379402 - Avoid unreachable controls: ensure maximum window size based on current screen resolution

Status: NEW

(Firefox :: General, defect, P4)

Description

[Andi Snow-Weaver]

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

[Aaron Leventhal]

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.

Comment 2

[Aaron Leventhal]

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.

Comment 3

[Andi Snow-Weaver]

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

[Aaron Leventhal]

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.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[Aaron Leventhal]

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.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[Aaron Leventhal]

I don't know where to fix it, but if something is too big to fit, scrollbars should probably automatically happen.

Comment 10

[Andi Snow-Weaver]

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

[Aaron Leventhal]

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. 

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[Aaron Leventhal]

Jonas, I'd like to get some input from mconnor or someone on the UI team.

Comment 14

[Flaky Jake]

Sorry for the bugspam but haven't the Minimo folks probably pondered this issue already?

Comment 15

[Aaron Leventhal]

Flaky, no -- Minimo doesn't use XUL for UI.

Comment 16

[Aaron Leventhal]

Robert O'Callahan suggests the fix is simply adding "overflow:auto" to XUL <window>, <dialog> etc.

This bug needs an owner though.

Comment 17

[alexander :surkov (:asurkov)]

(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

[Aaron Leventhal]

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

[Aaron Leventhal]

Attachment: WIP: 1) Resize windows to screen size if they are too large, 2) Use overflow: auto inside XUL dialogs and prefwindows (wizards already do)

Comment 20

[Aaron Leventhal]

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.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+   // 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?

Comment 22

[Mike Connor [:mconnor]]

Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 25

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381