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.

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.

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.

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.

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.

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.

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?

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)

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

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.

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.

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

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

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

Robert O'Callahan suggests the fix is simply adding "overflow:auto" to XUL <window>, <dialog> etc. This bug needs an owner though.

(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.

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 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.

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

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

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