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)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1239856

People

(Reporter: dholbert, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

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.
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.
Attached video screencast showing bug (deleted) —
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
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
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.
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.
(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.
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.
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)
(I'll just mark this as a regression from that bug for now, and let Markus dupe as-appropriate.)
Blocks: 1201327
(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)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
[ 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. ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: