The default bug view has changed. See this FAQ.
Bug 561600 (SMAddonMgr)

[Tracker] Implement the New Addons Manager UI for SeaMonkey (about:addons)

RESOLVED FIXED

Status

SeaMonkey
UI Design
P2
normal
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Callek, Assigned: Callek)

Tracking

(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(blocking-seamonkey2.1 final+)

Details

Attachments

(6 attachments, 2 obsolete attachments)

(Assignee)

Description

7 years ago
Created attachment 441328 [details] [diff] [review]
WIP 1
Attachment #441328 - Flags: feedback?(dtownsend)
(Assignee)

Updated

7 years ago
Duplicate of this bug: 555615
Status: NEW → ASSIGNED
Depends on: 553890

Comment 2

7 years ago
Comment on attachment 441328 [details] [diff] [review]
WIP 1

> ; JavaScript components
>+@BINPATH@/components/amManager.js
>+@BINPATH@/components/amContentHandler.js
>+@BINPATH@/components/amWebInstallListener.js

Nit: Please order those alphabetically.

Updated

7 years ago
Blocks: 530102
Depends on: 553169
Ftr, a bunch of bug 553169 patches just landed,
and they seem to have more than the current work-in-progress patch, like:
{
-@BINPATH@/components/nsExtensionManager.js
+@BINPATH@/components/addonManager.js
}
Depends on: 552731
Depends on: 562485
(Assignee)

Comment 4

7 years ago
(In reply to comment #3)
> Ftr, a bunch of bug 553169 patches just landed,
> and they seem to have more than the current work-in-progress patch, like:
> {
> -@BINPATH@/components/nsExtensionManager.js
> +@BINPATH@/components/addonManager.js
> }

Thanks but I was tracking those other changes too. They landed on the branch in the past 48 hours.

Updated

7 years ago
blocking-seamonkey2.1: --- → ?
(Assignee)

Updated

7 years ago
blocking-seamonkey2.1: ? → a1+
Blocks: 563012
Adjusting summary so that I can find this again.

Callek already noted in his patch that the Add-on Manager should open in a tab. One thing to note is that we have the menu item in non-browser windows as well so we should probably focus the browser window and new tab in any case (whether we're coming from e.g. MailNews or a browser window).

Secondly, do we already have a bug for the required Modern changes?

BTW: Bug 465090 is about adding a shortcut for the Add-on Manager to Firefox. I think we should keep an eye on that, too, especially to see whether we can use the same shortcut (in another bug of course).
Summary: Implement the New Addons Manager UI for SeaMonkey → Implement the New Addons Manager UI for SeaMonkey (about:addons)

Comment 6

7 years ago
Well, the first thing is to fix things up so they how somewhat at all, which probably needs packaging and some other ground-laying changes that are in the patch attached here. Even the "open in a tab instead of a window" thing could be yet another bug/patch, IMHO.
Esp. in the light of an alpha freeze upcoming I'd like to see thing sliced a bit, so the meat (or actual cake?) can go in before the icing.
(Assignee)

Updated

7 years ago
Depends on: 562919

Comment 7

7 years ago
Created attachment 443057 [details] [diff] [review]
Apply Theme menu [Checked in]

Note that this requires a fix for at least 563256, and preferably 563241 too.
Attachment #443057 - Flags: feedback?(dtownsend)

Comment 8

7 years ago
The new EM has been backed out, so not blocking a1 on it (unless it relands before we can cut the relbranch)
blocking-seamonkey2.1: a1+ → a2+
Comment on attachment 441328 [details] [diff] [review]
WIP 1

Not a full review of course but this looks good to me. Do you guys have a removed-files.in? You'll probably want to update that too.

>diff --git a/suite/browser/browser-prefs.js b/suite/browser/browser-prefs.js
> pref("xpinstall.whitelist.add.103", "addons.mozilla.org");
> 
> pref("xpinstall.whitelist.add", "update.mozilla.org");

Note that you probably just want to set xpinstall.whitelist.add to addons.mozilla.org. update.mozilla.org doesn't need to be whitelisted anymore and these settings only affect new profiles.

>diff --git a/suite/installer/package-manifest.in b/suite/installer/package-manifest.in

> ; JavaScript components
>+@BINPATH@/components/amManager.js
>+@BINPATH@/components/amContentHandler.js
>+@BINPATH@/components/amWebInstallListener.js
> @BINPATH@/components/contentAreaDropListener.js
> @BINPATH@/components/contentSecurityPolicy.js
> @BINPATH@/components/crypto-SDR.js

Note that we've renamed the amManager.js to addonManager.js.
Attachment #441328 - Flags: feedback?(dtownsend) → feedback+
Comment on attachment 443057 [details] [diff] [review]
Apply Theme menu [Checked in]

This looks good to me
Attachment #443057 - Flags: feedback?(dtownsend) → feedback+
Comment on attachment 443057 [details] [diff] [review]
Apply Theme menu [Checked in]

>+    popup.removeChild(aPopup.lastChild);
Note to self: popup.lastChild
Duplicate of this bug: 565090
(Assignee)

Comment 13

7 years ago
(In reply to comment #12)
> *** Bug 565090 has been marked as a duplicate of this bug. ***

Fwiw I should have _that_ bug fixed before this one is fully fixed, but it was the correct dupe anyway.
(Assignee)

Comment 14

7 years ago
Created attachment 444830 [details] [diff] [review]
pref and packaging [checked in]

Robert, I'm not really sure if I need sr here because of pref changes.

This patch should make (most) things not fail in our nightlies, there is still more work to do here though.

Just requesting feedback from Mossop for sanity, should not block this.
Attachment #441328 - Attachment is obsolete: true
Attachment #444830 - Flags: superreview?(neil)
Attachment #444830 - Flags: review?(kairo)
Attachment #444830 - Flags: feedback?(dtownsend)
(Assignee)

Comment 15

7 years ago
(In reply to comment #9)
> (From update of attachment 441328 [details] [diff] [review])
> >diff --git a/suite/browser/browser-prefs.js b/suite/browser/browser-prefs.js
> > pref("xpinstall.whitelist.add.103", "addons.mozilla.org");
> > 
> > pref("xpinstall.whitelist.add", "update.mozilla.org");
> 
> Note that you probably just want to set xpinstall.whitelist.add to
> addons.mozilla.org. update.mozilla.org doesn't need to be whitelisted anymore
> and these settings only affect new profiles.

Just to be clear, I should remove "xpinstall.whitelist.add.103" and change the "update.mozilla.org" to the addons site instead?
(Assignee)

Comment 16

7 years ago
Created attachment 444831 [details] [diff] [review]
Build Config, and Notification bar [Checked in]
Attachment #444831 - Flags: superreview?(neil)
Attachment #444831 - Flags: review?(kairo)
(Assignee)

Comment 17

7 years ago
Comment on attachment 443057 [details] [diff] [review]
Apply Theme menu [Checked in]

Without yet having tested it, I'm slightly skeptical about the enable code actually enabling the addon. [could be a misunderstanding of the API here too though]  But even if that part is broken, this is much much better than present.
Attachment #443057 - Flags: review+
Comment on attachment 444830 [details] [diff] [review]
pref and packaging [checked in]

>+pref("extensions.webservice.discoverURL", "https://services.addons.mozilla.org/%LOCALE%/%APP%/discovery");
Unfortunately since changed in changeset 08696f911422. sr=me with that fixed.
Attachment #444830 - Flags: superreview?(neil) → superreview+
Comment on attachment 444831 [details] [diff] [review]
Build Config, and Notification bar [Checked in]

>-    if (gPrefs.getBoolPref("xpinstall.whitelist.required"))
>-      return BLOCK;
>-    return ALLOW;
>+    try {
>+      if (!gPrefs.getBoolPref("xpinstall.whitelist.required"))
>+        return ALLOW;
>+    }
>+    catch (e) {
>+    }
>+    return BLOCK;
I don't think we need this change; Mossop moved the pref from xpinstall.js (which no longer exists) to all.js so that it still exists.

>-                if (!this._prefs.getBoolPref("xpinstall.enabled")) {
>+                var enabled = true;
>+                try {
>+                  enabled = gPrefService.getBoolPref("xpinstall.enabled");
>+                }
>+                catch (e) {
>+                }
>+                if (!enabled) {
Same goes for this change.

>-
>+            
Adds whitespace.
Comment on attachment 444831 [details] [diff] [review]
Build Config, and Notification bar [Checked in]

Well, the notification works, and failed installs work, but I couldn't find an add-on compatible with 2.1a2pre ;-)
Attachment #444831 - Flags: superreview?(neil) → superreview+

Updated

7 years ago
Attachment #444830 - Flags: review?(kairo) → review+

Updated

7 years ago
Attachment #444831 - Flags: review?(kairo) → review+
(In reply to comment #15)
> (In reply to comment #9)
> > (From update of attachment 441328 [details] [diff] [review] [details])
> > >diff --git a/suite/browser/browser-prefs.js b/suite/browser/browser-prefs.js
> > > pref("xpinstall.whitelist.add.103", "addons.mozilla.org");
> > > 
> > > pref("xpinstall.whitelist.add", "update.mozilla.org");
> > 
> > Note that you probably just want to set xpinstall.whitelist.add to
> > addons.mozilla.org. update.mozilla.org doesn't need to be whitelisted anymore
> > and these settings only affect new profiles.
> 
> Just to be clear, I should remove "xpinstall.whitelist.add.103" and change the
> "update.mozilla.org" to the addons site instead?

Correct, you may also wish to add the personas site to the whitelist but that is of course your decision, see how we have done here: http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#158

The actual names of the prefs doesn't matter with the new add-ons manager too. Any xpinstall.whitelist.* pref will be read.
Comment on attachment 444830 [details] [diff] [review]
pref and packaging [checked in]

Looks good to me, though as Neil mentioned the discovery URL ended up getting changed again.
Attachment #444830 - Flags: feedback?(dtownsend) → feedback+
(Assignee)

Comment 23

7 years ago
Comment on attachment 444830 [details] [diff] [review]
pref and packaging [checked in]

Pushed with nits: http://hg.mozilla.org/comm-central/rev/52cc56729f2e
Attachment #444830 - Attachment description: pref and packaging → pref and packaging [checked in]
(Assignee)

Comment 24

7 years ago
Comment on attachment 444831 [details] [diff] [review]
Build Config, and Notification bar [Checked in]

Pushed with nit: http://hg.mozilla.org/comm-central/rev/052429ec3c44
Attachment #444831 - Attachment description: Build Config, and Notification bar → Build Config, and Notification bar [Checked in]
(Assignee)

Comment 25

7 years ago
Comment on attachment 443057 [details] [diff] [review]
Apply Theme menu [Checked in]

Pushed with nits: http://hg.mozilla.org/comm-central/rev/3c6a14ad087b
Attachment #443057 - Attachment description: Apply Theme menu → Apply Theme menu [Checked in]
(Assignee)

Updated

7 years ago
Duplicate of this bug: 565676
Created attachment 445291 [details]
screenshot (interim progress report)

Interim progress report for:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100513 Lightning/1.0b2pre SeaMonkey/2.1a2pre
Build ID:   20100513012344

Good points:
- A lot of progress in three days :-) <thumbsup/>
- Both the new URL about:addons and the old one chrome://mozapps/content/extensions/extensions.xul produce the same display. (This is good for people like me, who had "jumped the gun" and were displaying the older version of the addons manager in a tab.)

Not so good but still dogfoodable:
- The layout leaves much to be desired (or is it my favourite theme's fault? Kairo's EarlyBlue). In particular the left side includes too much empty space and the right side is cramped. (see screenshot)
- The new addons manager is slow (several seconds between displaying the chrome and filling the right pane)

Bad points (for the next patches I suppose :-) )
- All extensions wake up enabled (the NS1:userDisabled="true" attributes which may be present in extensions.rdf are not taken into account AFAICT)
- The counts on the tabs in the new addons manager's sidebar are all zero (see left siode of the screenshot).

Overall note:
Full of promises, but not ready for prime time yet.

Personal opinion:
- Too Firefoxy-flashy for my taste, I prefer the former layout with the tabs on top, and the buttons only on the current row.
- Mel will have some work making MR-Tech Toolkit work again with all its addons-manager enhancements (or "hacks", as some will call them).

Comment 28

7 years ago
(In reply to comment #27)

> - Both the new URL about:addons and the old one
> chrome://mozapps/content/extensions/extensions.xul produce the same display.

But if you open the manager with 'Tools->AddOn-Manager' in a SeaMonkey-Trunk-Build, its only open a very small window.

> Bad points (for the next patches I suppose :-) )

Its not possible to install xpi's from your local drive.

Comment 29

7 years ago
Hmm, seems I can't install an addon from the web right now as the notification bar doesn't come up. This is what error console says:

Fehler: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://communicator/content/bindings/notification.xml :: observe :: line 174"  data: no]
Quelldatei: chrome://communicator/content/bindings/notification.xml
Zeile: 174

Try yourself by trying to install one of the 2.1 Alpha 1 themes from http://www.kairo.at/download/mozskins
(In reply to comment #19)
>(From update of attachment 444831 [details] [diff] [review])
>>+    try {
>>+      if (!gPrefs.getBoolPref("xpinstall.whitelist.required"))
...
>>+                try {
>>+                  enabled = gPrefService.getBoolPref("xpinstall.enabled");
Apparently Mossop doesn't believe in default preferences; he only bothered adding xpinstall.whitelist.required to all.js because Firefox's UI needed it. rs=me to add xpinstall.enabled to browser-prefs.js so that our UI works again.
(Assignee)

Comment 31

7 years ago
(In reply to comment #27)
> Not so good but still dogfoodable:
> - The layout leaves much to be desired (or is it my favourite theme's fault?
> Kairo's EarlyBlue).

Part theme, part your personal preferences ;-)

> - The new addons manager is slow (several seconds between displaying the chrome
> and filling the right pane)

I don't experience this, could be a factor of how many extensions you have.

> Bad points (for the next patches I suppose :-) )
> - The counts on the tabs in the new addons manager's sidebar are all zero (see
> left siode of the screenshot).

The "count" is not really that; and the feature that the '0' is attached to is not yet implemented. Its more of a "Get Attention" kind of count, or "These addons were updated" etc. type of thing.  It will be hidden in non-default themes [any that don't take advantage of it].

(In reply to comment #28)
> But if you open the manager with 'Tools->AddOn-Manager' in a
> SeaMonkey-Trunk-Build, its only open a very small window.

Known issue at the moment, I'll be fixing that before a2 is out.

> > Bad points (for the next patches I suppose :-) )
> 
> Its not possible to install xpi's from your local drive.

It is, though there is no "Install" button. You can File->Open the .xpi itself if you desire.

(In reply to comment #30)
> rs=me to add xpinstall.enabled to browser-prefs.js so that our UI works again.

Pushed as: http://hg.mozilla.org/comm-central/rev/225cad32a651
Created attachment 445647 [details]
screenshot with SeaMonkey-Modern theme

In reply to comment #31

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100516 Lightning/1.0b2pre SeaMonkey/2.1a2pre - Build ID: 20100516004718

This is the first (and, so far, only) Linux tinderbox-build since your push in comment #31 (I checked the Mercurial changeset in the tinderbox waterfall; but why isn't the build time reflected in the build ID?). I tested it on a copy of my "live" profile, the same one I used in bug 565090; the technical details of its extensions appear in human-readable HTML form in attachment 444727 [details].

In about:config, xpinstall.enabled is still not listed. Not sure if it ought to be.

I tried to install the NoScript extension (one of those I hadn't yet, whose AMO page didn't say it was incompatible with Sm 2.1a2pre). The install-delay popup came up, there was no addon-manager popup, my addon-manager tab has a new entry, "NoScript: Ready to install". All seems well so far in this respect.

All my extensions are again enabled, disregarding manual disables done before migrating.

The "cramped right-side" layout is also visible in the Modern theme distributed with SeaMonkey, see screenshot. However there is a separate bug about that kind of problems (also seen of Firefox), namely bug 562978, I'll follow layout problems there. I haven't tried the default theme today yet, I'll set it at next restart.

Version numbers of extensions and themes are missing.

The "Show more" button near the right of the EM has no visible effect when clicked, other than alternate between "Show more" and "Show less".

If there is something else you want to have specifically checked, just say what.
Attachment #445291 - Attachment is obsolete: true
P.S. On further check, it seems that most disabled extensions had remained disabled but not (for instance) Firebug.
Created attachment 445650 [details]
screenshot with default theme

OK, with the default theme the "crampedness" is less obvious but mainly because the left part is in larger type. I'd prefer to see more items (of smaller height).

The subjective "slow load" effect is still there, maybe because the new EM appears in two steps: chrome first, then (after a noticeable wait) the content, leading to a subjective reaction like "Oh!... Has it lost all my extensions?... I think it has... Ah no, it fills up." OTOH, IIRC the "old" EM appeared all at once.
Tony, I would assume that you are seeing bug 562933.
(In reply to comment #35)
> Tony, I would assume that you are seeing bug 562933.

ah, thanks for the pointer; though in my case it's when changing from Extensions to Themes or vice-versa, not so much when starting up with about:addons as well as other tabs.

Comment 37

7 years ago
(In reply to comment #27)
> - The layout leaves much to be desired (or is it my favourite theme's fault?
> Kairo's EarlyBlue).

The theme has not yet been updated for this change, though I did some work for it yesterday (available in my public git repo, the 2.1a1 release doesn't have that yet).

> - The counts on the tabs in the new addons manager's sidebar are all zero

Also a theme issue, as they should be hidden, right now by the theme, when the number there is zero.

Comment 38

7 years ago
I am just a user, not a developer, so please forgive me if this comment is out of order in this venue.

From this user's POV:
- the new layout of the add-on manager looks nice to me; it's cleaner and more modern than the old one.
- however, it has lost functionality:
   a. version number of the extensions is not shown (echoing and endorsing #32)
   b. when an extension has its own preference setup, it's not obvious (no button appears until user double-clicks)

In short, I'd rather have the reduced clicking and better discovery of the old manager over the fresh look of the new one.

Wouldn't it be a better trade-off to make the listing for each extension slightly larger, if needed (I'm not sure it would be) and forget about the double-click? I don't think the effort of moving these functions off board (both programming effort and double-clickage for the user) is justified by the really minimal added complexity of leaving them on the initial page.

Thanks...
Of course it will be necesary to make the SeaMonkey-Modern theme work as nicely with the new UI as the default theme (as nicely functionally, I mean, though maybe with a "no-nonsense" look and feel more in line with Netscape / MozSuite / SeaMonkey "traditions"; maybe even with a slightly different layout, such as e.g. a single row of buttons, [See more][Preferences]|elastic space|[Enable/Disable][Uninstall], at the bottom of each entry rather than a cramped set in the right column...). I suppose such work belongs in a different bug; or will it be done here?
(In reply to comment #38)
>    a. version number of the extensions is not shown (echoing and endorsing #32)

Bug 562052.

>    b. when an extension has its own preference setup, it's not obvious (no

Bug 562890.
(Assignee)

Updated

7 years ago
Alias: SMAddonMgr
Summary: Implement the New Addons Manager UI for SeaMonkey (about:addons) → [Tracker] Implement the New Addons Manager UI for SeaMonkey (about:addons)
(Assignee)

Comment 41

7 years ago
Turning this into a tracker, its getting hard to follow as it stands.
(Assignee)

Updated

7 years ago
No longer blocks: 530102
Depends on: 530102
(Assignee)

Updated

7 years ago
Depends on: 566905
(Assignee)

Updated

7 years ago
Depends on: 560449
(Assignee)

Updated

7 years ago
Depends on: 566716
Depends on: 566593
Blocks: 568052
Blocks: 567972
Blocks: 570243

Comment 42

7 years ago
Created attachment 449565 [details] [diff] [review]
package extensions library [Checked in]

The extensions library has been missed in packaging, I stumbled over that when taking a look at package-compare...
Attachment #449565 - Flags: review?(bugspam.Callek)
(Assignee)

Comment 43

7 years ago
Comment on attachment 449565 [details] [diff] [review]
package extensions library [Checked in]

how'd I miss this.
Attachment #449565 - Flags: review?(bugspam.Callek) → review+

Comment 44

7 years ago
Comment on attachment 449565 [details] [diff] [review]
package extensions library [Checked in]

Pushed as http://hg.mozilla.org/comm-central/rev/8b7742f9c3e3
Attachment #449565 - Attachment description: package extensions library → package extensions library [Checked in]
(Assignee)

Updated

7 years ago
Depends on: 571527
(Assignee)

Updated

7 years ago
Depends on: 572049
(Assignee)

Comment 45

7 years ago
The _TRACKER_ here does not block a2.
blocking-seamonkey2.1: a2+ → final+

Updated

7 years ago
Depends on: 580223
(Assignee)

Comment 46

7 years ago
Done here, Bug 568052 remains, and is a final blocker.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

7 years ago
Blocks: 589659
Blocks: 608953
You need to log in before you can comment on or make changes to this bug.