Add-ons Manager should remember last selected (highlighted) extension and show it scrolled into view until the manager is closed

RESOLVED INACTIVE

Status

()

--
enhancement
RESOLVED INACTIVE
9 years ago
7 months ago

People

(Reporter: tawn, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted)

Details

(Reporter)

Description

9 years ago
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.
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?
Whiteboard: [invalid?]
(Reporter)

Comment 2

9 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?
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

8 years ago
And also scroll position should persist when switching view between "List view" and "Detail view".
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: uiwanted
Version: unspecified → Trunk

Comment 6

8 years ago
also, i think the scroll speed in the add-on tab is slower than in normal tabs
(Reporter)

Comment 7

8 years ago
I created
https://addons.mozilla.org/en-US/firefox/addon/222537/
as a basic workaround for this issue.
Duplicate of this bug: 620934

Comment 9

8 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.
Duplicate of this bug: 616806
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: --- → ?
Duplicate of this bug: 633809
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-.
blocking2.0: ? → -
status2.0: --- → wanted
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.
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
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
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 → ---
(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.
Duplicate of this bug: 681604
Keywords: uiwanted

Comment 19

7 months 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
Last Resolved: 8 years ago7 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.