[Project_owners] Dialog loosing modality

Adam Judson adamsplugins at gmail.com
Fri Mar 10 11:09:07 EST 2006

If the window underneath is getting focus, the implication is that the
alert is modal to the main window, rather than your dialog.

This should be easy to test (click on the dialog...).

Don't know why this would be, but you might try:

window.alert v.s. alert

the prompt service: http://www.xulplanet.com/tutorials/xulqa/q_msgbox.html


On 10/03/06, Paul Tomlin <paul at paultomlin.com> wrote:
> I've just tried again, reducing the code to the minimum I could without
> starting a new extension, and it certainly shows up.
> I can only think it might be related to something I do before openDialog
> [though this really shouldn't have any effect], or that I might be
> naughty by adding <this> as an argument to the openDialog call
> var win = window.openDialog(
>         "chrome://quickfile/content/quickfileDialog.xul",
>         "quickfileDialog",
>         "chrome,resizable,centerscreen,modal",
>         mAutoCompleteSession, this);
> I've played with the filter dialog, and it indeed remains modal if you
> pop an alert for the 'new filter' dialog accept when the name is empty.
> It's slightly different in that the main filters dialog isn't itself
> modal, so you can always click back on the main TB window.
> QF launches a modal dialog in order to stop you changing message
> selection. When I force an error, pop an alert, dismiss the alert, the
> main TB window is not only accessible, it's actually focussed. The QF
> dialog at that point is still visible above the main TB window, but not
> the current input focus.
> Most odd
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> http://mozdev.org/mailman/listinfo/project_owners

More information about the Project_owners mailing list