| 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 | ||
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. Thank you! Michael, can you verify that this assertion is no longer hit in a build with r80231? Sorry, I had assertions on the mind. I meant to say bug. Sure, when we roll this revision into view for chrome i'll take a look. Looks good to me. I'm no longer seeing multiple invocations of selectCache() for html fragments. (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! |
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.