Closed
Bug 485451
Opened 15 years ago
Closed 15 years ago
setting the *titlebarcolor attributes doesn't take effect immediately
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.2a1
People
(Reporter: myk, Assigned: mstange)
References
Details
(Keywords: fixed1.9.1)
Attachments
(2 files)
2.11 KB,
application/x-zip-compressed
|
Details | |
748 bytes,
patch
|
jaas
:
review+
roc
:
superreview+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
When I set the activetitlebarcolor, inactivetitlebarcolor, and titlebarcolor attributes on a top-level window element via setAttribute, the new colors don't get applied to the window titlebar immediately. Instead, they get applied after something else happens in the window, f.e. the window gets resized. I've attached a simple XULRunner testcase. It presents a button that, when pressed, runs the following code: document.documentElement.setAttribute("titlebarcolor", "#ff0000"); document.documentElement.setAttribute("activetitlebarcolor", "#ff0000"); document.documentElement.setAttribute("inactivetitlebarcolor", "#ff0000"); When you press the button in the testcase, the titlebar should turn red, but it doesn't. If you then resize the window, however, the titlebar then turns red.
Reporter | ||
Comment 1•15 years ago
|
||
Note: Personas currently works around this problem using the following code: if (window.windowState != Ci.nsIDOMChromeWindow.STATE_MINIMIZED) { window.resizeTo(parseInt(window.outerWidth)+1, window.outerHeight); window.resizeTo(parseInt(window.outerWidth)-1, window.outerHeight); } That's a pretty wonky experience, though, since it shakes the browser, which is jarring to users.
Reporter | ||
Comment 2•15 years ago
|
||
Assignee | ||
Comment 5•15 years ago
|
||
Attachment #369637 -
Flags: superreview?(roc)
Attachment #369637 -
Flags: review?(joshmoz)
Attachment #369637 -
Flags: superreview?(roc) → superreview+
Attachment #369637 -
Flags: review?(joshmoz) → review+
Assignee | ||
Comment 6•15 years ago
|
||
pushed: http://hg.mozilla.org/mozilla-central/rev/262d44d6e425
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Assignee | ||
Updated•15 years ago
|
Attachment #369637 -
Flags: approval1.9.1?
Assignee | ||
Comment 7•15 years ago
|
||
Comment on attachment 369637 [details] [diff] [review] fix trivial patch, no risk, necessary for bug 485305
Reporter | ||
Comment 8•15 years ago
|
||
Comment on attachment 369637 [details] [diff] [review] fix This would also be very useful on the 1.9.0 branch.
Attachment #369637 -
Flags: approval1.9.0.9?
Assignee | ||
Comment 9•15 years ago
|
||
For the 1.9.0 branch I'd have to create a new patch with changes from bug 439354.
Reporter | ||
Comment 10•15 years ago
|
||
(In reply to comment #9) > For the 1.9.0 branch I'd have to create a new patch with changes from bug > 439354. Given that the majority of Personas users are likely to be on Firefox 3.0 for the next few months, that would be super-useful if it isn't too hard or risky and could land in 1.9.0.
Flags: wanted1.9.0.x?
Reporter | ||
Updated•15 years ago
|
Attachment #369637 -
Flags: approval1.9.0.9?
Comment 11•15 years ago
|
||
Comment on attachment 369637 [details] [diff] [review] fix a191=beltzner
Attachment #369637 -
Flags: approval1.9.1? → approval1.9.1+
Assignee | ||
Comment 12•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d9785d47587a
Keywords: fixed1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•