660187 - Size of the dropdown menus in about:permissions doesn't display entire string

Status: RESOLVED DUPLICATE of bug 623922

(Core :: XUL, defect)

Description

[George Carstoiu]

Mozilla/5.0 (X11; Linux i686; rv:6.0a2) Gecko/20110525 Firefox/6.0a2

The drop-down menu for Store Passwords and Open Pop-Up Windows isn't long enough to display the entire string (see Screenshot 1). This applies only for the Linux build - tested on Windows and Mac also and the drop-downs look normal.

Reproducible: always

Steps to reproduce:
1. Go to about:permissions
2. Observe Store Passwords and Open Pop-Up Windows drop-down menus.

Actual results:
 - the string is cut-off

Expected results:
 - the string is displayed fully

Comment 1

[George Carstoiu]

Attachment: Screenshot 1

Comment 2

[Dan Wolff]

This bug actually has a wider scope, and isn't directly related to about:permissions. Anywhere where dropdowns are shown in the GUI, the longest string(s) of the dropdown are cut off.

Other examples:
1. Go to Edit -> Preferences -> General
2. When Aurora starts: select "Show my windows and tabs from last time"

1. Help -> Change channel: select "Release"

I'm not sure if this applies for all themes though, but it certainly does for the Ubuntu Ambiance theme.

Comment 3

[Daniel Holbert [:dholbert]]

I think Comment 2 is correct about this being a more general issue.
Comment 2's STR seems to have regressed between Firefox 3.6.17 (works) & 4.01 (broken), on my system.

Comment 4

[Asa Dotzler [:asa]]

this is a regression that would be great to fix but we're not going to track it for Firefox 6.

Comment 5

[:Margaret Leibovic]

I'm moving this bug to a different component, since it appears to be a problem with the xul widget, not it's use in the about:permissions page.

Comment 6

[Daniel Holbert [:dholbert]]

Margaret: I humbly suggest that the about:permissions UI may be a special & notable instance of this bug, which may merit a special-case hackaround, for the reasons described below.

I say this because the default values have scary & misleading labels, when truncated.

In particular (as shown in attachment 535592 [details]), the truncated labels
look quite surprising/scary at their *default* values, for these preferences:
   [ preference ]            [ displayed default value ]
   Store Passwords:          All...
   Share location:           Always...
   Maintain Offline Storage: Always...

Users trying out Firefox 6's new features will surely be very surprised to see the above defaults, and may be misled about our privacy settings / priorities.

Comment 7

[Daniel Holbert [:dholbert]]

(note that "All..." is really a truncated "Allow", and "Always..." is a truncated "Always Ask".)

Comment 8

[:Margaret Leibovic]

Very valid points! In that case, I can write a work-around patch for about:permissions, and we can file a xul widget follow-up bug.

Comment 9

[:Margaret Leibovic]

Attachment: patch

Comment 10

[Dão Gottwald [:dao]]

Comment on attachment 536455 [details] [diff] [review]
patch

This doesn't take different locales into account. I also don't really see a reason to take a workaround as long as the feature isn't exposed.

By the way, menulists with only two options are bad user experience and should be radio groups instead. Page Info's Permissions pane generally seems better to interact with.

Comment 11

[:Margaret Leibovic]

(In reply to comment #10)
> By the way, menulists with only two options are bad user experience and
> should be radio groups instead. Page Info's Permissions pane generally seems
> better to interact with.

This would be something for a new bug and UX discussion. This point was raised during the design process, but Boriss's final design used menulists because they are visually similar to the popup notification split menus where the user can also set permissions.

Comment 12

[:Margaret Leibovic]

(In reply to comment #10)
> This doesn't take different locales into account.

I think the main problem is that so much of the word is cut off that it is impossible to identify (or rather, it's identified as something else). I know nothing about what these options would look like in other locales, but I imagine exposing a longer segment of the word could only help, not hurt. I think part of the reason that this regression wasn't discovered until now is that the other menulists in our UI have longer strings, so ellipsizing them doesn't affect their meaning.

> I also don't really see a
> reason to take a workaround as long as the feature isn't exposed.

I agree that this isn't a critical problem as long as this feature is hidden, but if we decide to keep menulists, it will need to be dealt with before it becomes un-hidden. Definitely the best option is to fix the widget, but we should make sure we don't forget about this bug.

Comment 13

[Daniel Holbert [:dholbert]]

Regression range:
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b7pre) Gecko/20100915 Firefox/4.0b7pre
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0caec4ddff74&tochange=f38ef1080bfe

First thing to jump out at me in that range is:
> a796f404ede5	Brad Lassey — bug 585799 - Deal with what are currently popup widgets (e.g. for <select>) in widgetless content processe r=roc

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to comment #13)
> First thing to jump out at me in that range is:
> > a796f404ede5	Brad Lassey — bug 585799 - Deal with what are currently popup widgets (e.g. for <select>) in widgetless content processe r=roc

(looks like that's innocent, actually, from a local targeted build.  Doing some more targeted builds to isolate the cset that broke this...)

Comment 15

[Daniel Holbert [:dholbert]]

ah, found it -- looks like dupe of bug 623922, regressed from bug 566154

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to comment #10)
> Comment on attachment 536455 [details] [diff] [review] [review]
> patch
> 
> This doesn't take different locales into account. I also don't really see a
> reason to take a workaround as long as the feature isn't exposed.

Margaret / Dao: according to bug 623922 comment 2, we can work around this in a cross-locale way by adding the "sizetopopup" attribute.

Dao, given my concerns in comment 6, would you r+ a patch that used this more locale-friendly workaround?

(RE the feature not being exposed -- whether or not we expose it in the UI, we're still intending to ship it, and it's getting exposure from tech press -- it was among the few features highlighted in the "Firefox 6 goes to aurora" articles that I saw)