112180 - OK/Cancel buttons pushed off (and long full path to app) bottom of Downloading dlg when Chosen Application string is too long

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect, P2)

Description

[fruit1]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112020

When downloading a file like a pdf, if a new application is chosen to open it,
if the name of the new application overflows the original line(s), which it
usually will since the path is included in the application name, the text area
appears to intrude onto the bottom row of buttons, disabling them.  This makes
it impossible to complete the download or even to dismiss the dialog.

Reproducible: Always
Steps to Reproduce:
1. download a file, like a pdf.
2. choose a new application to open it from the download dialog that has a long
pathname.
3.

Actual Results:  The text area intrudes on the bottom buttons, disabling them.

Expected Results:  The bottom buttons should not be partially erased by the text
area and should still be active.

Comment 1

[sairuh (rarely reading bugmail)]

hi, could you pls attach a screenshot? thx!

i think i might've seen this before...but iirc, the buttons aren't really
disabled --they're certainly horribly drawn, but if you click around 'em
eventually they'll respond...

Comment 2

[Bill Law]

Resetting component.  Looks like a MacOS X problem?

Comment 3

[John Morrison]

Attachment: screenshot; is this the situation you are describing?

Comment 4

[John Morrison]

Assuming the screenshot above describes the situation in this bug report, 
this is not a Mac OS/X problem (screenshot is windows).

I think that anyway you look at it, stuffing a very long filename back into the 
label of the radio is going to "grow" the document (as it should), which pushes 
the bottom of the document out below the bottom edge of the window (which 
doesn't automagically resize, by design). 

I think this is an apps issue; need to make some provision in the xul for 
dealing with a long filename (maybe easiest just to chop the string if it's 
too long; perhaps though there is some way with crop and/or maxheight|width).

Note that there is another way this fails: if there are no spaces in the path,
then the right hand side of the document is what gets pushed offscreen (i.e,
can't access the 'Choose...' button).

back to File Handling (cc: blake if he knows any magic way to make the radio 
label "do the right thing")

Comment 5

[Bill Law]

OK, John.  I guess I'm stuck with this after all.

How about truncating the file name at xx bytes (appending "...")?  We do that 
kind of thing elsewhere.

Comment 6

[John Morrison]

:-]

One other option is just to display 'fooBarApp.exe' with no path, if path
is greater than NN characters. (In fact, on windows at least, the exe name
is all that is shown in the dialog when you reopen it after redefining the 
handler app).

Comment 7

[fruit1]

Attachment: Here's a screenshot

I'm including a screenshot (OS X).

I tried again and it looks like you're right.  What's actually happening is
that the true location of the button is about a half width below the apparent
location of the button and a tad to the left.  So it will work if you click
beneath it's apparent location or on its lower edge.  The true button location
actually appears for a moment when activated.  Still a problem but not fatal.

Comment 8

[sairuh (rarely reading bugmail)]

*** Bug 114174 has been marked as a duplicate of this bug. ***

Comment 9

[Peter Trudelle]

nsbeta1+ per Nav triage team, should fix in the easiest, safest manner possible,
such as suggested truncations.

Comment 10

[Bill Law]

The revised helper app dialog per bug 86640 will take care of this problem.  It 
puts the name of the application in a <textbox> so it can't cause this resizing 
problem.

Comment 11

[Peter Trudelle]

->ben

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

Accepting. Patch shortly....

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

resummarize

Comment 14

[Peter Trudelle]

nsbeta1- per Nav triage team

Comment 15

[sairuh (rarely reading bugmail)]

nominating...

Comment 16

[hirata masakazu]

By the way, this is not MacOSX only problem. Though less severe, MacOS9.x builds
show the same problem.

Comment 17

[sairuh (rarely reading bugmail)]

*** Bug 137616 has been marked as a duplicate of this bug. ***

Comment 18

[sairuh (rarely reading bugmail)]

another side effect of this bug which badly affects the Helper Applications pref
panel: when i encounter the "full path to chosen application" problem in the
Downloading (helper app) dlg, i'm unable to effectively edit from the Helper
Applications pref panel.

why? the full path makes the content of the panel stretch far to the right --so
far that the New, Edit, Remove *and* Reset buttons are no longer visible. the
Preferences window is [currently] not resizeable, at least on platforms such as
win32 and mac os. this makes it nearly impossible to edit or remove such a mimetype.

i'll attach a screenshot which illustrates this problem.

the workaround would be to edit the mimetype via the helper app dlg, not the
preferences panel. unless you've turned off the "always ask me" checkbox --which
makes things more difficult since Reset will be missing when this mimetype is
selected in the pref panel. *then* the workaround is to somehow move focus
(don't select or highlight) off of that mimetype, so that the Reset button appears.

Comment 19

[sairuh (rarely reading bugmail)]

Attachment: screenshot of affected Helper Apps pref panel

note how the New, Edit, Remove and Reset buttons are now missing from (clipped
off of) the pref panel.

Comment 20

[Boris Zbarsky [:bzbarsky]]

The pref panel is covered by bug 138680 (has a patch).

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 160638 has been marked as a duplicate of this bug. ***

Comment 22

[Boris Zbarsky [:bzbarsky]]

*** Bug 167755 has been marked as a duplicate of this bug. ***

Comment 23

[Boris Zbarsky [:bzbarsky]]

OK. We have three options here:

1)  Wait for 86640 to land
2)  Use the leafName of the app only, not the full name
3)  Call sizeToContent() when the appname changes.

