Closed
Bug 494225
Opened 16 years ago
Closed 16 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•16 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•16 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•16 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•16 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•16 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•16 years ago
|
Attachment #378927 -
Flags: approval1.9.1+
|
|
||
Comment 7•16 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•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
|
|
||
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1-
|
|
Assignee | |
Comment 9•16 years ago
|
||
|
Reporter | |
Updated•16 years ago
|
Whiteboard: [sg:low]
|
|
||
Comment 10•16 years ago
|
||
Keywords: fixed1.9.1
|
|
||
Comment 11•16 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
•