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)

Product:
Core
Component:
Layout
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jruderman, Assigned: zwol)

References

Details

(4 keywords, Whiteboard: [sg:low])

Attachments

(2 files)

testcase
112 bytes, text/html
Details
fix
3.22 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
beltzner
: approval1.9.1+
Details | Diff | Splinter Review
Attached file testcase — 
###!!! 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.
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.
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).
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.
Attached patch fix — — Splinter Review 
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.
Assignee: nobody → zweinberg
Status: NEW → ASSIGNED
Attachment #378927 - Flags: review?(bzbarsky)
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+
We should get this in on branch.
Flags: blocking1.9.1?
Comment on attachment 378927 [details] [diff] [review]
fix

a191=beltzner after it stays on m-c for with a green cycle
Pushed http://hg.mozilla.org/mozilla-central/rev/f4c8b20a304b
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Flags: blocking1.9.1? → blocking1.9.1-
Whiteboard: [sg:low]
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.