1340435 - [Linux] Zoom reset button missing hover feedback

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Bogdan Maris, Desktop Test Engineering]

Attachment: Screencast showing the issue

[Affected versions]:
- Firefox 51.0.1 RC
- Firefox 52 beta 6
- latest Developer Edition 53.0a2
- latest Nightly 54.0a1

[Affected platforms]:
- Ubuntu 16.04 32bit

[Unaffected platforms]:
- Windows 10 64bit
- macOS 10.12.3

[Steps to reproduce]:
1. Start Firefox
2. Enter Customization and drag the zoom buttons to ToolBar
3. Hover over 100% value

[Expected result]:
- The hover effect is the same as on the other buttons.

[Actual result]:
- The hover effect for 100% button is missing, though the action of the button is not affected.

[Regression range]:
- This is NOT a recent regression (but a very old one), I've tracked it back to Nightly from 2014-01-18:
Last good revision: 9bcc52594322 (2014-01-17)
First bad revision: 298f262f21ff (2014-01-18)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9bcc52594322&tochange=298f262f21ff

I see a bunch of bugs that touched Australis, I'm sure Gijs will have a better idea of what caused this.

[Additional notes]:
- Screencast showing the issue attached.
- I marked this as a regression even though it's a very old one, feel free to remove the regression keyword if you feel this is not correct.
- If for some reason the attachment says the file is corrupt please visit this dropbox link for the same video: https://dl.dropboxusercontent.com/u/109148197/Screencast%202017-02-16%2018%3A05%3A02.mp4

Comment 1

[:Gijs (he/him)]

This smells like bug 944138 to me, looking at that range. Mike de Boer?

Comment 2

[Mike de Boer [:mikedeboer]]

Well, I don't think it's that bug specifically, but more so just a variant that we've missed during the wide widget styling implementation.
It looks bad, but I'm not sure where I'd find the time currently to work on this. Do we have an idea who can pick this up instead?
Meanwhile I'll keep it in mind and will work on it in a free moment.

Comment 3

[Dão Gottwald [:dao]]

(In reply to :Gijs from comment #1)
> This smells like bug 944138 to me, looking at that range. Mike de Boer?

The patch looks unrelated.

This bug doesn't exist on Windows, does it? With some luck we could copy whatever makes it work there.

Comment 4

[Dão Gottwald [:dao]]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #0)
> - This is NOT a recent regression (but a very old one), I've tracked it back
> to Nightly from 2014-01-18:
> Last good revision: 9bcc52594322 (2014-01-17)
> First bad revision: 298f262f21ff (2014-01-18)
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=9bcc52594322&tochange=298f262f21ff

-> bug 875479. Not really useful.

Comment 5

[Bogdan Maris, Desktop Test Engineering]

(In reply to Dão Gottwald [:dao] from comment #3)
> (In reply to :Gijs from comment #1)
> > This smells like bug 944138 to me, looking at that range. Mike de Boer?
> 
> 
> This bug doesn't exist on Windows, does it? With some luck we could copy
> whatever makes it work there.

Nope, this is only seen in Linux.

Comment 6

[Gerry Chang [:gchang]]

This is not a recent regression. Mark 51 won't fix.

Comment 7

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 8

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

Trivial issue and a lot of wontfixes in a row, let's leave this in the backlog and stop triaging it.

Comment 9

[Farhadur Reja Fahim]

I have reproduced this bug with Nightly 54.0a1 (2017-02-16) on Ubuntu 16.04, 64 bit!

The bug's fix is now verified on latest Beta 55.0b2

Build ID 	20170615133456
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

[bugday 20170614]