When MediaDocument receives the first call for data for the media document, it immediately construct the DOM structure and mark the parsing as finished but does not stop the resource loading of the media file, so when the next buffer is received a ASSERT is hit.
*** Bug 25429 has been marked as a duplicate of this bug. ***
Created attachment 29876 [details] change log + patch Another bug I filed was a duplicate so I submit the patch again here. I'm not so sure if there's any layout tests regarding MediaDocument and MediaTokenizer, please correct me if I need to have layout tests for this fix.
Is there a way to reproduce this problem?
The steps I took: 1. Open Chromium nightly build 2. Enter a .mov address in the address bar 3. kaboom! I tried to reproduce it in Safari (or nightly WebKit) but no luck, I tried: 1. Remove all QuickTime plugins so it won't get delegated to QT 2. Enter a .mov address 3. Explorer opens and pointed me to the file
This patch causes an OSX build to crash in DocumentLoader::cancelMainResourceLoad, called from -[WebHTMLRepresentation receivedData:withDataSource:] to stop resource loading. Brady Eidson added that call in http://trac.webkit.org/changeset/36001 to replace code that was essentially the same as what you are proposing here, so I don't think this approach is right.
I'll do a OSX build to verify and debug into it, thanks for the info!
Comment on attachment 29876 [details] change log + patch Style violations { don't go on their own line for if's. also, why is this correct? does this match other Document.cpp finish() methods? Seems it needs a comment to that effect.
Comment on attachment 29876 [details] change log + patch Also, we could at least make a manual test (see WebCore/manual-tests/) for this.