Closed Bug 628290 Opened 9 years ago Closed 9 years ago

Click on "Get Add-ons" has to always load the initial Discovery pane


(Toolkit :: Add-ons Manager, defect)

Not set



Tracking Status
blocking2.0 --- .x+


(Reporter: robinaarden, Assigned: Unfocused)



(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

When Opening add-ons--> get add-ons and selecting one for download or more info. Then selecting for example on the left category extensions. Then there is no possible way to go back a level in the get add-ons page. Pressing back or forward buttons don't change current page buth change back to other tab/catagory and leave get add-on page on it's currents page. So only way of browsing further trough the page is to close the tab and go to add-ons - get add-ons once again.

Reproducible: Always

Steps to Reproduce:
1.Open [add-ons] (trough menu button)
2.Click [Get add-ons]
3.Click on the get add-on start-page on a [random add-on] for info or download.
4. Click on [extensions or plug-ins]
5. Click on [Get add-ons]

Actual Results:  
Now it is impossible to go back to the start-page from get add-ons tab without closing the tab. Pressing back will change category but impossible to go back a level on the get add-ons page.

Expected Results:  
Pressing the back button should change the item within the Get add-ons tab. not switching tabs to the last selected category. Or have the ability to revert home on the get add-ons tab. 

Feel free to contact me for further information
The problem with back/forward in the discovery pane is bug 625669.

Dave, I would like to keep this bug open for the add-ons manager itself. I really think we should always display the entry page when an user clicks on Get Addons.
Component: Menus → Add-ons Manager
Ever confirmed: true
Keywords: uiwanted
OS: Windows 7 → All
Product: Firefox → Toolkit
QA Contact: menus → add-ons.manager
Hardware: x86_64 → All
Version: unspecified → Trunk
Summary: Get Add-ons has no good possible working button to go back to home (need to close window every time a add-on has been opened and other catagory is selected) . Menu>Add-on>Get addon Firefox/4.0b9 → Click on "Get Add-ons" has to always load the initial Discovery pane
(In reply to comment #1)
> I really think we should always display the entry page when an user clicks on Get Addons.

Agreed - in addition to the issue described in comment 0, its inconsistent with other categories. Clicking on the extensions category will always bring you back to the extensions list, regardless of whether you're in the details view of an installed extension or not.
Assignee: nobody → bmcbride
Dave, while testing your try server build on bug 591905, this bug has been turned out to be really annoying. It doesn't sound that complicated to fix, and will help a lot for the navigation in the discovery pane. Something we could fix for Firefox 4?
blocking2.0: --- → ?
blocking2.0: ? → final+
Keywords: uiwanted
Whiteboard: [softblocker]
Attached patch Patch v1 (obsolete) — Splinter Review
Attachment #508567 - Flags: review?(dtownsend)
Comment on attachment 508567 [details] [diff] [review]
Patch v1

Once we land bug 591905 history will be working but this patch doesn't work well with it, it needs to push a new history state at least, but I think you'll need to put some of this logic into loadViewInternal rather than loadView
Attachment #508567 - Flags: review?(dtownsend) → review-
If this passes reviews, it has implicit a=beltzner
Whiteboard: [softblocker] → [softblocker][pre-approved by beltzner]
I think this is implicit in the filing of this bug, but clicking an add-on category on the left side of the add-ons manager should *always* go to the top level of that category, even if the user is a few levels deep in that category.
Attached patch Patch v2Splinter Review
This ended up being deceptively complex, but thankfully easy to test.

Patch handles clicking on Get Addons when already in discovery pane - but will only load the main page when on a different page. And properly integrates that into history - letting the page load add to history rather than replace or manually add via pushState. Also checks whether the pane is already loading - needed because gCategoryManager listens for both click and select events, so it loadView() is called twice for every click on a category item.
Attachment #508567 - Attachment is obsolete: true
Attachment #516456 - Flags: review?(dtownsend)

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
Attachment #516456 - Flags: review?(dtownsend) → review+
Whiteboard: [softblocker][pre-approved by beltzner] → [softblocker][pre-approved by beltzner][wanted fx5]
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [softblocker][pre-approved by beltzner][wanted fx5]
Flags: in-litmus-
Target Milestone: --- → mozilla6
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110430 Firefox/6.0a1
You need to log in before you can comment on or make changes to this bug.