[Affected versions]: - 47.0a1 [Affected platforms]: - Ubuntu 14.04 [Steps to reproduce]: 1. Launch Firefox with a clean profile. 2. Click on Menu panel (Hamburger button). 3. Select Customize. 4. Drag the 'Pocket', 'Forget' and 'Email Link' buttons to the top side of the Menu Panel, so they are on the first line of the panel, above the "Cut, Copy and Paste" buttons 5. Click on 'Exit Customize' 6. Click again on the Hamburger button [Expected result]: - Menu panel ok [Actual result]: - Menu panel broken - see the screenshot [Regression range]: - regressed by bug 1241832

[Tracking Requested - why for this release]: Regression from disabling xrender on Linux. I think this bug is visibly serious enough that it should block bug 1241832 from riding the trains. Lee, can you please look in to this?

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #1) > [Tracking Requested - why for this release]: Regression from disabling > xrender on Linux. I think this bug is visibly serious enough that it should > block bug 1241832 from riding the trains. > > Lee, can you please look in to this? I tried with a Linux nightly, followed STR, and I could not reproduce this. I tried toggling all related prefs we have recently changed retarded gfx.xrender.enabled and layers.use-image-offscreen-surfaces. Everything worked as expected.

(In reply to Lee Salzman [:lsalzman] from comment #2) > (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #1) > > [Tracking Requested - why for this release]: Regression from disabling > > xrender on Linux. I think this bug is visibly serious enough that it should > > block bug 1241832 from riding the trains. > > > > Lee, can you please look in to this? > > I tried with a Linux nightly, followed STR, and I could not reproduce this. > I tried toggling all related prefs we have recently changed retarded > gfx.xrender.enabled and layers.use-image-offscreen-surfaces. Everything > worked as expected. Incredibly sorry for horrible typo there, meant "regarding" obviously.

Paul, could you please provide further details so Lee can reproduce this bug?

Here is a screencast on a new profile, Fx 47.0a1 (2016-02-18), Ubuntu 14.04 x64.

(In reply to Paul Silaghi, QA [:pauly] from comment #5) > Created attachment 8721203 [details] > screencast > > Here is a screencast on a new profile, Fx 47.0a1 (2016-02-18), Ubuntu 14.04 > x64. I suspect the difference between this and the system Lee tested on might be the gtk3 version installed. See also bug 1249604.

Tracked for 47 since it's a recent regression. Milan, this is a pretty awful regression, could you please help find an owner for this issue? Thanks.

I need to sort out gtk3 issue, will get to the ownership after that.

GTK3 should ride 46, and it seems (comment 7) this is fine on GTK3 systems. Do we have an example of GTK3 system that fails with this?

(In reply to Milan Sreckovic [:milan] from comment #10) > GTK3 should ride 46, and it seems (comment 7) this is fine on GTK3 systems. > > Do we have an example of GTK3 system that fails with this? The screencast in attachment 8721203 [details] is using Nightly, so that was running gtk3. My point in comment 7 was about the version of gtk3 installed, because that turned out to be relevant in bug 1249604 - but it still needed a fix on our side. I wasn't trying to say that that screencast had no gtk3 enabled or installed - I'm fairly sure both are the case for nightly 47 on ubuntu 14.04.

Do we have multiple systems where we can reproduce this, or is Paul's the only one so far?

Paul, is yours the only system to reproduce this?

I can reproduce the issue on multiple systems on Nightly 47.0a1 (2016-02-16). But I can no longer reproduced it at all on 48.0a2 (2016-05-02), 49.0a1 (2016-05-02).

Andrew is looking for a fix-range, and we can then decide if the patch responsible for the fix is appropriate for an uplift.

I can't seem to reproduce this at all with GTK 3.4, 3.10, or 3.20 on the 2016-02-16 nightly using clean profiles and the Ambiance GTK theme. Do you mind running mozregression to try and find the commit that fixed this, Paul? Maybe it'll give us some clues as to what is responsible for this problem on your end.

This seems to be difficult, since the bug sometimes reproduces only after several tries. I've run mozregression 3 times and each time got a different range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1cf617a1f2813b6cd66f460313a61c223406c9b&tochange=241581e67d7535834591ae9ec031e5f0f37f6210 https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=19d0559bb450e18fffb8995053553fcff4f87bda&tochange=0e20bdd12dd106def9e6add5c4d5c79d6f8b199b https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d1b7c2464c2d8718d6a7506597feabf662ca7851&tochange=0bc377ee611a7311b7565969aceaa26b3c2d79ea

Thanks Paul. Unfortunately, I don't think any of those changesets are likely to be responsible for the issue, which appears related to X SHM (particularly what happens after the nsShmImage is resized, involving a recreation of the SHM image). If I had to guess, I'd suspect that Lee's double buffering patches fixed this somehow- at least, timing wise. I'll keep trying to reproduce locally.

[Tracking Requested - why for this release]: This is "only" a regression in the sense that xrender status has changed. It seems to be difficult to reproduce; I don't think we should track.