[Tracking Requested - why for this release]: Steps To Reproduce: 1. Enter Customize Mode 2. Click [Show / Hide Toolbars] Actual Results: Popup position is wrong Expected Results: Popup should be positioned beneath of the button

Another Steps To Reproduce: 1. Enter Customize Mode 2. Click [Theme]

[Tracking Requested - why for this release]: Regressed in Aurora38.0a2 and Nightly39.0a1 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=514c80664661&tochange=6cd4d71818ee Suspect: Bug 1142686 Also affected latest tinderbox aurora38.0a2

I can reproduce this in current Nightly. Thanks for the CC/needinfo. (In reply to Alice0775 White from comment #2) > Suspect: Bug 1142686 Yeah -- that bug fixes a formerly-broken check, which guarded the optimization from bug 1054010. It effectively makes that optimization apply more broadly. I would bet that Bug 1128354's patch (which has already landed on inbound & has a pending aurora-approval-request) will fix this. (This is likely a variant of bug 1128354 which we didn't initially hit because there was a border or padding, which accidentally prevented us from optimizing, until Bug 1142686's fix.) (I actually intended to land bug 1128354 & Bug 1142686 to Aurora at the same time, in case there might be fallout like this, but I forgot that RyanVM is awesome and lands stuff as soon as it's approved. :) I should've commented or held off on my approval request.)

Yeah, I can't reproduce in my up-to-date mozilla-inbound debug build, so I think bug 1128354 fixed this. Marking dependency.

I do still see one quirk with the "Themes" menu in customize mode, with bug 1128354 applied, though. - The first time I open the menu, it's correctly-positioned (directly above the button). - The second time I open the menu, it's positioned such that it's 50% lower down -- vertically centered over the menu button, basically. - The 3rd, 4th, etc. times I open it, it's still in an awkward centered-over-the-button position. - But if I resize my browser-window, and then open it again, the position seems to be fixed for good, from that point on. It's possible that lack-of-redundant-reflowing is just exposing an underlying layout bug, as was the case in bug 1143781.

(In reply to Daniel Holbert [:dholbert] from comment #6) > It's possible that lack-of-redundant-reflowing is just exposing an > underlying layout bug, as was the case in bug 1143781. I think bug 1130400 is likely the underlying bug.

Are you sure FF38 is affected? I just teste with the latest Aurora and I don't see any issue of bad positionning of the pop up. http://i.imgur.com/khGxf1P.jpg Because in bug 1145522, the regression range is after 2015-03-16.

I can reproduce on https://hg.mozilla.org/releases/mozilla-aurora/rev/7b82c496e1e3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150321004005 The offending patch( 8852b9ffe7c2 ) was landed in aurora on Fri Mar 20 18:05:00 2015 +0000. See https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=525829e43c33&tochange=7b82c496e1e3

Ah! I just discovered that I can reproduce comment 6's lingering issue in Firefox Beta 37. So, it indeed predates anything here. (and may very well be bug 1130400, as tn suggested.) So, I think we're all set here, once bug 1128354 has merged to central & aurora.

I confirmed that this is fixed (by bug 1128354) in latest nightly: 39.0a1 (2015-03-22)

(Should be fixed on 38 as well when bug 1128354 gets uplifted.)

This is already fixed in 38 and 39 so we don't need to track it.