Closed Bug 400466 Opened 17 years ago Closed 17 years ago

application selector dialog isn't wide enough if there is long file type description

Categories

(Firefox :: File Handling, defect, P3)

x86
Windows Vista
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: wladow, Assigned: jimm)

Details

Attachments

(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101905 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101905 Minefield/3.0a9pre

Application selector dialog (bug 348808) isn't wide enough, when opening this dialog for the FIRST time for content type with long description. If you close and open it again for taht file type, width is correct.

Tested on Windows Vista with en-US and sk latest FX nightlies.

Reproducible: Always

Steps to Reproduce:
1. open Application tab in FX Options window 
2. select content type with long name 
3. select Choose application from drop-down menu
4. Dialog with wrong width is shown
5. click on Cancel button
6. select Choose application from drop-down menu again
7. Dialog with correct width is shown
Version: unspecified → Trunk
I guess maybe we should either wrap these or ellipse them. 

Myk can you give me some feedback on this? Also, weren't we thinking of rolling this dialog into something else for the new content handling? Maybe I can hold off on making any changes.
(In reply to comment #2)
> I guess maybe we should either wrap these or ellipse them. 
> 
> Myk can you give me some feedback on this? Also, weren't we thinking of rolling
> this dialog into something else for the new content handling? Maybe I can hold
> off on making any changes.

We are planning to consolidate the dialogs, but it isn't happening for Firefox 3, AFAIK.  cc:ing dmose for confirmation on that.

In the meantime, I think we should crop these long descriptions, adding ellipses at the end.  cc:ing faaborg for confirmation on that.
Assignee: nobody → jmathies
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached patch patch v.1 (obsolete) — Splinter Review
I went with center crop so users can see both the begining of the file and the  extension.
Attachment #287726 - Flags: review?(myk)
Blocks: 400460
also I nixed the groove at the bottom of the dialog. You can view that here - 

https://bugzilla.mozilla.org/attachment.cgi?id=271748

Since I implemented this the groove has always stood out to me as something that didn't match our other content dialogs, so I took it out to clean things up.
Attachment #287724 - Flags: ui-review? → ui-review?(mconnor)
Comment on attachment 287726 [details] [diff] [review]
patch v.1

>Index: toolkit/components/apppicker/content/appPicker.css

>+    width:250px !important;
>+    max-width:250px !important;
> }
> 
> #suggested-filename {
>     font-weight:normal;
>+    width:250px !important;
>+    max-width:250px !important;
> }

I don't think this is necessary.  I think the crop attribute by itself (or perhaps in conjunction with an align="stretch" attribute) should fix the problem.

Otherwise this looks fine, but I'm not able to test it, as I can't find a testcase that demonstrates the problem.  Do you have one you can point me at?
Comment on attachment 287724 [details]
screenshot - new clipping

Yup, centre clipping ftw!
Attachment #287724 - Flags: ui-review?(mconnor) → ui-review+
I tried the crop attrib alone (and a few other combinations of attribs/css) but it didn't work, the dialog resized to the size of the longest text string. I'll try removing the widths and throw in the align to see what happens. If that doesn't do it though I'd be open to other suggestions.

Attached file test file
Yeah that didn't work either. You either end up with a first time clipped dialog, or a dialgo that stretches out to the length of the text. The widths were the only way I was able to get around this. 
I'm still having trouble testing this.  With or without the patch, I see the same thing when I click the "test file" attachment: a left-cropped name.  It looks like I'm getting the unknowncontenttype.xul dialog instead of apppicker.xul, even though I'm on Windows XP.  Is there anything I need to do to enable the app picker?
When you get the unknown content dialog, click the dropdown and select choose (or browse?), that should bring up the app licker.

Comment on attachment 287726 [details] [diff] [review]
patch v.1

Ok, with help from dmose I found the dialog.  For some reason I was thinking it would pop up instead of the UCTH dialog instead of in addition to it once I click the Browse button.

(In reply to comment #11)
> Yeah that didn't work either. You either end up with a first time clipped
> dialog, or a dialgo that stretches out to the length of the text. The widths
> were the only way I was able to get around this. 

This is because the containing vbox isn't flexible.  If it were, it would expand to fill the space available to the right of the content icon, and the labels would crop themselves appropriately given only the crop attribute without the need to specify explicit widths.

r=myk with that change
Attachment #287726 - Flags: review?(myk) → review+
Note: I filed bug 403982 on inconsistencies in style between the UCTH dialog and the app picker dialog.

Jim: can you add a newline to apppicker.xul when checking it in?
> This is because the containing vbox isn't flexible.

Ok, cool, that worked. Thanks Myk. Patch coming up...

> Jim: can you add a newline to apppicker.xul when checking it in?

added.
No longer blocks: 400460
Attached patch patch v.2Splinter Review
Attachment #287726 - Attachment is obsolete: true
Keywords: checkin-needed
Comment on attachment 289350 [details] [diff] [review]
patch v.2

Requesting approval for this very low-risk appearance fix.
Attachment #289350 - Flags: review+
Attachment #289350 - Flags: approval1.9?
Requesting wanted-firefox3 for this appearance glitch.
Flags: blocking-firefox3?
Attachment #289350 - Flags: approval1.9? → approval1.9+
Checking in toolkit/components/apppicker/content/appPicker.xul;
/cvsroot/mozilla/toolkit/components/apppicker/content/appPicker.xul,v  <--  appPicker.xul
new revision: 1.2; previous revision: 1.1
done

Note: I checked this in without the align="stretch" change, which is unnecessary (I was mistaken earlier in suggesting it).
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: