User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090626 Firefox/3.5 Build Identifier: 1.9.1 A XUL application uses xul:buttons in XBL bindings which observe broadcasters which in turn reside in an overlay file. Buttons are set to observe "collapsed" and "disabled" attributes. Something has changed between 1.9.0 and 1.9.1, and as a result buttons are drawn neither collapsed, nor disabled, tough the broadcasters has these attributes set to true. Nevertheless, the buttons report correct values for those attributes when asked with getAttribute(). Reproducible: Always This is a regression 1.9.1 against 1.9.0

This bug needs reasonable steps to reproduce, not just a pointer to a source repository.... Ideally, it would just have a simple testcase (either zipped-up xul+overlays+xbl or a Firefox extension if this needs to run as chrome to show the problem).

1. Install this extension into Firefox and restart 2. open chrome://abstract/content/entity.xul Actual results: "submit" and "discard" buttons are visible Expected results: They are "hidden" and "collapsed" Buttons have the attributes set to "true". If either button is pointed with mouse, its status is updated and it disappears.

The extension fails with 3.0.12, but it works well with 3.0b5.

Does the test case demonstrate the bug? Any pointers how to fix this or work around?

OK, this regressed between 2009-01-31-02 (rev d27323792a59) and 2009-02-01-02 (rev 2cd22042f7ef) on m-c. Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d27323792a59&tochange=2cd22042f7ef Relevant patches in that range that also landed on branches: bug 471166 and bug 468211. Those in fact touched broadcasters. Smaug, any idea what's up here?

This fixes the problem, but I need to run the tests etc. Bug 468211 made us synchronize later (at safe time) in some cases, but unfortunately mInitialLayoutComplete seem to be set quite late. Other option might be to set mInitialLayoutComplete a bit earlier, but that would be more like a hack.

Comment on attachment 394021 [details] [diff] [review] patch Safer patch coming

Comment on attachment 394037 [details] [diff] [review] better This is the safest I can think of.

Comment on attachment 394037 [details] [diff] [review] better I can't really say I know this code very well, but this looks reasonable.

I can confirm the patch works.

Comment on attachment 394037 [details] [diff] [review] better Approved for 1.9.1.4, a=dveditz for release-drivers

Comment on attachment 401812 [details] [diff] [review] 190 Approved for 1.9.0.15, a=dveditz for release-drivers

Checking in content/xul/document/src/nsXULDocument.cpp; /cvsroot/mozilla/content/xul/document/src/nsXULDocument.cpp,v <-- nsXULDocument.cpp new revision: 1.837; previous revision: 1.836 done Checking in content/xul/document/src/nsXULDocument.h; /cvsroot/mozilla/content/xul/document/src/nsXULDocument.h,v <-- nsXULDocument.h new revision: 1.213; previous revision: 1.212 done

(In reply to comment #2) > Created an attachment (id=390752) [details] > test case extension > > 1. Install this extension into Firefox and restart > 2. open chrome://abstract/content/entity.xul > > Actual results: > "submit" and "discard" buttons are visible > > Expected results: > They are "hidden" and "collapsed" > > Buttons have the attributes set to "true". If either button is pointed with > mouse, its status is updated and it disappears. This testcase doesn't work in 3.0.14. I don't see these buttons. This makes it a bit hard to verify the fix. Any suggestions?

(In reply to comment #19) > This testcase doesn't work in 3.0.14. Really? IIRC, I did test this on the latest 3.0.x without patch and then with patch. Without the patch the buttons were there, and with the patch they weren't.

(In reply to comment #19) > > Expected results: > > They are "hidden" and "collapsed" > > This testcase doesn't work in 3.0.14. I don't see these buttons. This makes it > a bit hard to verify the fix. Any suggestions? That's the correct behavior. The buttons shouldn't be visible.

Yes, but 3.0.14 is *before* the fix was checked in. I verify the bug before verifying the fix. I'm not seeing "submit" and "discard" buttons in 3.0.14 when running the repro steps above.

(In reply to comment #22) > Yes, but 3.0.14 is *before* the fix was checked in. I verify the bug before > verifying the fix. I'm not seeing "submit" and "discard" buttomayns in 3.0.14 when > running the repro steps above. I didn't test 1.9.0 tree. My app works with 1.9.1 and later. The bug may well not be there.

Verified for 1.9.1 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090924 Shiretoko/3.5.4pre (.NET CLR 3.5.30729). Verified for 1.9.0 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.15pre) Gecko/2009092805 GranParadiso/3.0.15pre (.NET CLR 3.5.30729) (I got the test case working - my mistake before).