1.59 KB, patch
|Details | Diff | Splinter Review|
22.07 KB, image/png
17.76 KB, image/jpeg
18.79 KB, image/png
12.98 KB, image/png
61.24 KB, image/png
41.13 KB, image/jpeg
18.99 KB, image/png
39.90 KB, image/jpeg
20.67 KB, image/png
34.65 KB, image/png
37.40 KB, image/png
1.03 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20020922 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20020922 The new customize toolbar window is incorrectly sized on Linux - Asa told me it looks better on Windows. I will attach a screenshot below. Reproducible: Always Steps to Reproduce:
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Phoenix0.2
Assignee: hyatt → hewitt
I don't see this. I suspect the larger fontsize makes the difference.
Summary: Customize toolbar windows is incorrectly sized → [cust] Customize toolbar windows is incorrectly sized
Unless more people see this...
Target Milestone: Phoenix0.2 → Phoenix0.3
I see this! Running on WinNT, I have "Large Fonts" installed.
OS->All since this seams to be related to large fonts and not limited to Linux.
OS: Linux → All
I use Debian 3.0 sid with fvwm winmgr. Indeed the cust window shows only partially without scrolling bars. I get around it by defining (or having) a resize key and then resizing the window so all the buttons show up. "done" button then rolls up the window after use.
Summary: [cust] Customize toolbar windows is incorrectly sized → [cust] Customize toolbar windows is incorrectly sized when using larger fonts
Target Milestone: Phoenix0.3 → Phoenix0.4
Wanted to add I see this on both Win2k and Linux (RH8). It is only a problem with the larger fonts as far as I can tell.
Try a very large screen font, e.g. -microsoft-Verdana-medium-r-normal--*-120-*-*-p-*-iso8859-1 (Linux) and you have no way to close the dialog. The OK and Cancel buttons are completely outside the dialog, and the dialog remains open even after exiting Phoenix.
*** Bug 174343 has been marked as a duplicate of this bug. ***
*** Bug 176633 has been marked as a duplicate of this bug. ***
Created attachment 104322 [details] [diff] [review] patch This patch resizes the customization window if the content needs more space.
*** Bug 177678 has been marked as a duplicate of this bug. ***
I see this too. I suppose that's because I have only VGA display (shame on me...) Phoenix 0.4, Win 98. Artem Vakhitov
Comment on attachment 104322 [details] [diff] [review] patch Hey Joe, can you take a look at this customize toolbar patch? Thanks.
Attachment #104322 - Flags: review?(hewitt)
With this patch, isn't it possible that the window can be wider than the screen, thus hiding the Done button?
Dean, do you think that's a common case? I don't think that should block our landing this fix for people who have fonts that are slightly or even moderately larger. We need an "escape" key to dismiss the dialog in the case that the window position (or I suppose, really large fonts or a really small screen) forces the dialog off screen. Is that reported?
I agree with Asa's most recent comment. I just looked at Phoenix under 1600x1200. Although i don't normally use that screen resolution, I know some people do. Those people would need to use a larger font size to keep toolbars readable. We really need an elastic box. Failing that, and if scrollbars are not available, the standard Windows command to accept and close a settings window is the Enter key. I'd recommend that.
Asa: You're probably right. And the patch doesn't add the problem, since the done button is barely visible in the screenshot, it just doesn't resolve it.
> We need an "escape" key to dismiss the dialog ... That's a terrible solution. If we can't get this working properly on all platforms and all resolutions then we need to ditch the whiz-bang sheet effect and stick with a standard dialog.
You could temporarily replace the content area with the customisation tools. That way it's still attached to the toolbar (by being part of the same window!) and it can be resized by the user. Of course, it wouldn't really be a dialog/sheet any more, so I suspect the implementation would be nasty, but I don't think it's entirely Crazy Talk.
Is this going to be merged into the main source tree that will become the nightly builds of Phoenix anytime soon? Using the 11/19 nightly I am still encountering this. Maybe the window should be just flagged as resizeable by default... ie so that the WM puts resize bars on the corners?
Created attachment 108297 [details] Screenshot showing the cut-off about dialog Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021202 Phoenix/0.4 It also affects the Help | About Phoenix dialog, which is non resizeable.
I atteched the screenshot above. Phoenix often shows the dialog with wrong size. This window really has 4 buttons but 3 of them are not visible. Steps to reproduce: 1.Launch Phoenix milestone 0.4. or 0.5 undex Windows XP (easier to reproduce) or Windows 2000. 2.Navigate to www.sunhill.ru. You should see the page in Russian. 3.Choose the link in left frame with location https://220.127.116.11/cgi-bin/clients/enter. (It is called "statistics" in Russian, the word of 10 cyrillic leters.) 3.Observe the results. The bug is not always reproducable, but it happens very often under WinXP.
*** Bug 186786 has been marked as a duplicate of this bug. ***
I have noticed that the problem occurs because the icons are in a line, left to right, and the rightmost ones fall outside of the box. OK, this is obvious. Would it be easier to make this customize box if the icons were stacked vertically, with scrollbars, etc.?
*** Bug 189150 has been marked as a duplicate of this bug. ***
*** Bug 187413 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030204 Phoenix/0.5 with the new Nautilus 1.0 theme. The Customize window has a vertical scrollbar. The Qute 1.0 beta theme has the same old problem.
well, from my testing, it seems that the problem is not on the palette box, but is on the row of buttons below the palette box which is too large when the font size is too large, so, my proposed fix for this bug is to break the `buttons bar' apart.
! first saw this on WinME, so it applies to all. It looks like patches are already made... but I think I found something relaited to this bug. (on winME) Help-->about-->Copyright and contributer-->right click on menubar-->cutomize-- >Oh my god, can't close it! so alt-F4 (customization window goes away) --> Menu is all greyed out (on the about: page), it's closable... but it's frustrating and its a bug. Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4a) Gecko/20030321 Phoenix/0.5 It happened the few times that I tried to do it.
> [...] but it's frustrating and its a bug. may be related to bug 170499. BTW anybody can try to see if that patch can solve the problem? i have tried on gtk2, and it seems that the customize windows does not overflow if a set to ~18pt application font size. Furthermore, this patch does _NOT_ address all font size, if user uses insanely HUGE size (say, 26pt), the customize window may still overflow.
how do you apply these patches anyway? I have no idea where to start even!
Created attachment 118195 [details] [diff] [review] customize dialog patch, part 2 of 3 there are three patches concerning customize dialog in total. (bug 178078, bug 171454, bug 171106)
Comment on attachment 118195 [details] [diff] [review] customize dialog patch, part 2 of 3 sorry...
Attachment #118195 - Attachment is obsolete: true
Created attachment 118196 [details] [diff] [review] customize dialog patch, part 2 of 3 there are three patches concerning customize dialog in total. (bug 178078, bug 171454, bug 171106)
Created attachment 118300 [details] custom font size causes dialog box weirdnesses My fonts are set to a custom size (84% -- makes a logical inch on my monitor equivilant to an actual inch), and this causes similar issues, see attachment. I could attach many more examples of this upon request.
Target Milestone: Phoenix0.6 → Phoenix0.7
anybody can take a look at my patch? it is very simple and it seems to fix the problem.
*** Bug 211874 has been marked as a duplicate of this bug. ***
I've looked for ways to implement patches into the Firebird... I think I remember finding something, but couldn't get it to work.. So, How do we try your patch?
Taking QA Contact
QA Contact: asa → bugzilla
Assignee: hewitt → noririty
Noririty, your checkin probably belongs to this bug, not bug 171451. 08/10/2003 04:11 mozilla/ toolkit/ content/ customizeToolbar.css tweak css. b=171451
Steffen: Right. It's still not completely but expected works well.
*** Bug 216092 has been marked as a duplicate of this bug. ***
Using the latest nightly (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030813 Mozilla Firebird/0.6.1+), I now see a scrollbar which allows me to access the elements that do not fit. However, I can not use the mouse wheel to scroll through it. Is this worth a separate bug?
This bug causes usability issues to people with bad sight bacause they set a larger font size by default. Adding the Access keyword.
Why wasn't this marked FIXED? The Customize window now works well with larger fonts.
Created attachment 130112 [details] screenshot: cut-off button in the customize toolbar window There is an issue remaining: The button "Restore Default Set" is cut off.
Attachment #101023 - Attachment is obsolete: true
This it pathetic. This bug is almost one year old, and configuring the latest Firebird release is still a pain in the ass because of the messed up toolbar customize dialog. If you are unable to fix this, couldn't you just make that window a normal, resizable one, instead of this frameless thingie?
Created attachment 134408 [details] [diff] [review] Whiz-bang sheet effect removal patch This patch removes the sheet effect (as suggested by Blake in comment 22) and turns the dialog into a proper, self-sizing dialog. I've tested it at various font sizes (up to 26px) and it always lays out correctly.
Comment on attachment 134408 [details] [diff] [review] Whiz-bang sheet effect removal patch Superreview is currently not needed for mozilla firebird. Since Ben is pretty loaded, moving review request over to Dean.
Attachment #134408 - Flags: review?(dean_tessman) → review?(blake)
I run into this problem with the Dutch translation, i circumvent it by editing the width in the file content/global/customizeToolbar.js from within the toolkit.jar archive. While you work out how to programmatically solve this problem, i'd like to see this be set like the "prefWindow.size" in browser/pref/pref.dtd ...
*** Bug 236359 has been marked as a duplicate of this bug. ***
Created attachment 142896 [details] screen shot of bug In WinXP opening the customize toolbar window. There is no title bar, you can not move the window. The 'done' button can not be clicked. The only solution is Alt+F4.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 with 9pt verdana as my 'message box' font, the text at the bottom "show [icons] use small icons [add new toolbar][restore default set]" gets a horizontal scroll bar, which partially hides the text. 9pt verdana is not much larger than the default font on win2k, but is much easier for me to read, except here! i can upload a screenshot of this if it will help
I'm not convinced we can't do better here. -ing. I'm pretty sure that if someone sat down and thought about it they could come up with a patch that sized correctly.
Flags: blocking1.0? → blocking1.0-
*** Bug 240669 has been marked as a duplicate of this bug. ***
Has no progress been made for this bug? I'm using the latest (0.9.1) under Linux/Gnome/Metacity and have had this issue for ages. The Customize dialog is in a random size and position pretty much every time I open it. People are going on about font sizes etc.. but I don't appear to have done anything from the default and I have this issue.. Is this a window manager issue or are no size considerations being done at all? Anyhow, just wanted to register the fact that this is not limited to Win or Fonts or whatever. I'll have a look at this stylesheet stuff, but if it works, why hasn't this been put into the main releases given that this has been floating around since firefox was called PHOENIX?
can we please review (and possibly land) the patch at comment 53? I've been able to reproduce a variet of wrongly sized "sheet" on windows and especially linux. Currently with default settings on all of the platforms, we get a vertical scrollbar.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0PR+
Whiteboard: [have patch]
blake or ben, can you have a look?
Whiteboard: [have patch] -blake → [have patch] -blake ben
Created attachment 157026 [details] screenshot of bug sometimes it looks as horribly as the screenshot in the attachment. (ff0.9.3)
Created attachment 157160 [details] Wrong sized profilemanager window Text string is hidden behind "Choose Folder ..." button.
Created attachment 157194 [details] Demo of the bug in Firefox 0.9.3 for Linux I just installed Firefox 0.9.3, added the Noia 2.0 theme, and saw this bug when browsing Firefox' features. The first time I opened the Customize Toolbar dialog, it was positioned so that the right side was slightly off-screen, completely hiding the vertical scrollbar and half-hiding the Done button. (I'm just lucky it didn't hide the -whole- Done button!) Without any window decoration, I am unable to properly resize or move the dialog. What I want to know is, what goofball decided to create a dialog box without any window manager support (title, move, resize controls)? And why, given the long history of complaints in this bug, has nothing been done about it?
because its implemented as a sheet, not a dialog/window.
I don't think this should block 1.0 PR. There won't be a l10n impact, since worst-case is that we don't use the Done string and use the built-in OK string. That's not a stopper at this point. The sheet is a much better interface than a dialog is going to be, IMO, and I think its worth holding off and trying to make it work right, instead of killing it. As for the patch, it won't do anythign about the vertical scrollbar, since that will appear depending on the number of items in the toolbar palette. (The patch fixes the palette box to 300px in height, which virtually assures the scrollbar with our current palette.) Fixing that will be dependent on the same careful thought as fixing the rest of this bug, so why make a negative change now? If we have to do something like this for 1.0, then lets wait on that drastic step and try to find a better solution in the meantime. The change is quite low-risk as it stands, so there's no need to rush a decision here.
ok, lets try and get this fixed by 1.0
hu... I was just working on it. I have a patch ready for linux with the animation. I need to test it on windows, but I agree it shouldn't block PR1.0.
*** Bug 258576 has been marked as a duplicate of this bug. ***
Wrong dialog size still present on Linux with 1.0PR, fresh install (new profile, default theme) Same behavior as the 0.9.3 demo attachment.
Created attachment 159343 [details] Screenshot of ridiculously sized customize-toolbar window I'm attaching a screenshot of the customize-toolbar window, as rendered using a fresh profile on my SuSE/KDE desktop. As you can see, the window is rendered in a ridiculous size. I don't know if this is the same bug, or a different one. My screen resolution is 1600x1200. I'm using a medium font size. Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040910 Firefox/0.10
14 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Created attachment 163141 [details] screenshot showing the bug This bug is still present in Firefox/0.10; the screenshot was taken on windows xp with display set to 120dpi.
Indeed, even on Fx 1.0RC1 the selectable options toolbar hangs over the right end when large fonts are selected. You can get at the overhang with a scrollbar in SphereGnome 0.9.8.2 and 0.9.9, but the trouble is that when you use ever larger fonts, the fixed size of the window means that the palette portion gets smaller and smaller. This will be an issue on notebook computers that have high resolutions and small screens. Is there any way to specify the customize window with ex units rather than px units? If so, the box would expand as the fontsize grows larger.
Created attachment 163843 [details] Screenshot of costumization toolbar laid out incorrectly on nl-NL localized build Because 'overflow: auto' is set to the box containing the form elements in the toolbar, the scrollbar runs over those form elements. This is very annoying, because you have to make the toolbar wider to make the scrollbar disappear, instead of higher what you expect you must do.
Reopening, as the bug has not been completely fixed in Firefox 1.0.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 165911 [details] Firefox 1.0/Linux screenshot
Attachment #159343 - Attachment is obsolete: true
If this was fixed in aviary-1.0 is it really still a problem? Marking P2 since a fix was devies once already so it should be low hanging fruit.
Priority: -- → P2
The fix is a kludge, not a proper fix. On my system - Win XP, Large Font option (125%/120px), the Restore Default Button is only half in the window. The problem is exacerbated when larger fonts are chosen. Why would larger fonts be chosen? Well, one user of the SphereGnome Jumbo theme uses a screen resolution of 3820x2400. You would really need large fonts for that. Even with a screen resolution of 1900x1200, if you have a 15-inch laptop display, you'd want larger fonts. I note the window size is in px units. Perhaps if it were sized in ex units it could grow as system font size increases.
I have just looked at the new Netscape browser pre-beta. The Customize window is resizable. This solves every one of my problems with the Customize window.
Created attachment 204142 [details] [diff] [review] move "restore default set" button to bottom left of customize toolbar window By moving the "Restore Default Set" button to the bottom left of the Customize Toolbar window, there is much less chance that some part will fall outside the window because of large font sizes. This also solves an issue mentioned in bug #171106 comment #4 https://bugzilla.mozilla.org/show_bug.cgi?id=171106#c4 (point 11). Clicking this button does have major consequences that can not be undone (not in one step at least), so I think it is reasonable that this button should be placed where it is (in my experience) less accessible: bottom left of the window. I know this will not fix issues with really large font sizes, but it will definitely make those issues less worse.
With recent builds on Linux and Windows, this dialog now appears resizable and a vertical scroll bar appears. That resolves my issue, since I can resize the dialog to accomodate larger fonts. The only potential problem I see is if the dialog width is wider than the screen. But perhaps this bug should be closed, and a new one opened to track that issue. Here are the versions I tried that seem fixed: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060414 CentOS/1.0.8-1.4.1.centos4 Firefox/1.0.8 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20060508 Firefox/22.214.171.124
Seems like the patch Teune van Steeg posted was never reviewed? The problem still exists here on Linux, and I don't use overly huge fonts. 10pt I think. Can we fix this for Firefox 3? ;)
Just discovered that there was a "stop" button available to add to Thunderbird 126.96.36.199 toolbar in WinXP, SP2. It was not seen for years because it was located on the left side of the customize window and was blocked. Only discovered it by increasing the window to full screen, but then couldn't drag it off due to it is in fact full screen! Then discovered that the right side of the window could be stretched and the button became visible. However, the sizing must be hard coded and does not stick on the new size. Very annoying to say the least! If additional info is needed regarding font size, etc., please let me know.
Realized that this bug is for Firefox, not Thunderbird which is my concern. Perhaps it should be refiled as a new bug for TB, or will that be taken care of on your end?
Assignee: noririty → nobody
Status: REOPENED → NEW
Priority: P3 → --
Hardware: PC → All
Whiteboard: [have patch] -blake ben
Target Milestone: Firefox1.0 → ---
This will not block the final release of Firefox 3. Any patch will need unit tests in order to be approved.
Flags: blocking-firefox3? → blocking-firefox3-
patch needs new owner
Component: Toolbars → Toolbars and Toolbar Customization
Product: Firefox → Toolkit
QA Contact: toolbars → toolbars
You need to log in before you can comment on or make changes to this bug.