567652 - Long name of extensions/plugins should wrap and on line breaks to avoid horizontal scroll bar

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Alice0775 White]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US;
rv:1.9.3a5pre) Gecko/20100523 Minefield/3.7a5pre ID:20100523040016
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US;
rv:1.9.3a5pre) Gecko/20100523 Minefield/3.7a5pre ID:20100523040016

Long name of extensions/plugins should wrap and on line breaks to avoid horizontal scroll bar on 1024x768 monitor.

Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Resize window to 1024x768 pixels
3. Open Add-ons Manager and Go Plugins pane

Actual Results:
 Horizontal scroll bar appears.

Expected Results:
 Horizontal scroll bar shpuld not appear on 1024x768 monitor.

Comment 1

[Alice0775 White]

Attachment: screenshot

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Dave, can we get this fixed for beta1?

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Can't help but wonder if we just want to crop the title, rather than wrapping it.

Comment 4

[Alice0775 White]

Attachment: screenshot of Detail pane in 1024x768pixels monitor

In Detail View of "RealPlayer(tm) G2 LiveConnect-Enabled Plug-In (32-bit)" plugins.

The detail pane is also with horizontal scrollbar,
In this case " crop the title" is not acceptable.

Comment 5

[Alice0775 White]

A tooltip of the title should be provided, If title crop is cropped.
But i dislike a tooltip.

Comment 6

[Tony Mechelynck [:tonymec]]

Personally I prefer wrapping to cropping. As a workaround (and if addon name is only "a little" too long) use zoom-out (Ctrl+- or View => Zoom).

Comment 7

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Long title wrapped in list view

For the list view, let's crop the title with "..." if it is too long for the row.

For the detail view, let's show the full title.

This is consistent with how we currently handle the description of an add-on.  Also, the ability to scan the list is most important in list view while seeing all relevant information is most important in detail view, so I feel this approach is consistent.

Comment 8

[Alice0775 White]

Please provide a tooltip for cropped title.

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Adding "(Disabled)" to an extension on long(ish) addon/plugin names also causes the list of addons to have a horizontal scrollbar, pushing parts of each extension's information/controls off-screen.

Would that also be fixed by Boriss' patch?

Comment 10

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #9)
> Adding "(Disabled)" to an extension on long(ish) addon/plugin names also causes
> the list of addons to have a horizontal scrollbar, pushing parts of each
> extension's information/controls off-screen.

I think in that case, the title should crop, but the "(disabled)" postfix would remain visible.

Of course, that's only possible assuming we don't go ahead with the suggestion in bug 583965 comment 6. If we do, the "(disabled)" part would also be cropped. Which wouldn't be as nice, IMO.

Comment 13

[Matthew Turnbull [Bluefang]]

Attachment: extension.xul mockup patch

Well, since my bug got duped on the process of adding this attachment, I'll add it here too.

I created a fairly rough mockup of my thoughts. I'm not too familiar with XUL
and I didn't add IDs to the wrapper boxes I created. Basically, it structurally
reorganizes the richlist items, so that it's more flexible horizontally.

I also played around with the presentation of the version string.... Having it
attached to the name, floating right, large font or not, etc... In this
patricular patch, I have the version string in smaller text and floating right.
I'm not sure I like it that way, but I was just playing around.

See Bug 596393 for other thoughts.

Comment 14

[Dave Townsend [:mossop]]

Could you post a screenshot of how your patch looks in windows of a couple of sizes?

Comment 15

[Matthew Turnbull [Bluefang]]

Attachment: Add-ons Manager at ~ 1400x1000

Comment 16

[Matthew Turnbull [Bluefang]]

Attachment: Add-ons Manager at ~ 1024x768

Comment 17

[Matthew Turnbull [Bluefang]]

Attachment: Add-ons Manager at ~ 1024x768 with disabled extension

Comment 18

[Matthew Turnbull [Bluefang]]

Attachment: Same as above, but with a small version number

This is with the actual patch I posted. The only difference between this and the other screenshots is the location of the class="name-container" attribute within the name/version container.

Comment 19

[Matthew Turnbull [Bluefang]]

Attachment: And to round it out, the Add-ons Manager at ~ 800x600

Comment 20

[Matthew Turnbull [Bluefang]]

On a side note, these screenshots are from Linux running GNOME 2.30

I can post a screenshot or two from Windows 7 if you like.

Comment 21

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #13)
> In this
> patricular patch, I have the version string in smaller text and floating right.

Pretty sure we want to keep the version directly after the name, as it is now.