I kinda like item #2 as a temporary measure....

Comment 24

[Stefan [:stefanh]]

*** Bug 166230 has been marked as a duplicate of this bug. ***

Comment 25

[Stefan [:stefanh]]

*** Bug 159378 has been marked as a duplicate of this bug. ***

Comment 26

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 27

[Stefan [:stefanh]]

*** Bug 173584 has been marked as a duplicate of this bug. ***

Comment 28

[Torben]

*** Bug 170042 has been marked as a duplicate of this bug. ***

Comment 29

[Torben]

*** Bug 179049 has been marked as a duplicate of this bug. ***

Comment 30

[Boris Zbarsky [:bzbarsky]]

*** Bug 165052 has been marked as a duplicate of this bug. ***

Comment 31

[Boris Zbarsky [:bzbarsky]]

*** Bug 181435 has been marked as a duplicate of this bug. ***

Comment 32

[Boris Zbarsky [:bzbarsky]]

*** Bug 184370 has been marked as a duplicate of this bug. ***

Comment 33

[Boris Zbarsky [:bzbarsky]]

OK.  I see two options here:

1)  call sizeToContent() after the path is picked (I dislike this)
2)  don't show the whole path  (I sorta dislike this too)

There are facilities within XUL for cropping off the leading part of a radio
button label, no?

Anyone have any other suggestions?

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

bz: yes, you could use crop="start". however, crop="center" might be a better
idea... not sure...

Comment 35

[R.K.Aa.]

*** Bug 185548 has been marked as a duplicate of this bug. ***

Comment 36

[u60234]

*** Bug 187669 has been marked as a duplicate of this bug. ***

Comment 37

[Boris Zbarsky [:bzbarsky]]

*** Bug 188531 has been marked as a duplicate of this bug. ***

Comment 38

[sairuh (rarely reading bugmail)]

i think this particular bug is fixed now, but another has been introduced: bug
189076. resolving this one...

Comment 39

[Chris Petersen]

Great to finally see this issue getting fixed. Confirming issue has been fixed
on both the CFM (2003-01-12-03) and Mach-O (2003-01-14-07) trunk builds.

Comment 40

[Boris Zbarsky [:bzbarsky]]

*** Bug 177546 has been marked as a duplicate of this bug. ***

Comment 41

[Boris Zbarsky [:bzbarsky]]

*** Bug 194110 has been marked as a duplicate of this bug. ***

Comment 42

[Mark Leverson]

This bug can't be checked anymore because the decorpressing option goes straight
to decompress and the reset for file-opening option has been removed from the
helper applications preferences.

Comment 43

[Boris Zbarsky [:bzbarsky]]

It's been removed because now you can edit any type you want directly in the 
settings for that type.