See the screen shot: http://forums.mozillazine.org/viewtopic.php?p=414780#414780 This showed up March 4th, the day after the stuff for Bug #118296. But then you backed some stuff out and moved it to a gtk2 specific skin directory. However this problem remained after the back out. I see it still in builds from March 5th. Any ideas?

uh. is it for windows? The line is due to the native painting of the menubar.

yes this regression is in the windows build sorry I wasn't clear :)

I am very surprized. without rebuilding, could you extract the file toolbar.css in chrome/classic.jar, and see if there is an appearance set to the menubar? (and report any appearance)

I see the problem with a fresh thunderbird build with gtk2, but only when I am trying to customize the toolbars. Same problem in Firefox. When I exit the customization panel, the extra borders of the menubar disappear.

Pierre, that was weird, if I try to customize the toolbar and hit ok, then the grey line goes away. But the next time I start thunderbird up again it is back. At least on windows. Any ideas what change from the 4th would have caused this?

The menubar appearance is well understandable: the CSS rule that hides its appearance was not matching the inserted palette in toolbar customization mode. I checked in a fix. But it's only for gtk2... I don't get at all the windows case... Could you remove your dist/chrome and rebuild? Then, if there are still problems, attach the toolbar.css from classic.jar?

I was seeing this in Firefox, but after deleting dist/chrome and rebuilding it no longer appears. Strange.

Sorry, I spoke too soon. After restarting Firefox, that accursed bar was back! Here's my toolbar.css file from classic.jar.

Pierre, I just blew away dist, did a clobber build and on Win XP I still get this grey bar underneath the menubar in thunderbird. Sounds like Jon Henry still sees it in firefox after a clean build.

I'm seeing the line under the menubar in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040306 Firefox/0.8.0+ The strange thing is that the first time I load FF after building/editing a chrome file/deleting xul.mfl it doesn't appear, but it does appear the next time I load. Whether it appears or not DOMI shows that the menubar is matching this rule: toolbar[type="menubar"], menubar { min-width: 1px; min-height: 20px; border-bottom: 1px solid ThreeDShadow; border-top: 0px !important; } But the computed styles for the border-bottom properties show them blank on first load and "1px solid rgb(157, 157, 161)" on subsequent loads.

Bug still apperent in 07 builds: http://www.gpcentre.net/tmp/line-bug.png The line does not appear after a "new" install of a .zip nightly. However, after restart it returns indefinatly (until you start up another "new" nightly). Test: Two versions of Moz Fx: 2004-03-03 and 2004-03-07 Start up 03; no line. Restart 03; no line. Start up 07; no line. Restart 07; line. Restart (indefinte) 07; line

apparently ben and brian are also looking into this. cc'ing them so they can be kept up to date.

This definetely has something to do with the XUL Cache. If you delete the XUL.mfl and start Firefox, the menubar is normal. Restart again and you get the bar. I disabled the XUL cache using TTLO, and it's fine since (this obviously causes startup slowdown though).

This should fix it. Would be great if someone could try it out since i don't have a FF/TB build

Jonas, any chance the changes to mozilla/content could have caused the other UI regression that showed up the same time as this one. Random dialogs and windows are not getting the correct width set on them anymore. they come up clipped. See Bug #236467. I'll try this patch out for the grey line.

so far it looks like this patch fixes the problem.

Comment on attachment 143340 [details] [diff] [review] patch to fix Yes, the bug will affect all style-attributes in XUL that has non-empty attributes before them in the markup.

Marking fixed per comment 16. Please reopen if it didn't fix it for you. If someone else tests with tomorrows nighly and the problem is fixed there please mark this as verified.

I just tested today's Linux build, and the problem is indeed fixed.