Bug 54689
| Summary: | HTML Fragment parsing bug in HTMLHtmlElement. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Nordman <michaeln> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | abarth, aestes, michaeln |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
Michael Nordman
Looks like the test for fragment'ness when a synthesized <html> element for an innerHtml fragment no longer functions properly in HTMLHtmlElement::insertedByParser().
void HTMLHtmlElement::insertedByParser()
{
// When parsing a fragment, its dummy document has a null parser.
if (!document()->parser() || !document()->parser()->documentWasLoadedAsPartOfNavigation())
return;
That test no longer weeds out these elements so the method continues when it shouldn't. This has bad consequences for the appcache system.
See http://code.google.com/p/chromium/issues/detail?id=72986 for some history.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Andy Estes
Working on it. I actually think this will be fixed by the patch I'm uploading to https://bugs.webkit.org/show_bug.cgi?id=48719, which will not create an HTML element during fragment parsing.
Michael Nordman
Thank you!
Andy Estes
Michael, can you verify that this assertion is no longer hit in a build with r80231?
Andy Estes
Sorry, I had assertions on the mind. I meant to say bug.
Michael Nordman
Sure, when we roll this revision into view for chrome i'll take a look.
Michael Nordman
Looks good to me. I'm no longer seeing multiple invocations of selectCache() for html fragments.
Andy Estes
(In reply to comment #6)
> Looks good to me. I'm no longer seeing multiple invocations of selectCache() for html fragments.
Thanks for checking Michael!