1678788 - Preferences window cropped at the right side on open

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Rufus]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.5.1

Steps to reproduce:

I installed Seamonkey 2.53.5 under Mac OS 10.15.7 (Catalina) and opened Preferences (I'm using the Modern Theme).

Actual results:

Preferences opens, but the Pane is presented to small for the content - horizontally. If I cursor to the edge (to get a drag arrow) and double click the Pane opens fully.

This also happens with Seamonkey 2.53.5.1.

Expected results:

Preference Pane should be presented fully open when selected without having to stretch the Pane to the correct default size.

Comment 1

[Rainer Bielefeld]

@Reporter
a) Please attach a screenshot
b) and tell your result with Classic Default Theme.
c) Which was the last version with which that worked for you.

Comment 2

[Frank-Rainer Grahl (:frg)]

My understanding is that the Modern theme is shipped but was never really adopted to macOS. Suspect needs a lot of work to be made fully compatible. Maybe stefanh knows about it.

Comment 3

[Stefan [:stefanh]]

Yeah, we've never done any mac-specific changes to the Modern theme. But if it's just the size of the window I suppose the default size could be increased.

Comment 4

[Rufus]

Attachment: Screenshot of Preferences on initial open with short pane.

Comment 5

[Rufus]

Attachment: Screen Shot with Pref pane stretched to contain buttons.

Comment 6

[Rufus]

Screen Shots appended as requested.

Comment 7

[Rufus]

Same thing happens with Seamonkey Default theme; I only have the two built in Themes installed - Seamonkey Modern and Seamonkey Default. I prefer the Modern Theme and have been using it on Macs (and now Windows as well) for more than a decade.

The last release that was working correctly for me in launching Preferences was SM 2.53.4.

Comment 8

[Stefan [:stefanh]]

The width is here: https://searchfox.org/comm-central/rev/5007c6f56b3408f49c1efc203afc2d8ca8552610/suite/locales/en-US/chrome/common/pref/preferences.dtd#14

Comment 9

[Rufus]

So, is there a typo where:

<!ENTITY prefWindowMac.size "width: 62em; height: 41em;">

Should actually read:

<!ENTITY prefWindowMac.size "width: 62ch; height: 41em;">

like in the other two lines before and after?

Comment 10

[Stefan [:stefanh]]

No, that's on purpose (Bug 1272888, comment #30). Nothing have changed regarding this since it was added. Did you use the same MacOS version in SM 2.53.4? What happens if you open preferences using a new & fresh profile?

Comment 11

[Rufus]

Same thing with a new Profile - already tried that. And I'm not invoking the Profile Manager at startup.

Yes, I used both Catalina and Mojave with SM 2.53.4 and didn't really start noticing this until 2.53.5. I'm also aware that there is a lot of weirdness going on with Catalina...but now that you bring it up, I just checked and this is also happening with SM 2.53.5.1 under High Sierra - OS 10.13.6 - on another machine. I'm presently running SM 2.53.5.1 under Catalina and High Sierra on three different machines and seeing this on all three installations. So now I'm back to thinking this is a real SM 2.53.5 bug and far less inclined to blame Catalina.

Comment 12

[Stefan [:stefanh]]

I can actually reproduce this on Sierra, but I don't think the problem is the width. When you open the prefwindow you end up at the browser preferences. Now, if you select the Appearance pane the window width increases and stays to that width.

Comment 13

[Rufus]

Interesting - I'm seeing the same thing under Catalina, however, what I see when the Browser window opens (default) it is short, then after I select Appearance it becomes the size it should be and after that all panes are presented normally (at the changed width) and all contents fit within the pane. Same thing you're seeing.

Maybe the issue is actually that the buttons aren't being drawn where they should be? Or that the pane isn't responding to the location?

Comment 14

[Frank-Rainer Grahl (:frg)]

Confirmed with Catalina too. Suspect after all the recent changes to support later macOS versions it needs to be a bit wider now. I usually see this in localized builds under Windows too when the translated strings are longer. Snaps to the right size as soon as you move the border.

Comment 15

[Frank-Rainer Grahl (:frg)]

