1149022 - unable to move or disable the reading list add button

Status: RESOLVED INVALID

Description

[Byron Jones ‹:glob› 🎈]

Created attachment 8585295 [details]
reading-list.gif

the current location of the reading list's add button means that for me it appears over the bug id in a bug's url, making it painful for me to copy the bug id from the url (an action i perform frequently).

i would like to see the ability to disable the add button, or be able to relocate it to a toolbar button, without disabling the ensure reading list feature by toggling browser.readinglist.enabled.

Comment 1

[(away 9/21) Jared Wein [:jaws] (please needinfo? me)]

There are two issues here:
1) The button only shows up on hover, so people may be planning on clicking on the text where the button will appear only to be foiled when their mouse reaches the text.
2) We're not taking advantage of the great customization abilities of Firefox post-Australis.

Are you sure we need to place this button in the URL bar? The bookmarks button was moved *outside* of the URL bar, and uses a combination button for Bookmarking and the Bookmarks list. We could do something similar for Add to Reading List + Reader Mode.

Comment 2

[Michael Maslaney [:mmaslaney] ([e-mail])]

Yes, for version 1, we need to have it in there. Version 2 will address placing this function into an all inclusive sent-to button. Once that's done, then we can address removing it's placement in the URL bar.

Comment 3

[Mark Hammond [:markh] - PTO until Sept 17]

(In reply to Michael Maslaney [:mmaslaney] ([e-mail]) from comment #2)
> Yes, for version 1, we need to have it in there. Version 2 will address
> placing this function into an all inclusive sent-to button. Once that's
> done, then we can address removing it's placement in the URL bar.

Does it absolutely need to be displayed only on hover until then?  I find the hover behaviour quite distracting (eg, every time the mouse moves from the menu bar to the content area and vice-versa, the flash of the URL bar distracts even though the user isn't interacting with it.

If we always displayed the button we'd solve that (perceived) distraction and also solve the initial bug report and Jared's (1) from comment 1 which re-states it.

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

The particularly problematic issue of obscuring the bug number in the URL seems to be due to a very specific combination of window size and the length of bugzilla URLs.

As Michael said, the button will likely change with V2.

About keeping it always visible: the issue here is that this would make the right end of the awesomebar pretty crowded.

Comment 5

[Michael Maslaney [:mmaslaney] ([e-mail])]

(In reply to Mark Hammond [:markh] from comment #3)
> (In reply to Michael Maslaney [:mmaslaney] ([e-mail]) from
> comment #2)
> > Yes, for version 1, we need to have it in there. Version 2 will address
> > placing this function into an all inclusive sent-to button. Once that's
> > done, then we can address removing it's placement in the URL bar.
> 
> Does it absolutely need to be displayed only on hover until then?  I find
> the hover behaviour quite distracting (eg, every time the mouse moves from
> the menu bar to the content area and vice-versa, the flash of the URL bar
> distracts even though the user isn't interacting with it.
> 
> If we always displayed the button we'd solve that (perceived) distraction
> and also solve the initial bug report and Jared's (1) from comment 1 which
> re-states it.

At the risk of adding to the already over-crowded URL bar, I would suggest keeping it on hover. I'll sync up with Bryan to see if there's a way we can track the perceived distraction. Also, v2 will most likely be removing the function from the URL bar to a button on the toolbar.

Comment 6

[Mark Hammond [:markh] - PTO until Sept 17]

Closing some old readinglist bugs.