Closed
Bug 586956
Opened 14 years ago
Closed 6 years ago
Add-ons Manager should remember last selected (highlighted) extension and show it scrolled into view until the manager is closed
Categories
(Toolkit :: Add-ons Manager, enhancement)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: tawn, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3) Gecko/20100805 Firefox/4.0b3 Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3) Gecko/20100805 Firefox/4.0b3 When switching between tabs in Add-ons Manager or if I am trying out or testing an extensions preferences and they require a restart to take effect, I shouldn't have to keep searching for the previously highlighted add-on in list. Don't know if this is a bug or rfe, but this feature was present before the Add-ons Manager rewrite and I see no reason to drop it. Reproducible: Always Steps to Reproduce: 1. Open Add-ons Manager 2. Click the extensions tab 3. Scroll down and click to select an extension, which then becomes highlighted 4. Click the themes tab 5. Click the extensions tab to go back to it Actual Results: Extension selected in step 3 is no longer highlighted and you have to scroll down and look for it again (or use the search box to find it again) Expected Results: Extension selected in step 3 is still highlighted and scrolled into view.
Comment 1•14 years ago
|
||
This behavior has been removed by the patch on bug 339206. And I don't think that we want to bring it back. Dave, is it invalid?
Updated•14 years ago
|
Whiteboard: [invalid?]
Reporter | ||
Comment 2•14 years ago
|
||
bug 562797 comment 16 (and 18) "...supporting about:addons#my-addon-id as a much simpler shortcut that just always assumes you want the detail view of a specific addon" sounds like an excellent alternative. Has/should a separate bug been filed for that as a rfe?
Comment 3•14 years ago
|
||
This is something we used to do in the old manager and wasn't really ideal. I think there is a case for remembering the last selected item from each list as long as the manager tab remains open, but I think that once closed it would then forget the selection and the next manager opened would just be a fresh view. I certainly wouldn't block a release on this so I wouldn't have time to work on it before Firefox 4 goes out, but if Boriss agrees with my rationale and a patch with tests was forthcoming then I'd review and take it.
Severity: normal → enhancement
OS: Windows 7 → All
Hardware: x86 → All
Summary: Add-ons Manager should remember last selected (highlighted) extension and show it scrolled into view → Add-ons Manager should remember last selected (highlighted) extension and show it scrolled into view until the manager is closed
Whiteboard: [invalid?]
Comment 4•14 years ago
|
||
And also scroll position should persist when switching view between "List view" and "Detail view".
Comment 5•14 years ago
|
||
(In reply to comment #3) > I certainly wouldn't block a release on this so I wouldn't have time to work on > it before Firefox 4 goes out, but if Boriss agrees with my rationale and a > patch with tests was forthcoming then I'd review and take it. Jennifer can you please give us your feedback? Thanks.
also, i think the scroll speed in the add-on tab is slower than in normal tabs
Reporter | ||
Comment 7•14 years ago
|
||
I created https://addons.mozilla.org/en-US/firefox/addon/222537/ as a basic workaround for this issue.
Comment 9•14 years ago
|
||
Two alternatives. 1) Only do this on the back button 2) Add a button that says "back" to the page itself (probably a bad idea). It is really annoying when one is going thru a lot of addons to start at the top each time.
Comment 11•14 years ago
|
||
Dave, after testing of a lot of add-ons in the last week, this issue is kinda annoying over time. Should we get it on the softblocking list?
blocking2.0: --- → ?
Comment 13•14 years ago
|
||
Annoying in non-primary UI is not nearly disruptive enough to hold back Firefox 4 given how badly we need to ship it. This would be a slick piece of UI polish for people who spend a lot of time in the AOM, so wanted+, but blocking-.
Comment 14•14 years ago
|
||
Agreed. Note: This should at least be a lot easier to implement thanks to the changes in bug 591905, since we pass around the state information to the view when navigating via history.
Comment 15•14 years ago
|
||
For Firefox 4, add-ons in List View won't be highlighted but will instead launched detailed view with a single click. The rationale for this can be found in bug 625465. Thanks for filing this, custom.firefox.lady: we may revisit the possibility of multiple selections in later versions.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Comment 16•14 years ago
|
||
Jennifer, also with bug 625465 this bug will persist, at least the second part to remember the scroll position, which is probably the most important part of this bug report.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 17•14 years ago
|
||
(In reply to comment #16) > Jennifer, also with bug 625465 this bug will persist, at least the second part > to remember the scroll position, which is probably the most important part of > this bug report. Thanks for pointing this out, Henrik. I agree with Dave in Comment 3: we should remember scrolling position within one session of the manager, but not after it has been closed. When the user opens the manager, they are essentially performing a task, and jumping between categories may be part of the user's interaction in that task. However, once the manager's closed, that task is completed and we should be resetting the manager to a "fresh" state of scrolled up. This is particularly important now that add-ons are grouped by status. Maintaining scrolling status through one opening of the manager would include pressing back and forward.
Comment 19•6 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 6 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•