Bug 30049

Summary:

Manipulating DOM from a script while parsing XHTML can cause a crash

Product:

WebKit

Reporter:

chameleon <gessos.paul>

Component:

DOM

Assignee:

Alexey Proskuryakov <ap>

Status:

RESOLVED FIXED

Severity:

Major

CC:

ap, cdumez

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
A whole web site which reproduce the crash	none
Static website which reproduce the crash	none
same test in zip format	none
reduced test case (will crash)	none
proposed fix	darin: review+

chameleon

Reported 2009-10-03 13:54:11 PDT

Created attachment 40582 [details] A whole web site which reproduce the crash I attach a simplified website, programmed by me. Website uses Javascript and XSLT 1.1. Complete source code is available in attachment. The attached website works fine on Firefox/Opera. When load it with latest Safari, it crashes immediatelly. So, I cannot provide more info.

Attachments
A whole web site which reproduce the crash (5.77 KB, application/octet-stream) 2009-10-03 13:54 PDT, chameleon	no flags	Details
Static website which reproduce the crash (5.72 KB, application/x-7z-compressed) 2009-10-04 22:25 PDT, chameleon	no flags	Details
same test in zip format (7.67 KB, application/zip) 2009-10-07 22:16 PDT, Alexey Proskuryakov	no flags	Details
reduced test case (will crash) (248 bytes, application/xhtml+xml) 2009-10-07 22:31 PDT, Alexey Proskuryakov	no flags	Details
proposed fix (11.30 KB, patch) 2009-10-26 12:49 PDT, Alexey Proskuryakov	darin: review+	Details Formatted Diff Diff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Mark Rowe (bdash)

Comment 1 2009-10-03 22:36:43 PDT

Thanks for filing this bug report. Is there any chance that you can provide your attached reproducible case in a format that would be easier to reproduce? Test cases that require a web server are naturally more difficult to work with than a simple HTML file.

chameleon

Comment 2 2009-10-04 22:25:05 PDT

Created attachment 40612 [details] Static website which reproduce the crash PHP has only the header('.....'); dynamic. All other content was static. So I replace the attachment with a 100% static website.

Alexey Proskuryakov

Comment 3 2009-10-07 22:16:08 PDT

Created attachment 40847 [details] same test in zip format Confirmed with r48940.

Alexey Proskuryakov

Comment 4 2009-10-07 22:31:08 PDT

Created attachment 40850 [details] reduced test case (will crash)

Alexey Proskuryakov

Comment 5 2009-10-07 22:35:50 PDT

The issue here is that an element is removed while it's still being parsed. I'm not sure what the right behavior would be here.

Alexey Proskuryakov

Comment 6 2009-10-07 22:36:45 PDT

<rdar://problem/7286002>

Alexey Proskuryakov

Comment 7 2009-10-26 12:49:22 PDT

Created attachment 41883 [details] proposed fix

Darin Adler

Comment 8 2009-10-26 15:26:44 PDT

Comment on attachment 41883 [details] proposed fix > + (WebCore::XMLTokenizer::setCurrentNode): Push the new node onto stack. If null is passed, > + then we're aborting; nuke the whole stack. It seems strange to give setCurrentNode(0) this special behavior. Perhaps instead we could use a separate functions for this purpose. One could be called pushNode and the other could be called something else. > + (WebCore::XMLTokenizer::popCurrentNode): This is now called instead of setCurrentNode when > + exiting a node. I'm not sure why the word "current" is needed in the name of this function. r=me as is, but please consider getting rid of the two different meanings for setCurrentNode.

Alexey Proskuryakov

Comment 9 2009-10-26 16:13:53 PDT

Committed <http://trac.webkit.org/changeset/50110>.

Lucas Forschler

Comment 10 2019-02-06 09:04:09 PST

Mass moving XML DOM bugs to the "DOM" Component.

Note You need to log in before you can comment on or make changes to this bug.