138680 - (TruncHApps) Helper Applications preferences panel content exceeds available space and is cut off

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Yuying Long]

Reproduce on: 
both 04-19 branch and trunk build on:
Mac10.1.3 with all locales, WinXP-SimpChinese.

Not reproduce on:
Linux RH7.2, WinME-JA

Steps:
1. Go to Edit | Preferences.
2. Navigator | Helper Applications.

Result:
The buttons are cut off in this dialog.

Comment 1

[Yuying Long]

Attachment: screen shot on WinXP-SC

Comment 2

[Kerry Shetline]

If by "buttons" the submitter here is talking about category titles in the list
of categories in the Preferences dialog, I concur.

"Helper Applicatio...", "Tabbed Brows...", "New Page Setti...", etc., are among
the category titles that look like they need just a little more width to be
properly rendered.

Comment 3

[Liz]

Buttons are cut off in Preferences > Cache as well.

Comment 4

[sairuh (rarely reading bugmail)]

i also see this on linux rh7.2, using (en-US version) 2002.05.06.15-1.0.0 comm bits.

it's not just the buttons that are clipped, but also the text in the "plug-in
finder service" section.

over to Bill, who works on the content in this panel, unless that's changed
recently.

Comment 5

[Cees T.]

I only see this when I select a file type with a big "handled by" string.
The Handled by: label extends to outside the window, taking the righthand sides
of the groupboxen and the file type box with it, pushing the buttons next to the
file type box offscreen.

Build 2002051004 on Windows ME.

Comment 6

[Brad Tiffany]

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

Comment 7

[R.K.Aa.]

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

Comment 8

[Martyr]

This occurs on Moz 1.0 RC 2, Mac OS 9.2.x as well. Just looks like we need to
extend the pane over a few pixels and all will be well. 

Comment 9

[Stephen Walker]

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

Comment 10

[Pete Zha]

If there is a file type with a long extension or mimetype, when I click it, the
three buttons(New, Edit, Remove) will disappear.

Comment 11

[Daniele Dellafiore]

Attachment: screenshot moz1.0 win2K

if i select the last helper application (open office) the buttons go out of
window and selection is not showed properly.
I have never noticed this before 1.0
I think this could be related to this bug

using mozilla 1.0, win2K

Comment 12

[sairuh (rarely reading bugmail)]

daniele, what is your screen resolution?

Comment 13

[Daniele Dellafiore]

1152*864*32@75

You see, there are two problems showed in my screenshot.
First, when the path labeled with "Handled by" is too long, it causes the buttons
to go out of window.
The other is that the last selected entry in the list is not showed properly.

Comment 14

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 15

[timeless]

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

Comment 16

[Micheal]

Attachment: A screen shot on Windows 98SE

Windows 98SE, 800x600, 16 Million colors

Comment 17

[Wesha]

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

Comment 18

[timeless]

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

Comment 19

[Stephen Walker]

Attachment: make pfs fit

Comment 20

[Matthias Versen [:Matti]]

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

Comment 21

[Jason Bassford]

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

Comment 22

[Jason Bassford]

From bug 146756:

When looking at an assigned helper application, the right side of the window is
cut off, it cannot be resized, and there are no scrollbars to move it over.

Reproducible: Always
Steps to Reproduce:
1. Edit / Preferences / Navigator / Helper Applications.
2. The window looks fine.  Now click on an existing application helper entry.
(Sometimes you need to click more than one for it to "know" you want it to
display information about the entry - also annoying.)
3. Notice that all content to the right (buttons) are pushed off the screen so
that it's cut off.

Actual Results:  The window is too small and text/graphics are cut off on the
right hand side.

Expected Results:  The window should resize itself to accomodate the content, or
(at least) scrollbars should appear to let the "out of sight" content be brought
into view.

Comment 23

[R.K.Aa.]

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

Comment 24

[Cees T.]

Attachment: Screenshot of textbox

In pref-applications.xul (comm.jar), I replaced 

<label id="handler"/>

with 

<textbox id="handler" style="width: 180px"/>

There's a before pic in bug 159816.

Comment 25

[Greg K.]

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

Comment 26

[sairuh (rarely reading bugmail)]

nominating.

Comment 27

[timeless]

re comment 24
<bz> timeless: that should use the applicationDescription from the MIME info
<bz> timeless: which is a "pretty name" for the program
and of course we should limit its width, but using applicationDescription
instead of fullpath will make this problem much rarer.

Comment 28

[Greg K.]

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

Comment 29

[Cees T.]

Re: comment 27

That would work, but when I check the properties of a .avi file in Explorer, it
says Open with: Unknown application. Prolly just my slightly messed up Windows
ME though.

Now I'm using <textbox id="handler" readonly="true" crop="right" style="width:
183px"/>

Comment 30

[R.K.Aa.]

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

Comment 31

[Jo Hermans]

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

Comment 32

[R.K.Aa.]

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

Comment 33

[timeless]

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

Comment 34

[Boris 'pi' Piwinger]

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

Comment 35

[parish]

Replacing a label with a textbox was the solution to the same problem in
Mail/News headers, bug 91662, so this would seem to be the correct solution here
as well.

