Closed Bug 1678788 Opened 4 years ago Closed 4 years ago

Preferences window cropped at the right side on open

Categories

(SeaMonkey :: Preferences, defect)

SeaMonkey 2.53 Branch
defect

Tracking

(seamonkey2.53+ fixed, seamonkey2.57esr? affected)

RESOLVED FIXED
seamonkey 2.83
Tracking Status
seamonkey2.53 + fixed
seamonkey2.57esr ? affected

People

(Reporter: srollin2, Assigned: frg)

References

Details

(Whiteboard: SM2.53.6)

Attachments

(4 files)

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.

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

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.

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.

Screen Shots appended as requested.

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.

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?

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?

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.

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.

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?

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → macOS

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.

Assignee: nobody → frgrahl
Status: NEW → ASSIGNED
OS: macOS → Unspecified
Summary: Preferences window not fully open - SM Mac with Catalina → Preferences window cropped at the right side on open

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

Attachment #9191645 - Flags: review?(stefanh)
Attachment #9191645 - Flags: review?(iann_bugzilla)
Attachment #9191645 - Flags: approval-comm-release?
Attachment #9191645 - Flags: approval-comm-esr60?

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.

Flags: needinfo?(frgrahl)

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.

Flags: needinfo?(frgrahl)

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.

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.

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

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

See Also: → 868495

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

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.

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 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?)

Flags: needinfo?(frgrahl)
Attachment #9191645 - Flags: review?(iann_bugzilla)
Attachment #9191645 - Flags: review+
Attachment #9191645 - Flags: approval-comm-release?
Attachment #9191645 - Flags: approval-comm-release+
Attachment #9191645 - Flags: approval-comm-esr60?
Attachment #9191645 - Flags: approval-comm-esr60+

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

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.

Attachment #9191645 - Flags: review?(stefanh) → review+

Pushed by frgrahl@gmx.net:
https://hg.mozilla.org/comm-central/rev/637d1e4e056e
Adjust width in SeaMonkey preferences dialog. r=IanN,stefanh

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Flags: needinfo?(frgrahl)
Whiteboard: SM2.53.6
Target Milestone: --- → Future
Target Milestone: Future → seamonkey 2.83
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: