1145868 - Popup position is wrong in Customize tab

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Alice0775 White]

Attachment: Screenshot

[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

Comment 1

[Alice0775 White]

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

Comment 2

[Alice0775 White]

[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

Comment 4

[Daniel Holbert [:dholbert]]

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.)

Comment 5

[Daniel Holbert [:dholbert]]

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

Comment 6

[Daniel Holbert [:dholbert]]

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.

Comment 7

[Timothy Nikkel (:tnikkel)]

(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.

Comment 9

[Loic]

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.

Comment 10

[Alice0775 White]

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

Comment 11

[Daniel Holbert [:dholbert]]

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.

Comment 13

[Daniel Holbert [:dholbert]]

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

Comment 14

[Daniel Holbert [:dholbert]]

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

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

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