983689 - Preferences window is not constrained by screen size and cut off on netbooks

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Flex]

Attachment: screenshot_seamonkey_big_window.png

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 (Beta/Release)
Build ID: 20140203230027

Steps to reproduce:

1. Used a netbook with 1024x600. Task bar is fixed on bottom and has 2 rows.

2. Go to preferences or mail-news-preferences.


Actual results:

Preference window usually opens without showing you the "Ok" and "cancel" buttons to end the dialogue.

In the case of the attached screenshot it was the other way round: upper part of the window missing, making it difficult to move the window.


Expected results:

Window should open in a size not exceeding screen size.

Comment 1

[Calvin]

Attachment: Faulty Dialog presentation

Comment 2

[Calvin]

Attachment: Dialog Corrected

Comment 3

[Calvin]

(In reply to Flex from comment #0)

I can (I think) confirm there is a problem with the preferences dialog generation in Seamonkey 2.29.0 NOTE: This fault was definately NOT EVIDENT in version 2.26.1 !

When you open the preferences dialogue on my Win XP SP3 Pro system (screen res set at 1024 x 768) the dialog is rendered with the right hand side "clipped" ie: some of the content is cut off by the right side dialog border - see attachment "Dialog Clipped.png"

If you grab the right hand dialog border and move it slightly right, it suddenly "sanps" to the correct position, and any attempt to resize inwards (left) after this correction is NOT permitted - see attachment "Dialog Correct.png"

Hope this info helps.

Comment 4

[Rainer Bielefeld]

Calvin's observation "ok with 1215150" is confirmed by Bug 1215150 comment #4

So it looks as if this one for SeaMonkey 2.24 might be something different?

@reporter, @Calvin:
Any indications that
a) bug still does exist?
                               and
b) independent from Bug 1215150?

Comment 5

[Calvin]

Hi Rainer,

Thanks for the feedback ! I had been meaning to update this bug report. I have recently found that the underlying culprit for the strange behaviour of the preferences dialogue actually seems to be the "Lightning" calender plugin. If you remove or disable this plugin, the "faulty" preferences dialogue behaviour vanishes on my systems.

I have verified this happens on two different machines (both Win XP SP3 and the latest builds of Seamonkey 2.38.0 with Lightning 4.0.2.1)

Comment 6

[Rainer Bielefeld]

AFAIK there are some thoughts to bundle Lightning with SeaMonkey, in this case this problem might need some more investigation.

Comment 7

[Calvin]

Hi Rainer,

I hope somebody with necessary expertise (presumably somebody from the Lightning team) will have a look at this fault. It would be good news if Lightning was "integrated" into Seamonkey. Most other mail apps now come with calender as a standard feature, so I suppose Seamonkey should follow the trend.

I can confirm the "faulty" behaviour is unchanged as of the present time, using Seamonkey 2.40.0 and Lightning Plugin 4.5b1

Calvin.

Comment 8

[Calvin]

PS: My apologies - I just realised I should have said that I am using the "Modern" theme on Seamonkey. It is possible this has a bearing on the issue. Sorry for not mentioning this sooner - 5 demerit points for me :-(

Comment 9

[rsx11m]

Calvin is indeed talking about bug 1215150, whereas Flex opened this bug for a different reason. Given limited height on a 1024x600 notebook, the prefpane window height may indeed be a problem. With the Windows Classic desktop theme on Windows 7, I get a height of 478px of the Preferences window when opened, expanding to 494px in the Advanced > Mouse Wheel panel. That's with hardware acceleration and DirectWrite font processing disabled in about:config (just type this into the location bar where usually the web site's address is shown and confirm the warning, then you can search all preferences):

   layers.acceleration.disabled = true
   gfx.direct2d.disabled = true

You can also try disabling ClearType font smoothing in the Windows Control Panel. The processed fonts are are known to increase the vertical space. With those settings, even the 494px after expansion should fit into a 600px high notebook window.

Comment 10

[rsx11m]

Comment on attachment 8391249 [details]
screenshot_seamonkey_big_window.png

This is actually bug 507640 - Account Settings Window Is Too Tall to Fit Monitor Screen, a fix for which landed a couple of days ago.

Comment 11

[rsx11m]

Attachment: Direct adaption of bug 507640

This is a direct port of comm-central changeset cc4da076eada but doesn't quite work.

Issue #1: "max-height" overriding "height" works on Linux but not on Windows 7 for some reason, even though the max-height value is added to the node's style attribute per DOM Inspector. I have to make an explicit window.resizeTo() there.

Issue #2: The vbox of the prefpane marks the minimum height to which the window can be reduced, but won't shrink further if you try to drag it. For the Account Settings window, the problem was resolved by allowing an overflow there to scroll, thus no problem in that case.

Comment 12

[rsx11m]

Attachment: Almost functional work in progress

This works for the most part on both Windows and Linux. The actual and permissible screen/dialog sizes are determined and reset if the dialog size exceeds the screen size (with a margin for toolbars and also not to hide the main window underneath completely). This is enforced with an explicit window.resizeTo().

If the desired dimensions of the dialog exceed the available screen size, the content pane is set to an "overflow: auto;" to allow scrolling. This isn't done if the dialog fits, to allow dynamic resizing of the window for certain large panes as introduced in bug 868495. That mechanism is switched off if scrolling was enabled.

The only remaining problem is that the window still opens with dimensions accommodating the minimum height of the prefpane content, despite overflowing being allowed at that time already and the height explicitly requested with the resizeTo() function (and I can manually shrink the window grabbing the edges with the mouse). So, it's a bit puzzling where this is coming from.

Comment 13

[Philip Chee]

