Summary: | Fix a bug in MediaDocument.cpp that gets triggered when entering a media file in address bar | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Hin-Chung Lam <hclam> | ||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Normal | CC: | dglazkov, eric.carlson | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | OS X 10.5 | ||||||
Attachments: |
|
Description
Hin-Chung Lam
2009-04-27 10:58:18 PDT
*** 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.
|