1215150 - UI: Browser Preferences dialog's contents clipped at the right

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Rainer Bielefeld]

Steps how to reproduce  with  en-US (German language pack) SeaMonkey 2.38  (Windows NT 6.1; WOW64; rv:41.0)  Gecko/20100101 Firefox/41.0 Build 20150923195647  (Classic Theme) on German WIN7 64bit:

1. Launch Browser
2. Menu 'Edit → Preferences → Browser'
   Bug: text clipped, some buttons at the right completely missing

Additional information:
a) when you drag and drop right dialog border to the right, the border 
   "jumps" few cm to the right until dialog width is appropriate.
b) further opening of 'Edit → Preferences' always will show dialog with
   sufficient width
c) after exit SM  → redo from stip 1 bug is back
d) "Bug 315676 - preferences window is too small for the content" 
    also should be checked, but I think that one was concerning different
    effects.
e) might be much older than Version 2.38, I did not check
f) Might be related to theme, system font and similar
g) This one blocks "Bug 133627 - (prefsfit) Ensure all Preferences panes 
   fit entirely within the pane area using all bundled themes"

Comment 1

[Rainer Bielefeld]

Attachment: screenshot browser preferences

c): There seem to be additional dependencies, currently I can't reproduce 
    observation "back after exit  → relaunch"
h) After step 2 I can drag and drop right border of the dialog too the left, 
   auto break of UI texts works fine, but at the end text will exceed buttons and 
   other exceeding contents problems might appear.
i) currently I can't reproduce the view of the screenshot, that only was 
   visible after installation of SM 2.38

Comment 2

[Rainer Bielefeld]

I found a way to reproduce screenshot view with "Modern" and "Classic" and "Early Blue" theme:
11. Launch Brower (English, if you want)
12. Menu 'Edit → Preferences'
13. Drag and drop right Browser Preferences dialog border to the left
    as far as possible
13. For Appearance, Contents, Fonts also drag and drop right border as far
    as possible to the left
14. Only view Colors, Spelling, Browser, History with click on item in
    Category Pane
15. in Category Pane click “Browser”
    Bug: looks like in screenshot

j) This reproduces the problem for me in at very most attempts.
k) No significant differences between Themes “Classic”, “Modern”, “Early Blue” 
l) also "History" and "Spelling" can show similar damages after particular
    proceeding

Comment 3

[u331436]

Confirmed with SM nightly and Alpha on Windows platform (Modern theme).
The edit --> preferences menu is clipped on the right, can be resized though.

As far as I can remember without bisecting, this started a few weeks ago (~2 months ??). not sure though.

Comment 4

[Rainer Bielefeld]

Already REPRIDUCIBLE with German SeaMonkey 2.32.1 Build 20150204202218 on German WIN7 64bit

Was still ok  with EN-US SeaMonkey 2.26  (Portable) Gecko/20120604 Firefox/13.0 Build 20140428215944 ( Classic Theme) on German WIN7 64bit 

NEW due to Comment 3

Comment 5

[rsx11m]

The specific issue should go away with bug 983689 adjusting the pane width for Lightning.

Ideally, the Preferences window should pre-populate all prefpanes at startup and then determine width and height based on the largest pane, rather than having fixed values, but I see where this could pose a performance issue with prolonged startup time for the dialog.

Comment 6

[rsx11m]

(In reply to rsx11m from comment #5)
> The specific issue should go away with bug 983689 adjusting the pane width for Lightning.

Make that bug 1272888, the other bug was opened for a different reason and got mangled with this topic. Sorry for the noise.

Comment 7

[rsx11m]

Attachment: Probable fix

I ran into this while investigating bug 983689. Linux is not affected by the issue described here, and this patch fixes it for me on Windows 7. It extends prefwindow's syncTreeWithPane method by not only adjusting the window height when it doesn't fit the scroll height (as introduced by bug 868495) but also the window width when it can't accommodate the scroll width.

Comment 8

[Philip Chee]

Comment on attachment 8755081 [details] [diff] [review]
Probable fix

r=me

Comment 9

[rsx11m]

Comment on attachment 8755081 [details] [diff] [review]
Probable fix

[Approval Request Comment]
Regression caused by (bug #): bug 516026 (makes this more relevant)
User impact if declined: preferences may not be accessible
Testing completed (on m-c, etc.): works on 2.45 and 2.44 builds
Risk to taking this patch (and alternatives if risky): low
String changes made by this patch: none

I'm requesting branch approval for this patch despite bug 1272888 increasing the window widths, e.g., if localized versions or odd fonts require dynamic width adjustments despite that change.

Comment 10

[rsx11m]

Thanks ewong. Ratty, does your "r=me" in comment #8 imply "a=me" for comm-central?

Comment 11

[Philip Chee]

a=me yup

Comment 12

[rsx11m]

http://hg.mozilla.org/comm-central/rev/d78cd91cc659
http://hg.mozilla.org/releases/comm-aurora/rev/a88a6a88c599
http://hg.mozilla.org/releases/comm-beta/rev/9cddd560b0e1