Comment 22

[Matthew Turnbull [Bluefang]]

I don't know. The longer I have it small on the right, the more I like it.

Pretty much every time I'm in the Add-ons Manager, I'm looking for a specific extension or plugin inorder to enable/disable it or edit it's preferences. The version really dosn't play any role in that.

If I had to choose between having the version front-and-center in huge letters, or seeimg more of the name, I would choose the name every time. I mean, the version isn't really even all that useful. It's nice that it's there, but it dosn't help you find an add-on, and it doesn't make sense to sort on it.


Another thing has also been on my mind. Is the "disabled" label realy necessary? It takes up a fair amount of space and IMHO there are better ways to handle it. For exaple, greying out the entry (like in the old Add-ons Manager) and the Enable button seem pretty obvious to mee. If not obvious enough, then add a "blah is disabled" banner like the "blah is incompatible" banner.

Comment 23

[Dave Townsend [:mossop]]

Attachment: patch rev 1

This patch makes better use of the width for the name by putting it into its own hbox with only the date to restrict it. Screenshots to follow.

Comment 24

[Dave Townsend [:mossop]]

Attachment: add-on list with rev 1

Comment 25

[Dave Townsend [:mossop]]

Attachment: updates with rev 1

Comment 26

[Dave Townsend [:mossop]]

Attachment: plugin list with rev 1

Comment 27

[Dave Townsend [:mossop]]

Attachment: plugin detail with rev 1

Comment 28

[Dave Townsend [:mossop]]

Attachment: patch rev 1

Wrong patch. This should be good. Also snuck in a fix for the plugin icon not being correct in the detail view.

Comment 29

[Dave Townsend [:mossop]]

Attachment: patch rev 1

*sigh* third times the charm?

Comment 30

[Matthew Turnbull [Bluefang]]

Is there a reason why the updated date is being squeezed into the name line? Why not move it, from the overly busy name line down, to the creator line (where the creator is the only element on that line)?

[name][version][disabled-postfix][update-postfix]
[creator][date-updated]

Granted it would look a little strange in the plugin list, but this layout should really be optimized for the extension list.


Alternatively, what about my suggestion for replacing the disabled/update postfix with visual queues and/or banners? Or should I file a bug to handle that?

Comment 31

[Dave Townsend [:mossop]]

(In reply to comment #30)
> Is there a reason why the updated date is being squeezed into the name line?
> Why not move it, from the overly busy name line down, to the creator line
> (where the creator is the only element on that line)?

Because that is where it seems to sit best, having it floating in the middle of the right just seems odd like the box is missing something up there.
> Granted it would look a little strange in the plugin list, but this layout
> should really be optimized for the extension list.

This list should be made to look right everywhere, we shouldn't be optimizing for one add-on type if we can avoid it.

> Alternatively, what about my suggestion for replacing the disabled/update
> postfix with visual queues and/or banners? Or should I file a bug to handle
> that?

It should be in a separate bug and I don't really know what you'd use for such a queue, espeically when the update postfix is really meant to be read as a sentence and both of them are right now useful to accessibility software.

Comment 32

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 478361 [details] [diff] [review]
patch rev 1

>+      <xul:hbox>
>+        <xul:vbox align="center" pack="center" class="icon-container">
>+          <xul:image anonid="icon" class="icon"/>
>         </xul:vbox>

This makes the icon center-aligned to the name+creator+description, rather than just name+creator. I think I slightly prefer the old way, but I'm betting this way looks better when using larger icons. Also, the mockups seem to look more like this way.

Although, the placement of the icon in the detail view looks out of place now (its top-aligned to the entire view). Followup fodder?

>+              <xul:hbox class="name-container" align="end">
>+                <xul:label anonid="name" class="name" crop="end" flex="1" xbl:inherits="value=name"/>
>+                <xul:label anonid="version" class="version"/>
>+                <xul:label class="disabled-postfix" value="&addon.disabled.postfix;"/>
>+                <xul:label class="update-postfix" value="&addon.update.postfix;"/>
>+                <xul:spacer flex="5000"/> <!-- Necessary to make the name crop -->
>+              </xul:hbox>

I agree with comment 8 - now the name is being cropped, it really needs a tooltip.

r=me with the tooltip in list view.

Comment 33

[Dave Townsend [:mossop]]

Fixed: http://hg.mozilla.org/mozilla-central/rev/0393eb812dde

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed with builds on Windows and OS X like Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101008 Firefox/4.0b8pre