Closed
Bug 494225
Opened 15 years ago
Closed 15 years ago
"ASSERTION: non-opaque color property cannot be stringified" after removing <body>
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: zwol)
References
Details
(4 keywords, Whiteboard: [sg:low])
Attachments
(2 files)
|
112 bytes,
text/html
|
Details | |
|
3.22 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
###!!! ASSERTION: non-opaque color property cannot be stringified: 'Not Reached', file content/html/document/src/nsHTMLDocument.cpp, line 2404 This assertion was added in bug 488649.
|
Assignee | |
Comment 1•15 years ago
|
||
You can get the same effect by executing code in <head>, e.g. just <head><script>document.linkColor;</script></head> suffices to trigger the assertion. I'm looking into it.
|
||
Comment 2•15 years ago
|
||
Oh, this is fun. GetVisitedLinkColor doesn't set its out param in some cases. In fact, whenever mVisitedRule is null. But it always sets rv to a success value. Which means that the value actually returned from this code if !mVisitedRule is random (0 in the case of my debugger right now).
|
|
||
Comment 3•15 years ago
|
||
Oh, and we only hit that codepath if there is no body, of course. And we only have mVisitedRule if someone either sets document.vlinkColor or has a <body vlink="..."> in the document.
|
|
Assignee | |
Comment 4•15 years ago
|
||
This is pretty simple. When there's no body, linkColor/vlinkColor/alinkColor fall back to looking up the property in mAttrStyleSheet (which should die, but that's bug 493881 and probably not suitable for 1.9.1, certainly not during an RC freeze). nsHTMLStyleSheet::Get*LinkColor return NS_HTML_STYLE_PROPERTY_NOT_THERE if the property wasn't set at all, and that's a *success* code. nsHTMLDocument::Get*LinkColor check only for *failure* before passing the color to LegacyRGBToHex. Boom. I shall refrain from editorializing about XPCOM. I've pushed this to the try server.
|
|
||
Comment 5•15 years ago
|
||
Comment on attachment 378927 [details] [diff] [review] fix I was about to suggest this same exact patch.
Attachment #378927 -
Flags: superreview+
Attachment #378927 -
Flags: review?(bzbarsky)
Attachment #378927 -
Flags: review+
|
||
Updated•15 years ago
|
Attachment #378927 -
Flags: approval1.9.1+
|
|
||
Comment 7•15 years ago
|
||
Comment on attachment 378927 [details] [diff] [review] fix a191=beltzner after it stays on m-c for with a green cycle
|
|
||
Comment 8•15 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/f4c8b20a304b
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
|
|
||
Updated•15 years ago
|
Flags: blocking1.9.1? → blocking1.9.1-
|
|
Assignee | |
Comment 9•15 years ago
|
||
https://build.mozilla.org/tryserver-builds/zweinberg@mozilla.com-bug494225/ (for the record)
|
Reporter | |
Updated•15 years ago
|
Whiteboard: [sg:low]
|
|
||
Comment 10•15 years ago
|
||
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/7cea8c54f140
Keywords: fixed1.9.1
|
||
Comment 11•15 years ago
|
||
verified FIXED on debug builds(no assert): Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre ID:20090528130303 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090528 Minefield/3.6a1pre ID:20090528112613
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•