Last Comment Bug 509124 - Chrome flags are never set on unparented XUL windows
: Chrome flags are never set on unparented XUL windows
Product: Core
Classification: Components
Component: General (show other bugs)
: 1.9.1 Branch
: All All
-- major (vote)
: mozilla1.9.3a1
Assigned To:
Depends on: 514920 651659
  Show dependency treegraph
Reported: 2009-08-07 14:59 PDT by Aakash Desai [:aakashd]
Modified: 2015-10-16 11:48 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testFormManager/testClearFormHistory.js (4.76 KB, application/x-javascript)
2009-08-07 14:59 PDT, Aakash Desai [:aakashd]
no flags Details
simple window checker (1.05 KB, application/vnd.mozilla.xul+xml)
2009-08-08 16:23 PDT, Henrik Skupin (:whimboo)
no flags Details
Proposed patch (3.17 KB, patch)
2009-08-10 02:58 PDT,
jst: review+
benjamin: approval1.9.2-
Details | Diff | Splinter Review

Description User image Aakash Desai [:aakashd] 2009-08-07 14:59:05 PDT
Created attachment 393277 [details]

using the attached test case, the modal dialog API hangs and does not respond to the instancing of the clear recent history dialog via the tools menu.
Comment 1 User image Henrik Skupin (:whimboo) 2009-08-07 15:23:34 PDT
That CRH dialog is weird! I tried to get a fix for that but I have no idea where to start. Here some observations:

When I let go output from within the getDialog function go to the console I never see an entry for this window. I have three windows open main browser window, Mozmill window, and the Error Console. That means I get the following BrowserChrome flags: 4094, 2147487422, and 2147485198. There is no flag listed for the opened Clear Recent History window.

Comparing the opener to other instances of modal dialogs this one uses null for its parent window. But the modal attribute is set. So could it be that when null is specified the window is not listed by getXULWindowEnumerator("")?

As result we hang in our getDialog function:

Boris, do you know why this window is not listed by the enumerator?
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2009-08-07 18:08:22 PDT
I have no idea.  Neil might know...  In general, is the issue just that it's app-modal?
Comment 3 User image Henrik Skupin (:whimboo) 2009-08-08 02:17:27 PDT
Ok, I have flipped null against aParentWindow in sanitize.js and everything works fine. The CRH dialog is now listed when retrieving an enumerator with getXULWindowEnumerator. I know nothing about how the window list is build but by using no parent window seems to create an independent window outside of the window list which will not be detected when the construction of the list happens.
Comment 4 User image Henrik Skupin (:whimboo) 2009-08-08 02:44:02 PDT
See also bug 309406 (which added the ifdef for Mac) and bug 464930 (CRH shouldn't be a modal dialog).
Comment 5 User image 2009-08-08 03:08:48 PDT
I don't know about the Mac (which is the only OS that uses a null parent for
the CPH dialog). I can't reproduce the problem on Windows.
Comment 6 User image Steven Michaud [:smichaud] (Retired) 2009-08-08 09:50:42 PDT
Comment on attachment 393277 [details]

Forgive my ignorance ... but how do you run this test?
Comment 7 User image Henrik Skupin (:whimboo) 2009-08-08 15:08:37 PDT
Steven, just clone the mozmill-test repository ( and save the test e.g. to firefox/helperClasses. Open Mozmill and run the test. You have to put it into the correct folder due to shared modules dependencies.

The same situation can be observed on Windows when changing the first parameter of the window opener to null. It would be helpful to have a better testcase here which doesn't rely on Mozmill. I'll try to create one.
Comment 8 User image Henrik Skupin (:whimboo) 2009-08-08 16:23:02 PDT
Created attachment 393397 [details]
simple window checker

This XUL file checks all the open windows and displays their chromeFlags.

While writing this code I noticed that I was wrong. The window enumerator returns the correct window instances but opening the CRH with null as parent window seems to ignore the modal flag given to the openWindow function. The flag is not added to the windows chromeFlags but let the window be opened modal. That means we cannot evaluate if this window is modal or not.
Comment 9 User image 2009-08-09 14:00:06 PDT
Can you call nsIWebBrowserChrome::IsWindowModal perhaps?
(QI to nsIInterfaceRequestor and getInterface an nsIWebBrowserChrome)
Comment 10 User image Henrik Skupin (:whimboo) 2009-08-10 02:27:32 PDT
Thanks Neil! In my testings on Friday I forgot the nsiInterfaceRequestor part so that function wasn't working for me. Now we get the correct modal state of the CRH window. I will incorporate the patch for Mozmill in bug 492136.

Does it mean the behavior of the underlying component is ok and will not be changed?
Comment 11 User image Henrik Skupin (:whimboo) 2009-08-10 02:42:44 PDT
As Neil mentioned on IRC chrome flags should only be used for content windows (pop-ups). So is there anything we can do here or should this bug be closed?
Comment 12 User image 2009-08-10 02:53:23 PDT
When opening a window from another window (either modal or modeless) then the flags calculated by the window watcher are explicitly set on the newly created chrome window. However if the window is opened without a parent then no chrome flags are set, the XUL window's chromeFlags property has a default value and the window always opens with all of its chrome. Usually nobody cares since the only parentless windows are either the startup browser (which always has all of its chrome) or a random XUL window which doesn't care about chrome flags.
Comment 13 User image 2009-08-10 02:58:01 PDT
Created attachment 393487 [details] [diff] [review]
Proposed patch

The simpler patch would have been to add a call to SetChromeFlags to the one caller of CreateTopLevelWindow that doesn't do it itself, but since we're passing the chrome flags around anyway I thought I'd centralise it.
Comment 14 User image 2009-08-14 08:03:59 PDT
Pushed changeset 5798118100e1 to mozilla-central.
Comment 15 User image Henrik Skupin (:whimboo) 2009-08-21 14:00:42 PDT
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090821 Minefield/3.7a1pre ID:20090821030931

Neil, do you think it's worth to have this patch in 1.9.2?
Comment 16 User image 2009-08-22 03:20:37 PDT
Mozmill is the only consumer that I know of, so it's up to you, basically.
Comment 17 User image Henrik Skupin (:whimboo) 2009-08-24 03:52:08 PDT
Comment on attachment 393487 [details] [diff] [review]
Proposed patch

At the moment our Mozmill tests don't use the flags anymore but it could happen that we have to base on them. So it would be fantastic to get it into 1.9.2.
Comment 18 User image Dave Townsend [:mossop] 2009-09-06 04:42:23 PDT
I suspect that this caused bug 514920
Comment 19 User image Benjamin Smedberg [:bsmedberg] 2009-09-14 12:44:06 PDT
Comment on attachment 393487 [details] [diff] [review]
Proposed patch

Caused a regression, can't approve without a complete rollup.

Note You need to log in before you can comment on or make changes to this bug.