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

VERIFIED FIXED in mozilla2.0b7

Status

()

defect
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: alice0775, Assigned: mossop)

Tracking

Trunk
mozilla2.0b7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [AddonsRewrite])

Attachments

(13 attachments, 3 obsolete attachments)

286.69 KB, image/jpeg
Details
238.80 KB, image/jpeg
Details
130.94 KB, image/png
Details
193.88 KB, image/png
Details
147.65 KB, image/png
Details
146.16 KB, image/png
Details
146.99 KB, image/png
Details
109.35 KB, image/png
Details
168.25 KB, image/png
Details
152.07 KB, image/png
Details
201.62 KB, image/png
Details
120.38 KB, image/png
Details
15.41 KB, patch
Unfocused
: review+
Details | Diff | Splinter Review
Reporter

Description

9 years ago
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.
Reporter

Comment 1

9 years ago
Posted image screenshot
Dave, can we get this fixed for beta1?
blocking2.0: --- → ?
Can't help but wonder if we just want to crop the title, rather than wrapping it.
Keywords: uiwanted
Reporter

Comment 4

9 years ago
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.
Reporter

Comment 5

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

Updated

9 years ago
blocking2.0: ? → final+
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).

Updated

9 years ago
OS: Windows 7 → All
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.
Reporter

Comment 8

9 years ago
Please provide a tooltip for cropped title.
Assignee

Updated

9 years ago
Whiteboard: [AddonsRewrite]
Assignee

Updated

9 years ago
Assignee: nobody → bparr
Assignee

Updated

9 years ago
Keywords: uiwanted
Assignee

Updated

9 years ago
Assignee: bparr → dtownsend
Assignee

Updated

9 years ago
Depends on: 585950
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?
(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.
Assignee

Updated

9 years ago
Whiteboard: [AddonsRewrite] → [AddonsRewrite][good first bug]
Assignee

Updated

9 years ago
Duplicate of this bug: 595144
Assignee

Updated

9 years ago
Duplicate of this bug: 596393
Posted patch extension.xul mockup patch (obsolete) — Splinter Review
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.
Assignee

Updated

9 years ago
Attachment #475258 - Attachment is patch: true
Could you post a screenshot of how your patch looks in windows of a couple of sizes?
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.
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.
(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.
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.
Posted patch patch rev 1 (obsolete) — Splinter Review
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.
Attachment #478352 - Flags: review?(bmcbride)
Posted patch patch rev 1 (obsolete) — Splinter Review
Wrong patch. This should be good. Also snuck in a fix for the plugin icon not being correct in the detail view.
Attachment #478352 - Attachment is obsolete: true
Attachment #478358 - Flags: review?(bmcbride)
Attachment #478352 - Flags: review?(bmcbride)
Posted patch patch rev 1Splinter Review
*sigh* third times the charm?
Attachment #478358 - Attachment is obsolete: true
Attachment #478358 - Flags: review?(bmcbride)
Assignee

Updated

9 years ago
Attachment #478361 - Attachment description: :Unfocused → patch rev 1
Attachment #478361 - Flags: review?(bmcbride)
Assignee

Updated

9 years ago
Status: NEW → ASSIGNED
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?
(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.
Assignee

Updated

9 years ago
Whiteboard: [AddonsRewrite][good first bug] → [AddonsRewrite][has patch][needs review Unfocused]
Attachment #475258 - Attachment is obsolete: true
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.
Attachment #478361 - Flags: review?(bmcbride) → review+
Hardware: x86 → All
Whiteboard: [AddonsRewrite][has patch][needs review Unfocused] → [AddonsRewrite][has patch]
Assignee

Updated

9 years ago
Whiteboard: [AddonsRewrite][has patch] → [AddonsRewrite][has patch][needs-checkin-post-b7]
Fixed: http://hg.mozilla.org/mozilla-central/rev/0393eb812dde
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite-
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [AddonsRewrite][has patch][needs-checkin-post-b7] → [AddonsRewrite]
Target Milestone: --- → mozilla2.0b8
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
Status: RESOLVED → VERIFIED
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.