Closed
Bug 138680
(TruncHApps)
Opened 23 years ago
Closed 22 years ago
Helper Applications preferences panel content exceeds available space and is cut off
Categories
(SeaMonkey :: Preferences, defect)
SeaMonkey
Preferences
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: amyy, Assigned: law)
References
Details
(Keywords: polish, Whiteboard: [adt3])
Attachments
(8 files, 4 obsolete files)
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
jag+mozilla
:
review+
bzbarsky
:
superreview+
blizzard
:
approval+
|
Details | Diff | Splinter Review |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details |
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.
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
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 4•23 years ago
|
||
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.
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.
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 10•23 years ago
|
||
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•23 years ago
|
||
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 13•23 years ago
|
||
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 19•23 years ago
|
||
Comment 22•23 years ago
|
||
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 24•22 years ago
|
||
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 27•22 years ago
|
||
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.
Alias: TruncatedPrefs → TruncHApps
Summary: content in Preferences | Helper applications are slightly cut off → Helper Applications preferences panel content exceeds available space and is cut off
Comment 29•22 years ago
|
||
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 35•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Attachment #98311 -
Attachment is obsolete: true
Comment 39•22 years ago
|
||
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•22 years ago
|
||
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?
Attachment #98434 -
Attachment is obsolete: true
Comment 41•22 years ago
|
||
Doh! self-LART there. The maximum is actually 17em. I had not tested it with a MIME type selected - the icon pushes everything over.
Attachment #98439 -
Attachment is obsolete: true
Comment 43•22 years ago
|
||
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•22 years ago
|
||
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.
Attachment #98442 -
Attachment is obsolete: true
Comment 45•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
good point. Patch looks pretty reasonable, though perhaps you want to set max-width and max-height instead?
Comment 48•22 years ago
|
||
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•22 years ago
|
||
Comment on attachment 98904 [details] [diff] [review] Enhanced patch sr=bzbarsky
Attachment #98904 -
Flags: superreview+
Comment 51•22 years ago
|
||
Boris has done the sr=, can someone r= and a= this so the bug can be closed please?
Updated•22 years ago
|
Comment 55•22 years ago
|
||
parish@ntlworld.com, did you mail someone for review? I'd recommend jaggernaut@netscape.com....
Comment 56•22 years ago
|
||
Comment on attachment 98904 [details] [diff] [review] Enhanced patch r=jag
Attachment #98904 -
Flags: review+
Comment 57•22 years ago
|
||
Now see http://mozilla.org/status/2002-10-23.html for info on asking for approval. ;)
Comment 59•22 years ago
|
||
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•22 years ago
|
||
FWIW, parish's patch also fixes the same GUI problem in Helper Applications in Netscape v 7.0. ---- Bill
Updated•22 years ago
|
Attachment #98904 -
Flags: approval+
Comment 61•22 years ago
|
||
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•22 years ago
|
||
checked in to the trunk for 1.2. parish@ntlworld.com, thank you again for the patch and for your patience.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 66•22 years ago
|
||
Depends. Why is it being cut off? Is it just a matter of fiddling with the textfield length introduced in this patch?
Comment 67•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•