Announce and Discuss the Latest Theme and Extension Releases.
For those who still prefer to use tabs for web pages - this small restatless extension forces Firefox 4 to use a separate dialog window for the Add-on Manager.
In addition to redirecting most internal calls to use the Add-on Manager dialog instead of a tab, it also ensures that any clickable links open properly in the browser and applies a subtle restyle to the Add-on Manager to match its use in a separate dialog.
Please report any problems, even minor issues, I'd like to polish it. Suggestions are welcome too.
Last edited by avatar.ds on February 3rd, 2011, 10:02 am, edited 1 time in total.
This turned out to take a little more effort than I had expected. The Add-on Manager is not designed to be run in a dialog, judging from the usability perspective. Had to resort to some hacky hacks to patch it so that it stops opening new windows for each homepage link. The Discovery page is broken really badly and there seems to be little reason to salvage it since it doesn't feel useful in a dialog unless perhaps it is turned into a full-blown standalone AMO browser, which seems kind of silly for a browser application. Overall styling is quite 10-footish and not easy to change due to a lot of hard-wired XBL bindings.
Tested extensively on Win XP for the 2 days that I spent while developing it, and it works fine for me. Other mileages may vary, though Post your experiences here.
Updated version 0.0b2pre now on AMO, get link in top-most post.
Thoroughly reworked and augmented version:
-[add] Links in extension list now all should open in the top existing browser window instead of new window.
-[add] 'Manage add-ons' button in global options dialog now launches add-on dialog, too.
-[fix] All visual controls in the Add-ons Manager Dialog reverted back to originals meaning no more stylistic glitches (patch now works more subtly).
Summary of what this extension now does:
- Menu item in Tools menu opens Add-ons Manager Dialog instead of opening/switching to add-ons tab.
- 'Manage add-ons' button from global options opens Add-ons Manager Dialog instead of new browser window add-ons tab.
- Links from Add-on Manager Dialog re patched to open/switch to a tab in existing browser window rather than open new window.
- Discovery pane, when viewed in the dialog, is mostly useless and badly broken. Replaced with an opt-out stub for now, with links to Mozilla's discovery web page and AMO proper.
Please report any glitches/misses.
You might be interested in this:
Link to the patch:
https://hg.instantbird.org/instantbird/ ... 2797.patch
Thanks a for the tip, Patrick.
This patch seems to kill off integration of web and dialog history altogether, not sure it bears any benefit now since it was designed to undo effects of bug 591801 which has since been fixed by Mozilla (back/forward buttons work fine for me in the dialog in b9pre... although, on a side note, that doesn't make them any more actually useful for me, except filling the embarassingly large empty space in the left upper corner...) The other possible advantage now would be to try see if it could give a lead to fixing the broken discovery page, and this gets me a little uneasy because even if that page can be fixed, I'm not sure it is worthwhile displaying in the dialog, in the first place.
Ahh yeah sorry about that. Honestly, I don't see much point in the back/forward buttons anyway. You can always navigate backwards using the tabs just as quickly as you can using the back button. As far as the "wasted space" goes, I've published some hacks here:
Anyone is welcome to take what I've done and build on it... it at least gets you a little closer to the old addons manager style. I haven't looked into it, but I don't understand why the discovery pane should be broken at all? It's just a webpage being displayed in a canvas isn't it?
That page spits a lot of warnings into the error console, some of which are quite bad, strange, elusive and seemingly impossible altogether, even though they could possibly explain the resultant erratic display (Warning: XUL box for a element contained an inline img child, forcing all its children to be wrapped in a block. File: https://services.addons.mozilla.org/en- ... e/WINNT#... ) I understand that this page is not release quality yet, so we'll see...
I'm anxious to test your styles on the dialog, but at the moment I hit a number of nasty problems with this patch that make me so confused that I just have to find a solution first
Some of those errors are caused by the fact that Gecko 2.0 has many new or renamed CSS properties, so you cannot view this page in older versions of Firefox... i.e. 3.6.
Uploaded new beta version on AMO.
Quite a substantial and satisfying overhaul of this patch.
* After struggling a lot with various sources potentially launching the add-on manager and re-utilizing the existing chrome window, finally secured that they use a single dialog coherently and without bugs. That includes window.open/window.openDialog for both extensions.xul chrome url and about:addons alias as well as loading about:addons url in a tab. An add-ons tab can still be opened by loading the chrome url directly into it, as I didn't feel the need to severe this as a custom opt-out scenario.
* Text-links placed inside the dialog's chrome, such as add-on homepage and creator link and search results are now patched to open in an existing browser window instead of a new window in a more straightforward and robust way.
* Looks like the discovery page was fixed meanwhile and now displays properly. I removed the stub that hid it and patched the discovery browser to redirect all links to an existing browser window instead of opening new ones for each link. Still not sure it is all that useful in a dialog, but since it now seems to work alright, there's no excuse for unconditionally removing it in this extension.
Please report any bugs/glitches/misses.
It actually works quite well in 3.6 except for some fancy and non-essential visual effects (looks more squarishly). It now works in the dialog too. Not sure whether it comes from a fix on the page itself or in Gecko. The sporadic XUL reflow warning for the <a> elements (which hold entire add-on descriptions boxes inside of them) is now gone, so that is probably how the fix happened, though I'm not sure.
No doubt you can *view* all kinds of things that older versions of Gecko will not properly render, but they will throw up error flags like a mad man.
Just posted a new beta, compatible with 4.0b10pre, and with quite a bunch of internal changes again.
* Non-url links in disco pane should now work as expected instead of trying to open in the browser by themselves.
* Enabling the Add-ons Manager Dialog when there is only one browser window with a single add-ons tab doesn't force suicidal behaviour on that window anymore.
* Compatible with 4.0b10pre/4.0.*.
* The dialog will now restyle quite a little bit. This is a purely dynamic chrome restyle that is barely tested and there's no option to turn the new style off in this beta yet. One side effect is that the application of style can be quite visible due to slowness of Firefox in loading the style from hard drive, but there will be workarounds in future betas.
* The category tab for the user scripts provided by Scriptish add-on is not always loaded. This depends on the way the dialog is launched internally and needs further investigation. This can probably affect any other overlay-based extension.
Checked out my attempt to restyle the dialog on other accounts/computers and was terrified by all the things that went wrong.
Quite embarrassing! I should better have waited until my experiments with preferences for restartless mode are complete so that this visual terror can be turned off...
New beta upload. Not much visually functional changes, but the dialog restyle is now more thorough and hopefully smooth, though I only test it on my two Windows XP computers with various UX themes and font sizes. A minor flicker of the style can still be experienced when opening the dialog as I'm still experimenting with all available options to smoothly apply UI stylesheets in restartless where chrome registry is not available.
Both Stylish and Scriptish are now correctly loaded and displayed in the dialog, but at the cost of a missing proper FF4 icon for the dialog in Windows task switcher(it's substituted for an ungainly generic Windows application icon). I'm going to get this corrected one way or another.
Not catching up with recent changes in the Disco pane because it's now probably going to change frequently before FF4 release.
***Updated link to addon download page at AMO***
Beta 9 pre published to AMO.
> Resolved manager restyling flicker.
> Retracted much of manager restyling. This is an evolutionary change which is unrelated to the flicker bug fix. The manager is still slightly restyled to better match being used in the dialog, just more subtly.
> Resolved wrong dialog task-bar icon.
> Improved handling of discovery pane links. Only links designed to open in a new tab are now redirected to a browser window.
> Improved handling of app-tabs. Pinned add-on manager tabs don't get closed or focused when the manager dialog is launched. Only regular add-on manager tabs get closed.
Still working on:
> No option to completely remove application of the integrated style.
> Sometimes when the default view is Get Add-ons (discovery pane), some chrome overlays such as Stylish and Scriptish will not load completely.
Last time I checked, Firefox 4 was not a project of Mozilla Labs for some daring experiments... However, the Add-on Manager team now appears to be working hard on Bug 625465 which calls for making the items in the add-on list click-through to add-on descriptions. By itself, making the add-on description more easily accessible is a very good thing, and many good things are usually achieved by simply adding a thoughtfully titled button - a ubiquitous, true and tried approach. Instead, what we are going to have soon is a set of click-through items with clickable buttons inside of them! How so? It's interesting to note that Jennifer Boriss, of Firefox 'User experience', in requesting this 'improvement' (let's call it so humbly), devoted arguably more words and letters to rationally reviewing its drawbacks than actually supporting her own position, and still, this change is pushed for because she 'feels' it is good. She writes of her invention: 'The two buttons on each entry essentially are buttons-within-buttons, which is an unusual move that is taken nowhere else in Firefox.' Well, what I feel is that this perfectly rational phrase should stop at 'nowhere else'. And for good reason - it is simply an instance of confusing and hard-to-use UI design. I think it is in a crying opposition to best practices, both on the web and desktop. Links are placed on non-clickable documents and buttons are placed on non-clickable toolbars. It is also worth noting that from the development point of view this change is not a mere toy to implement, because the behaviour requested is not part of standard logic of Firefox UI widget codebase: list views ('richlists') are designed for display and selection of subordinate complex widget items, whereas acting on clicks is a job of basic UI elements such as buttons and menu items. Meanshile there are other burning issues which are even more complicated to resolve, such as back-forward buttons in Add-on Manager still not working for the discovery pane (defeating their purpose). Appears to be a very hectic and disappointing direction of Firefox UI, removed both from realistic resource management and best practices, doesn't it?
Who is online
Users browsing this forum: Bing [Bot] and 1 guest