Open Bug 1795618 Opened 2 years ago Updated 2 years ago

The Firefox View notification dot disappears on hover if the button is placed on the Toolbar while on the Dark theme

Categories

(Firefox :: Firefox View, defect, P5)

Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr102 --- unaffected
firefox106 --- affected
firefox107 --- affected
firefox108 --- affected

People

(Reporter: atrif, Unassigned)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [fidefe-firefox-view])

Attachments

(1 file)

Attached image fx_view.gif (deleted) —

Found in

  • 107.0a1 (20221016093143)

Affected versions

  • 107.0a1 (20221016093143)
  • 106.0

Tested platforms

  • Affected platforms: Windows 10x64, Ubuntu 20.04, macOS 10.15
  • Unaffected platforms: none

Steps to reproduce

  1. Sign in with a FxA account to sync between devices.
  2. Move the Firefox view button to the Toolbar from the Customize menu.
  3. Change the Firefox theme to Dark.
  4. Open some tabs on a device and wait for the notification dot for the available pick-up tab pages to be displayed on the other device.
  5. After the notification dot is displayed hover over the Firefox View button.

Expected result

  • The notification dot is displayed on hover.

Actual result

  • The notification dot disappears on hover.

Regression range

  • Not a regression. This happens to start with bug 1774397 when the notification dot was implemented.

Additional notes

  • Attached a screen recording of the issue.
  • The issue does not reproduce if the Firefox View button is placed on tab area or Overlow menu.
Has STR: --- → yes
Priority: -- → P2

Does this need to be a P2 given it only happens on a non-default theme when the user has actively moved the fxview button out of the tabstrip?

Flags: needinfo?(rfambro)

Thanks for the question here @Gijs! I'd like to observe how many users are actually moving this icon around once we get into release (beta metrics tell us that this number is currently around 5%). Something tells me that we could see a number of folks moving this around honestly just to see if they can. For now, maybe we consider this at the very bottom of the P2 list? What do you mean when you say "non-default" theme here btw?

Flags: needinfo?(rfambro) → needinfo?(gijskruitbosch+bugs)

(In reply to Ray Fambro from comment #2)

Thanks for the question here @Gijs! I'd like to observe how many users are actually moving this icon around once we get into release (beta metrics tell us that this number is currently around 5%). Something tells me that we could see a number of folks moving this around honestly just to see if they can. For now, maybe we consider this at the very bottom of the P2 list? What do you mean when you say "non-default" theme here btw?

I mean this only happens on the builtin "dark" theme, and that's used by a minority of users (though probably >5%).

However, I don't think your 5% number is accurate - on beta, 5% of people entirely removed the icon - the number of people who added it to any other surface is a fraction of that (less than 1%). This bug only occurs for users who did that, and then only those users who are also on a dark theme. So some small fraction of 1%. Hence me thinking it's not a P2. Oh, and we're removing the dot entirely, so it not being visible on hover is probably small potatoes in the grand scheme of things...

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(rfambro)

Yea since we are removing the dot anyway, this is no longer an issue at the moment.

Flags: needinfo?(rfambro)
Priority: P2 → P3

Should this bug be closed out since the dot is going to be removed? Marking it as P3 means someone might end up picking it up...

Ah. Good point. So we will eventually bring the dot back...just with a different set of criteria around when it should surface. When that happens, I assume this bug will become applicable again?

Flags: needinfo?(sclements)

(In reply to Ray Fambro from comment #6)

Ah. Good point. So we will eventually bring the dot back...just with a different set of criteria around when it should surface. When that happens, I assume this bug will become applicable again?

I see, so if you are bringing it back later on would it make sense to mark it as a P4 or have it blocked by another bug (one that will redesign/redo it)? Probably Gijs will have some thoughts on this. :) If we leave it as P3 it basically means we want in 108, though.

Flags: needinfo?(sclements)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(gijskruitbosch+bugs)
Priority: P3 → P5
Blocks: 1788692
No longer blocks: firefox-view
Blocks: firefox-view
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: