Closed
Bug 28985
Opened 25 years ago
Closed 24 years ago
Resizing a dialog window doesn't cause repaint correctly
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: cmanske, Assigned: travis)
Details
(Whiteboard: [PDT+])
1. Start Composer (blank doc ok) 2. Click on the Link button on the toolbar. 3. Click on button that is either "More" or "Fewer" a few times -- the dialog content changes, but doesn't repaint correctly. This (and other) dialogs have a More/Fewer button that expands/contracts the dialog by calling window.sizeToContent. When the window size is contracted, "old" bits are not cleared, obscuring underlying bits. Besides being ugly, this is potentially very dangerous as you can click on what appears to be a button (e.g., "OK"), but you are really interacting with what is behind the dialog. I have a researched this thoroughly with Travis, and the fix is trivial: nsXULWindow::SizeShellTo() is calling nsXULWindow::Size() with the "aRepaint" param set to PR_FALSE, when it should be PR_TRUE.
As cmanske states, I have the fix in hand and reviewed.
Status: NEW → ASSIGNED
Just waiting on checkin approval.
Whiteboard: [PDT+] → [PDT+] waiting on approval to checkin
Fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Whiteboard: [PDT+] waiting on approval to checkin → [PDT+]
Comment 7•24 years ago
|
||
mid-air collision ? / bugzilla cleanup Reopening (current State: verfied and no resolution)
Comment 8•24 years ago
|
||
fixed
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•