1145609 - The Reading List item removal button should have the same tooltip as the one from the Location Bar

Status: RESOLVED INVALID

(Firefox Graveyard :: Reading List, defect, P4)

Description

[Andrei Vaida [:avaida]]

Reproducible on:
Nightly 39.0a1 (2015-03-20)

Affected platforms:
Ubuntu 14.04 (x64), Windows 7 (x64), Mac OS X 10.9.5

Preconditions:
* browser.readinglist.enabled = true
* a profile with at least 1 item in the Reading List

Steps to reproduce:
1. Launch Firefox.
2. Enable the Reading List sidebar, via toolbar → Show your bookmarks → Reading List → Show Reading List Sidebar.
3. Check the tooltip available for the remove button associated to a Reading List item.

Expected result:
The tooltip of a Reading List's item remove-button from the sidebar states the same thing as the one from the Location Bar, "Remove page from Reading List".

Actual result:
* The tooltip from the sidebar states: "Remove this from your Reading List".
* Also, please note that the tooltip of the same button from Reader View, states: "Remove from Reading List".

Comment 1

[Florian Quèze [:florian]]

Currently we actually have 3 different tooltip texts for 'remove':
- "Remove this from your Reading List" for the [X] buttons of sidebar items.
- "Remove page from Reading List" for the url bar button.
- "Remove from Reading List" for the button in the reader view toolbar.

And there are 2 different strings for 'add':
- "Add page to Reading List" for the url bar button.
- "Add to Reading List" for the reader view toolbar.

I just discussed this with mmaslaney; he thinks we should consolidate these and use the shorter strings everywhere: "Remove from Reading List" and "Add to Reading List".

Comment 2

[Florian Quèze [:florian]]

For 39/central, we need to clean up the mess (keep in mind that when changing the wording of a string, we need to also change its id for localizers to pick up the change).

For 38, we can either put in place hacks to get all the strings based on the one we like that's already there somehow; or we can decide it's wontfix (because that issue isn't _that_ bad).

The part that really needs to happen soon is landing the correct strings in the correct files for 39 before it's string frozen.

Comment 3

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to Florian Quèze [:florian] [:flo] (PTO until April 7th) from comment #2)
> For 38, we can either put in place hacks to get all the strings based on the
> one we like that's already there somehow; or we can decide it's wontfix
> (because that issue isn't _that_ bad).

This is annoying but I'm marking it as a P4, adding dolske to check if he agrees, because I think for now we can ship in 38 with tooltips we have.

The flag should still be raised for landing this in 39 in time to fix up the strings.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Looks like we missed string freeze for 39 here.

Comment 5

[Bryan Clark (DevTools PM) [:clarkbw]]

sad :panda_face:

Florian, can you get this in for 40?

Comment 6

[Rares Doghi, Desktop QA]

This no longer applies in our latest Builds 123.0.1