1349406 - Only each 2nd click on ">>" button in toolbar opens "more tools" panel if downloads button is placed inside

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect)

Description

[684sigma]

I noticed a problem in Nightly 55. It doesn't happen in Beta 52, Beta 53, ESR 45.
Sometimes when button ">>" in toolbar is clicked, it doesn't open "more tools" panel. More precisely, only each 2nd click works, if downloads button is placed inside "more tools" panel. It happens if downloads panel appeared even once.
Here's what I do

1. Open downloads panel. Close the panel
2. Resize window so that downloads button is inside "more tools" panel (appears when clicking >> button in toolbar)
3. Click >> button to open "more tools" panel.

Result: button >> looks pressed, but panel doesn't appear
Expected: "more tools" panel should open

*Pribably* it's a problem with "Downloads panel", because so far I only noticed this issue with downloads button.

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

rexboy, this is a regression from bug 1270006 - can you take a look at this, please?

[Tracking Requested - why for this release]: Confusing regression in UI behavior.

Comment 2

[:Gijs (he/him)]

The symptoms here are the same as bug 1029937. I expect the new binding is broken in a similar way to the old versions of the badge binding. Neil or Neil might be able to tell us more.

Comment 3

[Neil Deakin]

Likely. My patch from 1029937 appears to fix this bug as well.

Comment 4

[Loic]

Probably a missclick, but ESR52 is unaffected (only 54+).

Comment 5

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Just read the discussions of bug 1029937. 

The reason seems to be similar because there's a position: absolute added in bug 1270006.
And removing it do eliminate the symptom, but I'm not sure if there's an easy way to get rid of position: absolute without breaking the indicator. Still need some studying.

Comment 6

[:Gijs (he/him)]

(In reply to KM Lee [:rexboy] from comment #5)
> Just read the discussions of bug 1029937. 
> 
> The reason seems to be similar because there's a position: absolute added in
> bug 1270006.
> And removing it do eliminate the symptom, but I'm not sure if there's an
> easy way to get rid of position: absolute without breaking the indicator.
> Still need some studying.

Using a stack instead of absolute positioning might work (I haven't looked at the code).

Comment 7

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: Bug 1349406 - Avoid reflows for arrow-typed download indicators by using stack instead of position: absolute.

Review commit: https://reviewboard.mozilla.org/r/123434/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/123434/

Comment 8

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Seems using stack works well. Thanks for the advise Gijs!
Tested on Linux and Mac.
Paolo would you take a look on this quick fix?

And I'll be away for the next week, so if follow-up fixes are needed I'll be available after Apr. 4.

Comment 9

[Marcia Knous [:marcia]]

Tracking 54/55+ for this regression.

Comment 10

[:Paolo Amadini]

Comment on attachment 8850918 [details]
Bug 1349406 - Avoid reflows for arrow-typed download indicators by using stack instead of position: absolute.

https://reviewboard.mozilla.org/r/123434/#review127594

Thanks! This works well and is easy to uplift.

We can probably avoid having a nested stack, but we can handle this later in bug 1329109.

Comment 11

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Thanks Paolo!
Let's try checkin and uplift it.

Comment 12

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Comment on attachment 8850918 [details]
Bug 1349406 - Avoid reflows for arrow-typed download indicators by using stack instead of position: absolute.

Approval Request Comment
[Feature/Bug causing the regression]: 1270006
[User impact if declined]: "more tools" panel works in confusing way on each 2nd click
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Not yet
[Needs manual test from QE? If yes, steps to reproduce]: See STR in reporter
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Only trivial changes to css/xul on download button of toolbar
[String changes made/needed]: No

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b8145a0cff58
Avoid reflows for arrow-typed download indicators by using stack instead of position: absolute. r=Paolo

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/b8145a0cff58

Comment 15

[Gerry Chang [:gchang]]

Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!

Comment 16

[Simona Badau, Desktop QA]

Reproduced the initial issue using Nightly 55.0a1 (Build ID: 20170406030206) on Windows 10 x64.

Verified as fixed using the latest Nightly 55.0a1 (Build ID: 20170407030233) on Windows 10 x64, Ubuntu 16.04 x64, Mac OS X 10.12

Comment 17

[Gerry Chang [:gchang]]

Comment on attachment 8850918 [details]
Bug 1349406 - Avoid reflows for arrow-typed download indicators by using stack instead of position: absolute.

Fix a regression and was verified. Aurora54+.

Comment 18

[Brindusa Tot, Desktop QA]

Based on comment 16, the bug was verified on latest Nightly. Remove the NI flag.

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/5dc8f5c5ff0d

Comment 20

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I reproduced this issue using Nightly 55.0a1 (Build ID: 20170406030206) on Windows 10 x64.
I can confirm this issue is fixed, I verified using Fx 54.0b1 on Windows 10 x64, Ubuntu 14.04 LTS and Mac OS X 10.12.4.

Cheers!