Can the change not be committed and this bug marked FIXED so that we get rid of
another (relatively) high-visibility bug that makes Moz/NS look half-finished?

Comment 36

[parish]

Attachment: Change handler label to a textbox

Doh! I think I've found the answer to my own question; CT didn't submit his fix
as a patch, so here it is. (Credit to CT for the fix; I just made the patch)

Comment 37

[Boris Zbarsky [:bzbarsky]]

So... my comments on that are:

1)  Use crop="middle" or at worst crop="end".  crop="right" is a terrible thing to
    inflict on a possibly-BIDI interface.
2)  See comment 27.  You're fixing a symptom; may as well fix the cause at the
    same time.  That should also be a 1-line patch.

Comment 38

[parish]

Attachment: New patch without the "crop" attribute.

Boris, addressing your comments:

1) New patch without the "crop" attribute. "crop" isn't a textbox attribute
   anyway (and it doesn't really make sense).

2) It appears to already use the "pretty name" but, under Windows, this only
   works if the app is registered as a file handler in Windows. For example,
   on my system, application/x-zip-compressed is handled by WinZip which is the

   app registered with Windows for handling ZIP files. On the main Helper page
   the Handled By: field just contains WINZIP32.EXE but in the edit dialogue
   the full path os shown. This only causes problems if the Helper app you wish

   to use is not registered as a file handler under Windows in which case the
   full path is required.

   This isn't a problem under *nix as all programs, or their startup scripts,
   are located in $PATH.

   I don't know about MAC and OS/2 but I expect they employ a similar mechanism

   to Windows.

Comment 39

[timeless]

don't use px, use em.
On macos classic an app will not be longer than 31em.
On windows most apps aren't longer than 8em. The openwith dialog allows ~48em 
for pretty names, but realistically the longest app i have here is 16em 
(QuickTimeUpdater) and the longest i can remember is Corel WordPerfect which 
iirc was <24em.

From the pictures, it looks like 32em should work.

your assertion about unix is a bit silly, path works the same way on unix, 
windows and os/2. I might not have an application (especially a helper app) in 
my path if it will only be used by web browsers.  I think that it's fair to only 
show the filename. If a user wants to find out the full path, then the user can 
click edit.

As for teaching mozilla about how to extract pretty names, someone will file a 
bug and I'll see that someone looks into it.

Comment 40

[parish]

Attachment: Use em instead of px

The largest size you can use is 21em; any bigger and it starts pushing the
buttons out of the window.

> your assertion about unix is a bit silly, path works the same way
> on unix, windows and os/2.

:-( OK, I guess that I don't fully understand how Moz interfaces with the OS to
run external programs. What I was suggesting/implying is that under *nix (well,
FreeBSD at least) when an app is installed its binary, or startup script, is
put in /usr/local/bin which is in $PATH so you can just type <appname> at the
command prompt so Moz doesn't/shouldn't need to be concerned with the location.
Windows of course puts each app in its own directory under Program Files, which
is not in %PATH%, so Moz (an even from the commandline) the actual location is
needed.

By "pretty name" are we talking about Moz's "pretty name" for an app, or the
OS's which, under Windows, is linked to the .EXE in the registry?

Comment 41

[parish]

Attachment: 21em -> 17em

Doh! self-LART there. The maximum is actually 17em. I had not tested it with a
MIME type selected - the icon pushes everything over.

Comment 42

[Chris Lyon]

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

Comment 43

[Boris Zbarsky [:bzbarsky]]

Moz doesn't know squat about PATH yet, unfortunately.

Timeless, why em instead of px?  Given that the whole dialog is px-sized, using
em just seems to be a way of saying "please overflow this dialog if a larger
font size is used"....

Comment 44

[parish]

Attachment: Enhanced patch

Someone applied my patch on a Mac and it still didn't fix it. Looking at the
screenshot he sent me the icon alignment appeared different, and also larger,
than in Windows.

Looking at this closer I found that when no Filetype is selected (or if the
Helper App has no icon) then the labels (Mime Type, etc.) are aligned with the
left hand edge of the list box. When an icon appears they get shifted over to
the right. This, IMO, is bad design; if an icon (or any element) is missing,
the other elements should not move around to fill the space, instead a blank
"placeholder" should remain.

The attached patch adds size and constraint attributes to the vbox that
contains the icon which keeps the elements to the right static. The align and
pack attributes fix the size of the icon box at 40x40 px so an icon larger than
40x40 (if any platform uses these) will be shrunk to fit - not ideal, but a lot
better than the buttons moving partially outside the window (I've tested this
by setting the size to 20x20 on Windows, which uses 32x32 icons).

I've also changed the size of the textbox back to px from em (and reduced it to
175 from 183) as per Boris' comment 43.

Although not really within the scope of this bug I notice that several elements
have flex set to 1. Since the prefs dialogue is a fixed size this seems wrong,
surely the should all remain static?


I've asked the Mac user to test it on his Mac and I'm going to apply it on my
FreeBSD system.

Comment 45

[Boris Zbarsky [:bzbarsky]]

