Summary: | HTMLTreeBuilder passes a wrong token when pushing the head element | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Kwang Yul Seo <skyul> | ||||
Component: | DOM | Assignee: | Kwang Yul Seo <skyul> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | abarth, eric, webkit.review.bot | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 92830 | ||||||
Attachments: |
|
Description
Kwang Yul Seo
2012-07-31 22:08:30 PDT
Created attachment 155720 [details]
Patch
Comment on attachment 155720 [details]
Patch
Interesting. It's hard to see how this could have any observable effects, but I agree that it's wrong.
Maybe with one of those convoluted tests for token re-use, something like: <head a='b'> <script> document.head.setAttribute('a', 'c'); </script> But I agree with Adam and it's unlikely to matter. > Maybe with one of those convoluted tests for token re-use, something like:
Yeah, but I couldn't think of any cases where we'd read back the attributes of the <head> element...
Comment on attachment 155720 [details] Patch Clearing flags on attachment: 155720 Committed r124353: <http://trac.webkit.org/changeset/124353> All reviewed patches have been landed. Closing bug. (In reply to comment #4) > > Maybe with one of those convoluted tests for token re-use, something like: > > Yeah, but I couldn't think of any cases where we'd read back the attributes of the <head> element... It's hardly a problem in real situations. But the first assertion in HTMLElementStack::pushHTMLHeadElement(PassRefPtr<HTMLStackItem>) fails after Bug 92830. void HTMLElementStack::pushHTMLHeadElement(PassRefPtr<HTMLStackItem> item) { ASSERT(item->hasTagName(HTMLNames::headTag)); // <- this assertion fails because the tag name is read from the stack item (saved token). ASSERT(!m_headElement); m_headElement = item->element(); pushCommon(item); } |