Add a label to hide synced tabs sidebar when it is shown
Categories
(Firefox :: Toolbars and Customization, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox68 | --- | fixed |
People
(Reporter: rfeeley, Assigned: umaralam48, Mentored)
References
Details
(Keywords: good-first-bug, Whiteboard: [bugday-20190424] )
Attachments
(2 files)
STEPS TO REPRODUCE
- Open Synced Tabs sidebar
- Open Synced Tabs menu panel
EXPECTED RESULTS
- Sidebar toggle is labelled Hide Synced Tabs Sidebar
ACTUAL RESULTS
- Sidebar toggle is labelled Hide Synced Tabs Sidebar
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
|
||
A bit of clarification on the STR:
Add the Synced Tabs button to your toolbar - by using the Customize option from the main menu, drag the 'Synced Tabs' icon to your toolbar to the right of the address/url bar.
Click the toggle sidebar icon in your toolbar to show the sidebar, and select the Synced Tabs panel from the picker at the top of the sidebar.
Sign into Sync - both the sidebar and the toolbar button will prompt you to sign in to Sync
Now, you are ready for the steps in comment #0. The menu that appears when you click the toolbar button has as its first item "View Synced Tabs Sidebar". This menu item actually toggles the visibility of the sidebar, so when the sidebar is already open, it should be labelled "Hide Synced Tabs Sidebar".
There is a currentID property on the SidebarUI which can be used to know if the Synced Tabs Sidebar is already open: https://searchfox.org/mozilla-central/source/browser/base/content/browser-sidebar.js#334
The current string used for this label is appMenuRemoteTabs.sidebar.label, which is used in the markup for this menuitem: https://searchfox.org/mozilla-central/source/browser/components/customizableui/content/panelUI.inc.xul#466
You'll need to define the new string for the "Hide.." variation and figure out how to switch it so the correct string is used for each state.
Comment 2•6 years ago
|
||
The new string should be added in https://searchfox.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.dtd#469 with the name of appMenuRemoteTabs.sidebar.hideLabel and the value of "Hide Synced Tabs Sidebar".
It looks like this code already handles changing the label based on if the sidebar is showing or not,
https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/base/content/browser.js#5827-5837
Therefore, the attribute in the XUL file should be named checked-label and the current attribute should be set as unchecked-label (not sure if we should keep the label attribute or not, this would need to be tested).
Updated•6 years ago
|
Comment 3•6 years ago
|
||
I would like to try to solve this issue.
Comment 4•6 years ago
|
||
(In reply to Berkay Barlas from comment #3)
I would like to try to solve this issue.
You may work on this, but we only assign bugs to people once a patch is attached. Please ask any questions you may have here while working on it.
Comment 5•6 years ago
|
||
Is anybody working on this?
Comment 6•6 years ago
|
||
Because this week is my midterm week(it will end tomorrow), I had trouble to find time to look at problem.
(In reply to (behind on reviews and needinfos) Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me) from comment #2)
Therefore, the attribute in the XUL file should be named
checked-labeland the current attribute should be set asunchecked-label(not sure if we should keep thelabelattribute or not, this would need to be tested).
I couldn't understand how to set the attribute in the XUL as 'checked-label'. Does not they need to be named like this
label="&appMenuRemoteTabs.sidebar.label;" to show the text?
| Assignee | ||
Comment 7•6 years ago
|
||
The same behaviour is shown by the history sidebar toggle button. Should I file a separate bug for it ?
Comment 8•6 years ago
|
||
(In reply to Mohd Umar Alam [:umaralam48] from comment #7)
The same behaviour is shown by the history sidebar toggle button. Should I file a separate bug for it ?
Yeah, go ahead. If it turns out both can be fixed with the same patch, we can always close it as a duplicate.
| Assignee | ||
Comment 9•6 years ago
|
||
See also : Bug 1529874
| Assignee | ||
Comment 10•6 years ago
|
||
Updated•6 years ago
|
Comment 11•6 years ago
|
||
:flod, I think Attachment #9059442 [details] just needs your ok to land at this point.
Comment 12•6 years ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #11)
:flod, I think Attachment #9059442 [details] just needs your ok to land at this point.
Not really. The review is mandatory only for FTL files, for DTDs and properties front-end devs have more than enough experience.
Comment 13•6 years ago
|
||
Comment 14•6 years ago
|
||
Comment 15•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/33363b7f728c
https://hg.mozilla.org/mozilla-central/rev/c0962f523e2a
| Assignee | ||
Comment 16•6 years ago
|
||
This patch fixes the bug 1529874 too so maybe we can close it?
Comment 18•6 years ago
•
|
||
I have reproduced this bug with Nightly 67.0a1 (2019-03-07) on Windows 7, 64 Bit. The fix of this bug is verified with latest Nightly!
Build ID 20190429095544
User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Updated•6 years ago
|
Description
•