Closed
Bug 1245356
Opened 9 years ago
Closed 9 years ago
On 2nd popup in Tracking Protection tour, the "x" close-button doesn't look different when hovered
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
DUPLICATE
of bug 1239856
People
(Reporter: dholbert, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
435.27 KB,
video/ogg
|
Details |
STR:
1. Launch the tracking protection tour -- e.g. Open a Private Browsing window and click "See How This Works".
2. Optional: Hover the "x" on the first popup. Note how it changes color (to red) to show you that it's a button.
3. Click "Next".
4. Hover the "x" on the second popup.
EXPECTED RESULTS: It should change color, like the first popup did.
ACTUAL RESULTS: It does not change color.
It does change color if I click it, though.
Reporter | ||
Comment 1•9 years ago
|
||
Alternate STR which take you directly to the "step 2" popup:
1. Visit https://www.mozilla.org/en-US/firefox/47.0a1/tracking-protection/start/?step=2
2. Hover the "x" on the popup.
Reporter | ||
Comment 2•9 years ago
|
||
Reporter | ||
Comment 3•9 years ago
|
||
This is a gecko regression -- in current Firefox release (44), both sets of STR produce EXPECTED RESULTS. So, this bug probably belongs in another component.
Tracking down a regression range now; I'll reclassify into the correct component after I determine what regressed it.
Keywords: regression
Reporter | ||
Comment 4•9 years ago
|
||
Markus, looks like this is one of yours -- regression from either bug 1201327 or bug 1201330.
Regression pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=097cac1912b9658ba68389b5dd72d4cc45e762d5&tochange=21cabf6ab3e9a254cdc9370986f300213b346cb2
This reproduces regardless of whether e10s is enabled, BTW.
Component: Tours → Layout
Flags: needinfo?(mstange)
Product: Firefox → Core
Reporter | ||
Updated•9 years ago
|
Comment 5•9 years ago
|
||
This is not a gecko regression. We can't anchor UITour pop ups on elements within the web page content, so we recreated one using html/CSS to mimick the real panels. We've had similar reports about minor differences here, but we generally don't think it warrants making things pixel perfect.
Comment 6•9 years ago
|
||
If this issue is just when hovering over the close button, then it's likely a trivial fix. But this needs to be done in the web content.
Reporter | ||
Comment 7•9 years ago
|
||
(In reply to Alex Gibson [:agibson] from comment #5)
> This is not a gecko regression.
I think you misunderstand -- there's absolutely a Gecko regression here. See regression range in comment 4, which is only gecko changes.
(Before that range, I get EXPECTED RESULTS -- the "x" button changes color when hovered. After that range, I get ACTUAL RESULTS -- the "x" button does not change at all when hovered.)
(In reply to Alex Gibson [:agibson] from comment #6)
> If this issue is just when hovering over the close button
It is.
> then it's likely
> a trivial fix. But this needs to be done in the web content.
Hooray! It sounds like that web-content fix might be working around an unexpected gecko behavior-change, though, and it's still worth tracking (and hopefully fixing) the gecko bug independently.
Comment 8•9 years ago
|
||
Interesting, CSS styles are here if they may be of use: https://github.com/mozilla/bedrock/blob/master/media/css/firefox/tracking-protection-tour.less#L256
It looks like we use a different image from the sprite for both hover and active states using background-position.
Reporter | ||
Comment 9•9 years ago
|
||
Thanks. In that case, this is almost certainly caused by this changeset from the regression range:
Bug 1201327 - Let DLBI detect background-position changes. r=mattwoodrow
...and really, this is probably a dupe of one of the existing regressions on that bug (e.g. bug 1239856)
Reporter | ||
Comment 10•9 years ago
|
||
(I'll just mark this as a regression from that bug for now, and let Markus dupe as-appropriate.)
Blocks: 1201327
Comment 11•9 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #9)
> Thanks. In that case, this is almost certainly caused by this changeset from
> the regression range:
> Bug 1201327 - Let DLBI detect background-position changes. r=mattwoodrow
> ...and really, this is probably a dupe of one of the existing regressions on
> that bug (e.g. bug 1239856)
Correct.
Flags: needinfo?(mstange)
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 13•9 years ago
|
||
[ clearing "status-firefox47:affected" since bug 1239856 comment 10 indicates that it should no longer be affected. I'll just leave the status fields unset since we'll be tracking status on duplicate bug 1239856 now. ]
status-firefox47:
affected → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•