Closed Bug 1215150 Opened 9 years ago Closed 8 years ago

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

Categories

(SeaMonkey :: Preferences, defect)

SeaMonkey 2.32 Branch
defect
Not set
normal

Tracking

(seamonkey2.44 fixed, seamonkey2.45 fixed, seamonkey2.46 fixed)

RESOLVED FIXED
seamonkey2.46
Tracking Status
seamonkey2.44 --- fixed
seamonkey2.45 --- fixed
seamonkey2.46 --- fixed

People

(Reporter: RainerBielefeldNG, Assigned: rsx11m.pub)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

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"
Attached image screenshot browser preferences (deleted) —
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
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
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: Browser Preferences dialog's contents clipped at the right → UI: Browser Preferences dialog's contents clipped at the right
Version: SeaMonkey 2.38 Branch → SeaMonkey 2.32 Branch
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.
Depends on: 1272888
(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.
Attached patch Probable fix (deleted) — Splinter Review
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.
Assignee: nobody → rsx11m.pub
Attachment #8755081 - Flags: review?(philip.chee)
Comment on attachment 8755081 [details] [diff] [review] Probable fix r=me
Attachment #8755081 - Flags: review?(philip.chee) → review+
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.
Attachment #8755081 - Flags: approval-comm-beta?
Attachment #8755081 - Flags: approval-comm-aurora?
OS: Windows 7 → All
Hardware: Unspecified → All
Attachment #8755081 - Flags: approval-comm-beta?
Attachment #8755081 - Flags: approval-comm-beta+
Attachment #8755081 - Flags: approval-comm-aurora?
Attachment #8755081 - Flags: approval-comm-aurora+
Thanks ewong. Ratty, does your "r=me" in comment #8 imply "a=me" for comm-central?
a=me yup
Status: NEW → ASSIGNED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: