Daniel Holbert [:dholbert] Reporter
	Description • 9 years ago

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.

	Daniel Holbert [:dholbert] 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.

	Daniel Holbert [:dholbert] 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.

	Daniel Holbert [:dholbert] 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.

	Alex Gibson [:agibson]
	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.

	Alex Gibson [:agibson]
	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.

	Daniel Holbert [:dholbert] 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.

	Alex Gibson [:agibson]
	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.

	Daniel Holbert [:dholbert] 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)

	Daniel Holbert [:dholbert] 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.)

	Markus Stange [:mstange]
	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.

	Daniel Holbert [:dholbert] 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. ]