I am able to reproduce this with Windows 7 Aero and Server 2016 too. Seems to be caused by Lightning. As soon as you disable it window is fine. I didn't find any specific too long width statements in the Lightning css but assume it just needs a bit more space.
With the Modern theme and Windows 7 Aero the height is also too low and the lower button bar will be cropped too.

Comment 16

[Frank-Rainer Grahl (:frg)]

Attachment: 1678788-prefwidth-2536.patch

[Approval Request Comment]
Regression caused by (bug #): --
User impact if declined: Cropped dialog. Auto adjusts back if you select an item in the tree or the border.
Testing completed (on m-c, etc.): 2.53.6b1 pre Windows and macOS.
Risk to taking this patch (and alternatives if risky): mini-tweak.
String changes made by this patch: 2 for size.

Comment 17

[Stefan [:stefanh]]

Frank, se my previus comment - the width isn't the issue here. The issue is that the window doesn't expand to the full width the first time the window is opened (and the browser pane is selected). You should be able to confirm this if you test with a fresh profile - watch what happens when the window opens and the default pane is selected. Watch then what happens when you select the appearance pane.

Comment 18

[Frank-Rainer Grahl (:frg)]

Frank, se my previus comment - the width isn't the issue here.

Maybe but the patch fixes it for both macOS and Windows. This is width not min-width so it is not expanded with a right padding. I wonder if it does some wrong initial calculation but where? And only when the lightning.xpi is installed. Preferences has auto and width in the dialog. I wouldn't even need to know where to look so just though this is good enough.

Comment 19

[Stefan [:stefanh]]

I don't have a SM build, but what happens if you don't call the OnLoad() function at https://searchfox.org/comm-central/rev/ea46a911666aedc9b7832f27bf0363a32a4a1ae2/suite/components/pref/content/preferences.xul#28? Just a guess, but it does seem to set width/height.

Comment 20

[Frank-Rainer Grahl (:frg)]

Just a guess, but it does seem to set width/height.
You can make the windows much smaller. It has a minimum width. The code tinkers with the inner window.
Tried to remove size but then the initial dialog is too small. So seems both are needed. Size in the xul to set an intial width and resizing in the onload to prevent setting a too small size. I remember now that I tinkered with the code before but to no avail :) Maybe IanN has a clue.

Comment 21

[Stefan [:stefanh]]

It is actually the OnLoad() function that causes this, removing it makes the width correct upon first launch.

Comment 22

[Frank-Rainer Grahl (:frg)]

Attachment: Capture.PNG

If you remove the OnLoad() you can do this which probably also not what we want.

Basic problem seem to be the innerWidth/-Height assignments. Later replacement code in Bug 1601812 does not work correctly too.

Comment 23

[Stefan [:stefanh]]

It's really odd. I don't see anything wrong with how the width is computed/set...

Comment 24

[Stefan [:stefanh]]

Hmm, it's actually the 'dialog.setAttribute("overflow", "visible");' line that causes this, removing it makes the problem go away. Atm I don't understand why, though.

Comment 25

[Nuno Silva [:njsg]]

I think that (at least when overflow is "visible" and this problem happens) the size calculations in OnLoad() do not have the final values of document.documentElement.scrollWidth and scrollHeight.

Comment 26

[Ian Neal]

Comment on attachment 9191645 [details] [diff] [review]
1678788-prefwidth-2536.patch

[Triage Comment]
I think this makes the issue less likely to happen but doesn't fix the underlying issue. r/a=me but needs testing on a mac (does Bill's build contain this patch yet?)

Comment 27

[Stefan [:stefanh]]

How about setting a min-height/min-width instead and not doing the 'dialog.setAttribute("overflow", "visible");' stuff?

Comment 28

[Stefan [:stefanh]]

Comment on attachment 9191645 [details] [diff] [review]
1678788-prefwidth-2536.patch

Alright then, I give up :-). I tested the patch on 2.53.5.1 source with MacOS 10.12.6.

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/637d1e4e056e
Adjust width in SeaMonkey preferences dialog. r=IanN,stefanh

Comment 30

[Frank-Rainer Grahl (:frg)]

https://gitlab.com/seamonkey-project/seamonkey-2.53-comm/-/commit/49c49393c519512acc7f3447038d7ebaca88fb65
Adjust width in SeaMonkey preferences dialog. r=IanN,stefanh a=IanN