Created attachment 546146 [details] Screen shot 2011-07-15 at 3.45.42 PM.png User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110715 Firefox/8.0a1 Build ID: 20110715030758 Steps to reproduce: Starting with today's nightly, changeset: 52617959b48e, I'm getting major graphical corruption on context menus and the drop down for the URL-bar, see attached screenshots. If I disable accelerated layers the context menus disappear all together. The pushlog shows that bug 648484 landed between yesterday's build (no issues) and today's build (graphical corruption).
Created attachment 546147 [details] Screenshot of URL-bar dropdown Screenshot of the URL-bar, also the pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=34b0b3bc6984&tochange=52617959b48e
This seems like something that would prevent nightly dogfooding...
Severity: normal → critical
I confirm the problem on Mac OS X 10.5, w/o hardware acceleration. Several elements disappeared in today's nightly: tooltips, contextuals menus, menus from the folder in the boomarks toolbar, dropdown for the search bar, dropdown with the suggestion of the awesome bar. A new profile doesn't help. (I can't change status to confirm as the menu doesn't appear here ;-) )
Status: UNCONFIRMED → NEW
Ever confirmed: true
On Windows this works perfectly with or without HA . I can't reproduce any of the bugs. So I think "All" should be removed from the platform ?
The Platform is set to OS X. This occurs both in 32-bit and 64-bit mode (x86 and x86_64 respectively, hence "All Mac OS X").
More pics: http://i.imgur.com/GHdmQ.png http://imgur.com/HVXasl&XCkQJ&fjZkU Snow Leopard 10.6.8 started happening with the nightly today, was perfectly fine yesterday.
I've started building to see what's at fault. It's going to take me a while because my mac build env is out of date and somewhat slow. Bug 648484 looks very suspicious but I can't see anything that might have broken this. I think the symptom might be somehow GL layers are being used for popup widgets. This isn't the first time we've had this exact bug. We can't (easily) reftest popups, but is there some other way we write a test to check this doesn't happen again? Will think on't.
I bisected the mozilla-inbound build and found that it did in fact start with the push for bug 648484: http://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=a0ea3fd86f20
Thanks! My first build is still going :/. Backing out.
Backout: http://hg.mozilla.org/mozilla-central/rev/36828a0ab010 If anyone thinks this is worth respinning the nightly over, it can be respun off of http://hg.mozilla.org/mozilla-central/rev/d3f9f3411612
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
I reverted to yesterdays build and I've got no problems waiting for tomorrows build, but if there is a significant number of Nightly mac testers it would be nice for them to have a working browser.
(In reply to comment #10) > If anyone thinks this is worth respinning the nightly over, it can be respun > off of > > http://hg.mozilla.org/mozilla-central/rev/d3f9f3411612 I've asked bhearsum to do that.
You need to log in before you can comment on or make changes to this bug.