Closed Bug 560449 Opened 10 years ago Closed 9 years ago

Add support for opening the addons manager at a specific pane

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla2.0b1
Tracking Status
blocking2.0 --- final+

People

(Reporter: Unfocused, Assigned: mossop)

References

Details

(Whiteboard: [rewrite])

Attachments

(1 file)

The old addons manager could be opened with a specific pane showing. Need to support this in the new UI too.
Blocks: 552754
Would that imply manual tests or can we cover all of that with automation? I wonder under which circumstances users could see that.
Flags: in-testsuite?
Flags: in-litmus?
The automated tests seem to cover this for the old UI - should just be a matter of adapting them (er, and adding more).
Flags: in-litmus? → in-litmus-
Need help with this?
(In reply to comment #3)
> Need help with this?

Yea, that'd be great! Feel free to grab this and any other bug that blocks bug 550048.

I haven't come up with any concrete plans on the best way to tackle this.
Passing the addons:// url as the argument seems like the best way to do this.
(In reply to comment #4)
> Yea, that'd be great! Feel free to grab this and any other bug that blocks bug
> 550048.
> 
> I haven't come up with any concrete plans on the best way to tackle this.

/me goes to build http://hg.mozilla.org/projects/addonsmgr/
Blocks: 554231
The current behavior is also visible and annoying when going forward and backward in the history. Each time you open the add-ons manager we open the extension pane at the moment.
Depends on: 562797
Blocks: SMAddonMgr
Duplicate of this bug: 567137
IMO we should block on this.
blocking2.0: --- → ?
No longer depends on: 562797
Depends on: 562899
Have a patch in progress for this.
Assignee: nobody → dtownsend
blocking2.0: ? → final+
Attached patch patch rev 1Splinter Review
This turns on persistence for the initial view (though it doesn't work when viewing as about:addons right now) and adds a global method to load a new view. The main browser code now waits for the tab to complete loading and then calls it to select a specific view if necessary. Made the test for the plugin case work.
Comment on attachment 451323 [details] [diff] [review]
patch rev 1

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>+ * @param A callback to call when the tab is open, the tab will be passed as
>+ *        an argument

looks like it's actually "the tab's browser", right?
Attachment #451323 - Flags: review+
Landed and tested: http://hg.mozilla.org/mozilla-central/rev/ac6d4d6dfea1
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
Blocks: 567137
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.3a6pre) Gecko/20100616 Minefield/3.7a6pre

Works for the plugin pane case, but we show all the add-ons and not only the ones with the given type. See bug 572653.
Status: RESOLVED → VERIFIED
Version: unspecified → Trunk
No longer depends on: 572653
You need to log in before you can comment on or make changes to this bug.