Closed
Bug 1245356
Opened 9 years ago
Closed 8 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)
(deleted),
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•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 13•8 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
•