BUILD: Seamonkey or Firefox build from 2008-01-03-02 or later STEPS TO REPRODUCE: 1) Start the browser 2) Open a menu ACTUAL RESULTS: Depending on the menu, either opens at 0x0 size or opens at the height of the screen. In the latter case, either none of the menuitems paint, or the ones before the first separator paint, and nothing after that. EXPECTED RESULTS: Menus work REGRESSION RANGE: 2008-01-02-02 to 2008-01-03-02, with Seamonkey builds. Bonsai URL with 2 hours padding: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-02+00&maxdate=2008-01-03+04&cvsroot=%2Fcvsroot ADDITIONAL NOTES: Switching to the Modern theme fixes the bug, so I'm guessing this is a regression from one of the GTK native theming fixes. I can only reproduce this with mozilla.org builds. My own builds don't show the problem. I'm using GTK2 2.6.10, in case that matters. Another box using GTK2 2.8.20 doesn't show the problem, but there are various other library and package differences there too (e.g. no gnome themes on that machine). If the issue is in fact that we don't support gtk2 2.6 at runtime if compiled against some other gtk version, we should fail to start instead of starting all broken...

Note that the minimum GTK version (as per the Linux ref platform) that's required for Firefox 3 is GTK 2.10. If we could possibly #ifdef something to help old GTK versions, that would probably be fine, but if this is really due to an old GTK version not supporting something we now do, I don't think it should block release.

If the gtk version is indeed the only issue (in that this is a bug in gtk that we can't deal with), I agree that we shouldn't block on it. That's not quite obvious to me so far...

I would guess out of the two options, that bug 408578 is the cause. I don't have a great knowledge of the internals of Firefox, but the only thing I think could cause this was when I force repaint when the open attribute changes.

But you don't do that for menus, right? I'm talking about the main browser menu (File, Edit, etc), not comboboxes.

I didn't add the code to specifically do it for comboboxes since I was under the impression that if ::open ever changed, then it was likely that ::menuactive changed as well. Someone with some more time could try removing that line and seeing if it fixes the issue. I have a deadline coming up, so I won't be much help for a week or so

Did backing out 408578 fix this?

Doesn't look like it did. :(

Given that GTK 2.6 is out of spec, I think we should just leave this bug alone unless/until someone reproduces it in 2.10 or higher, unless of course bz or another GTK 2.6 user wants to try local backouts.

Local backouts won't help. See comment 0 "additional notes" section. My own builds work just fine; it's just the ones mozilla.org ships that don't.

Oh right. Then I think we should close this.

11 years after, yes, closing!