Open
Bug 379402
Opened 18 years ago
Updated 2 years ago
Avoid unreachable controls: ensure maximum window size based on current screen resolution
Categories
(Firefox :: General, defect, P4)
Tracking
()
NEW
People
(Reporter: andisnow, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access, sec-want, Whiteboard: [sg:want?])
Attachments
(1 file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11
When Windows high contrast display settings are enabled, the pushbuttons on dialogs may be missing. This problem was previously reported against the Print Preview dialog. Opening this new bug because it is a more general problem than just the Print Preview dialog. It can happen in any dialog box that becomes too large for the screen.
Reproducible: Always
Steps to Reproduce:
1.Open Windows Control Panel, Accessibility Options, choose Display tab, enable High Contrast, click apply
2. Launch Firefox
3. Select Tools > Options > Content, select the Advanced ... button in the font selection area.
Actual Results:
The three pushbuttons at the bottom of the dialog box are not displayed.
Expected Results:
The dialog box should be coded in such a way that when the fonts enlarge, the widgets re-arrange themselves so that they still fit in the window.
Comment 1•18 years ago
|
||
Hi Andi, that's a rather old version of Firefox. Ancient, by now :)
Would you be willing to install a recent alpha and test?
http://www.mozilla.org/projects/firefox/3.0a4/releasenotes/
Install in a separate directory and close all other versions of Firefox before running.
Blocks: 343205
Comment 2•18 years ago
|
||
BTW, for your daily-use browser you should be up to Firefox 2.0x by now. Try Help -> Check for updates. You might have asked it not to update once or twice.
Reporter | ||
Comment 3•18 years ago
|
||
Hi Aaron,
I upgraded to Firefox 2.0.0.3 and retested with high contrast. The results are exactly the same. The dialog boxes grow too large for the buttons to display on the screen.
Comment 4•17 years ago
|
||
To reproduce Andi's results, it's best to reduce your screen resolution quite a bit.
Changing the bug summary to reflect the most probable solution. If we ensure a max-width and max-height for each window that's not larger than the current screen resolution it should fix this problem.
Summary: Dialog box pushbuttons are missing in high contrast mode → Avoid unreachable controls: ensure maximum window size based on current screen resolution
Updated•17 years ago
|
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•17 years ago
|
Flags: blocking-firefox3?
Comment 5•17 years ago
|
||
This is also bad from a spoofing standpoint - you don't want a window to be able to be resized so that the actual chrome is off screen, allowing spoofed chrome to take its place.
Flags: blocking-firefox3? → blocking-firefox3+
Whiteboard: sg:?
Updated•17 years ago
|
Target Milestone: --- → Firefox 3 M9
Is the problem that we limit windows to the size of the screen? So that when the screen is small enough (measured in pixels) the dialog boxes are too small? And the suggested solution is to make windows bigger than the screen?
Comment 7•17 years ago
|
||
As comment 4 says, I think the problem might be that we *don't* limit windows to the size of the screen. If we did I think the XUL stretching algorithms would hopefully make everything small enough to fit. Something might need to take on a scrollbar.
XUL never squeezes to be smaller if the window is too small to fit the contents, so that would not work. Putting in scrollbars would work though. So is that the proposed solution? If so I think you can do that by setting the appropriate style rules in all dialogs (possibly using xul.css)
Comment 9•17 years ago
|
||
I don't know where to fix it, but if something is too big to fit, scrollbars should probably automatically happen.
Reporter | ||
Comment 10•17 years ago
|
||
I think scroll bars is the only solution - or redesign your dialog boxes so that they have room to grow for the large font system settings but not fall off the screen. On Windows, this is an OS problem. It should prevent the DB from becoming larger than the screen and provide scroll bars if the content is larger than the DB. Or, alternatively, they could add a scroll bar for the "screen" so that when dialog boxes grow too large, the user can scroll the entire screen to see it all and access the buttons.
Comment 11•17 years ago
|
||
Andi, we probably need a generic solution because Mozilla's XUL technology is also used by Firefox extensions and applications. So after we release new dialogs can be authored.
If scrollbars is what we want then it sounds to me like this needs to be fixed at a toolkit level. In some cases we could possibly try to use wrapping, such that toolbar buttons, or dialog buttons line up in multiple lines, rather than always side-by-side.
The latter might require gecko-level changes to XUL, in which case we'd need to know as soon as possible.
Comment 13•17 years ago
|
||
Jonas, I'd like to get some input from mconnor or someone on the UI team.
Comment 14•17 years ago
|
||
Sorry for the bugspam but haven't the Minimo folks probably pondered this issue already?
Updated•17 years ago
|
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Updated•17 years ago
|
Blocks: fox3access
Updated•17 years ago
|
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Updated•17 years ago
|
Priority: -- → P4
Comment 16•17 years ago
|
||
Robert O'Callahan suggests the fix is simply adding "overflow:auto" to XUL <window>, <dialog> etc.
This bug needs an owner though.
Comment 17•17 years ago
|
||
(In reply to comment #16)
> Robert O'Callahan suggests the fix is simply adding "overflow:auto" to XUL
> <window>, <dialog> etc.
It seems "overflow:auto" placed on windows doesn't work properly.
Comment 18•17 years ago
|
||
I think we need that in combination with a fix that automatically changes window placement and size, if necessary.
if (x + width > screenWidth) {
if (width > screenWidth) {
x = 0;
width = screenWidth;
}
else {
x = screenWidth - width;
}
}
Same for y and height.
Comment 19•17 years ago
|
||
Comment 20•17 years ago
|
||
Comment on attachment 292021 [details] [diff] [review]
WIP: 1) Resize windows to screen size if they are too large, 2) Use overflow: auto inside XUL dialogs and prefwindows (wizards already do)
I need help in one place -- for DocumentViewerImpl::SizeToContent() taking the border size of the window into account would be a bit nicer.
However, mWindow->GetBorderSize(borderWidth, borderHeight) just returns 0. Not sure why that is.
Other than that it seems to work quite well.
Attachment #292021 -
Flags: superreview?(roc)
+ // Protect against window size larger than available screen
+ nsCOMPtr<nsIDocument> document;
+ GetDocument(getter_AddRefs(document));
+ if (document) {
Use presContext->Document(), which can't be null.
CheckSecurityLeftAndTop does something similar, but doesn't account for borders, so I guess we can't:
http://mxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#3276
Should share the code to constrain width and height. Not sure where. Maybe in nsIScreen?
Updated•17 years ago
|
Priority: P4 → P3
Updated•17 years ago
|
Priority: P3 → P4
Comment 22•17 years ago
|
||
Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Comment on attachment 292021 [details] [diff] [review]
WIP: 1) Resize windows to screen size if they are too large, 2) Use overflow: auto inside XUL dialogs and prefwindows (wizards already do)
Need revised patch --- see comment #21
Attachment #292021 -
Flags: superreview?(roc)
Updated•14 years ago
|
Whiteboard: sg:?
Updated•14 years ago
|
Whiteboard: [sg:want?]
Updated•10 years ago
|
Target Milestone: Firefox 3 beta3 → ---
Comment 25•6 years ago
|
||
Keywords: sec508
Updated•4 years ago
|
Blocks: fx-high-contrast
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•