> +  let dialog    = document.getElementById("prefDialog");
Or you could use |document.documentElement| This should be more portable.

Comment 14

[Philip Chee]

Also please file a bug with Lightning/Calendar to reduce the widths of their prefpanes. Do we know which prefpane is the culprit?

Comment 15

[rsx11m]

(Quoting Frank-Rainer Grahl from bug 1272888 comment #4)
> The timezone box might be the problem.

Since we are increasing the width over in the other bug, and the prefDialog width stays below 800px, we are probably fine. The problem with that box is that they can't put the menulist below the label, given Thunderbird's height of the prefpane which they've maxed out already. On the other hand, it appears to be tricky to use a horizontal layout when on Thunderbird but a vertical layout when on SeaMonkey.

Comment 16

[Philip Chee]

The enclosing element is a <hbox> adding xul attribute orient=vertical turns it into a vbox. Then change align=center to align=start due to the flip. Anyone want to write an overlay to test this?

Comment 17

[rsx11m]

I've never touched or written an extension myself, thus don't really have a clue how to do that. :-\ Would I file this for SeaMonkey or Calendar?

Comment 18

[rsx11m]

Attachment: Functional patch

Here we go, this works now.

I've changed a couple of things relative to attachment 8755041 [details] [diff] [review]:

(1) I've switched .computedStyle() for .scrollHeight/.scrollWidth, which provide more reliable values if the window isn't fully expanded yet. I'm also confused about apparent different behaviors using inner or outer dimensions for both the computed style and window.resizeTo() between Windows and Linux, thus also replaced the latter with a more consistent .innerHeight/.innerWidth.

(2) The problem with the initial size not allowed to shrink below the minimum was caused by the prefpane > .content-box rule forcing overflow: visible; I've hence introduced a new prefpane attribute "overflow" which is either "auto" or "visible" depending on the intended behavior. The window starts off as "auto" and is adjusted according to the scroll sizes. If they are within permissible bounds of the screen size, the mode switches to "visible" and bug 868495/bug 1215150 are in effect.

(3) Since we have inner widths now consistently everywhere, I'm adding 48px in height to account for the title bar and the lower border, and 24px width for the side borders (which are 2x8=16px on Windows 7, so this leaves some comfortable space).

Comment 19

[rsx11m]

Attachment: Screenshot (large taskbar)

This screenshot shows the patch in action on an 800x600 screen (Windows 7).

With the regular task bar, the dialog doesn't quite fit and the scrollbar becomes visible for the main Browser window. When switching prefpanes, extending the pane's height is disabled, and the scrollbar appears as needed.

Comment 20

[rsx11m]

Attachment: Screenshot (small taskbar)

Here the same with "Small Icons" taskbar setting. The dialog fits now, thus no scrollbar. However, dynamic expansion is disabled as the window is within the 40px safety zone, consequently bug 868495 is not in effect [overflow="auto"].

Comment 21

[rsx11m]

Attachment: Screenshot (Mouse Wheel prefpane)

Coming from attachment 8756178 [details] and switching to the "Mouse Wheel" prefpane, rather than extending the prefpane to fit its contents, the scrollbar reappears.

Doing the same sequence with a screen size larger than about 600px just shows the current behavior of starting off with a fixed size, then dynamically resizing if a pane switched to cannot be accommodated by the current size.

Comment 22

[Philip Chee]

Comment on attachment 8756176 [details] [diff] [review]
Functional patch

Looks good.
r=me, a=me

> +  // Leave some space for desktop toolbar and window decoration.
> +  let maxHeight = window.screen.availHeight - 48;
> +  let maxWidth  = window.screen.availWidth  - 24;

Instead of hard-coding the vertical and horizontal space can we get the padding using this instead?
  window.outerHeight - window.innerHeight;
  window.outerWidth - window.innerWidth;

Comment 23

[rsx11m]

(In reply to Philip Chee from comment #22)
> Instead of hard-coding the vertical and horizontal space can we get the
> padding using this instead?
>   window.outerHeight - window.innerHeight;
>   window.outerWidth - window.innerWidth;

This is not reliable on Linux, thus I'd rather keep it consistent among platforms. Also, I'd like a little extra space to allow getting to title or border of the underlying window, so we shouldn't cover it completely.

Comment 24

[rsx11m]

For reference, bug 507640 defined 30px in height padding for the Account Settings, under the assumption that nobody uses large toolbars or window decorations on a small-screen netbook.

Comment 25

[rsx11m]

On Linux, innerHeight == outerHeight, thus 0px are reported for the window decoration itself
(see bug 581863 and bug 581866, old issue).

I've push this without further changes as http://hg.mozilla.org/comm-central/rev/664eff8ea96f

Comment 26

[rsx11m]

Comment on attachment 8756176 [details] [diff] [review]
Functional patch

Given that bug 1272888 increasing vertical heights in both Windows and Linux has landed on comm-aurora/comm-beta as well, it may be worth considering this fix for the branches too so that all bases are covered.

[Approval Request Comment]
Regression caused by (bug #): bug 1272888 (sort of, basically an old issue)
User impact if declined: preferences window may be truncated on 600px screens
Testing completed (on m-c, etc.): works fine on 2.44 Windows/Linux builds
Risk to taking this patch (and alternatives if risky): low
String changes made by this patch: none

Comment 27

[Philip Chee]

Comment on attachment 8756176 [details] [diff] [review]
Functional patch

a=me a=CLOSED TREE

> On Linux, innerHeight == outerHeight
bummer.

Comment 28

[rsx11m]

http://hg.mozilla.org/releases/comm-aurora/rev/a90c9c5b546d
http://hg.mozilla.org/releases/comm-beta/rev/24c79620e7b7