1)  The prefs dialog is not always fixed size (eg on my linux box it's not).
2)  I still feel we should not be displaying the full pathname here.... maybe it's
    just me.

Comment 46

[parish]

Attachment: Mac prefs dialogue

1) Unix/Linux is a special case as the window manager allows the window to be
re-sized irrespective of whether Mozilla allows it or not (which should mean
that this bug isn't really an issue (or not a major issue) on these platforms).


2) I'm inclined to agreee, and mostly it doesn't. On Windows at least it only
appears to show the full path if the app is not a registered file handler in
Windows itself. Mac on the other hand appears have its own naming convention
for the apps (see attached screenshot). The question of extracting "pretty
names" appears to be a separate issue according to timeless in comment 39 but
even so, there is nothing to stop the pretty name being ridiculously long but
if the contents of a GUI element are too big for it then the contents should be
truncated in some way; the other elements in the UI should never be pushed out
of the window because of it.

My patch addresses the problem raised by this bug which is to stop the prefs
dialogue being mangled. I think that a new bug should be filed for the issue of
extracting pretty names as suggested by timeless who said that he would see
that someone looks into it although text being longer than an editbox is the
norm in Windows (try setting the PATH envar in control Panel for an extreme
example) so I don't expect anyone to complain about it.

Comment 47

[Boris Zbarsky [:bzbarsky]]

good point.  Patch looks pretty reasonable, though perhaps you want to set
max-width and max-height instead?

Comment 48

[parish]

Just setting width and height makes the box a fixed size. If you just set
max-{width,height} then the Labels will move the left if no icon is being
displayed, which looks bad. As I said in comment 44 we should have a blank
"placeholder" if no icon is displayed, not move the other elements around to
fill the gaps.

Comment 49

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 98904 [details] [diff] [review]
Enhanced patch

sr=bzbarsky

Comment 50

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

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

Comment 51

[parish]

Boris has done the sr=, can someone r= and a= this so the bug can be closed please?

Comment 52

[Boris Zbarsky [:bzbarsky]]

You don't need a=, but you'll need r= and someone to check this in... 

Comment 53

[Michele Bugliaro]

Attachment: Save as dialog with specific app

Same problem in a Save As dialog, Mac Mozilla 1.2a.

Comment 54

[hirata masakazu]

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

Comment 55

[Boris Zbarsky [:bzbarsky]]

[e-mail], did you mail someone for review?  I'd recommend
[e-mail]....

Comment 56

[jag (Peter Annema)]

Comment on attachment 98904 [details] [diff] [review]
Enhanced patch

r=jag

Comment 57

[Boris Zbarsky [:bzbarsky]]

Now see http://mozilla.org/status/2002-10-23.html for info on asking for
approval.  ;)

Comment 58

[parish]

In comment 52 /you/ said it doesn't need approval.

Comment 59

[Boris Zbarsky [:bzbarsky]]

You're right.  And that was true till October 9.  Starting October 9 and until
1.2 final is released, you need approval.  See http://mozilla.org/roadmap.html,
and sorry for the misunderstanding.

Comment 60

[Bill Strohm]

FWIW, parish's patch also fixes the same GUI problem in Helper Applications in
Netscape v 7.0.

    ----    Bill

Comment 61

[Christopher Blizzard (:blizzard)]

Comment on attachment 98904 [details] [diff] [review]
Enhanced patch

a=blizzard on behalf of drivers for 1.2 final.

Please try to get this in before the morning tree closure on Nov 5, 2002 or
it's going to have to wait until we've finished cutting the branch.

Comment 62

[Boris Zbarsky [:bzbarsky]]

checked in to the trunk for 1.2.  [e-mail], thank you again for the
patch and for your patience.

Comment 63

[Paul Wyskoczka]

nsbeta1+/adt3 per the nav triage team.

Comment 64

[sairuh (rarely reading bugmail)]

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

Comment 65

[José Jeria]

On Mac OS 9, this is still an issue. Reopen or file new bug?

Comment 66

[Boris Zbarsky [:bzbarsky]]

Depends.  Why is it being cut off?  Is it just a matter of fiddling with the
textfield length introduced in this patch?

Comment 67

[Bill Strohm]

Answer to comments #65 and #66:

Parish's patch does fix, under Mac OS 9.1, the main problem caused by this bug,
which is "pushing the radio buttons off the screen" when a long MIME type is
selected and an icon appears. The overall Helper Apps window is still slightly
too small, cutting off a part of the buttons under all conditions (as are many
other windows), but at least the functions can all be accessed now.

Comment 68

[parish]

The problem with cropped buttons is a separate issue. The button text on Macs is
larger and bold than the other text in the dialogue, see
http://bugzilla.mozilla.org/attachment.cgi?id=98934&action=view

I am informed that this is normal in the Mac UI however the prefs dialogue
should be altered to accomodate this. A new bug should be filed.

Comment 69

[sairuh (rarely reading bugmail)]

yeah, even on linux the buttons are still partially cropped.

rs vrfy this one, and filed bug 180942 for the remaining issue of the
partially-cropped buttons.