Summary: | ASSERT if WebView's UIDelegate does not implement webView:runOpenPanel | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Joseph Pecoraro <joepeck> | ||||
Component: | WebKit API | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | joepeck, webkit.review.bot | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Joseph Pecoraro
2011-09-28 16:00:30 PDT
Created attachment 109096 [details]
[PATCH] Proposed Fix
Easiest approach was to just send a -cancel to the listener.
This would also fix a leak for those cases. Comment on attachment 109096 [details]
[PATCH] Proposed Fix
Is it right to -release after -cancel? This looks like an over-release.
In this case, -cancel doesn't release the object, it just sends a message down to the WebCore::FileChooser and clears the FileChooser. -release just deallocates, which expects the chooser to have already been cleared. The relevant code here is: ifndef NDEBUG - (void)dealloc { ASSERT(!_chooser); [super dealloc]; } - (void)finalize { ASSERT(!_chooser); [super finalize]; } #endif - (void)cancel { ASSERT(_chooser); if (!_chooser) return; _chooser->deref(); _chooser = 0; } (In reply to comment #4) > "it just sends a message down to the WebCore::FileChooser" Actually the -cancel path doesn't send a message. The -chooseFile(s) paths do send a message and clear the chooser. The rest of my comment is still fine. Comment on attachment 109096 [details] [PATCH] Proposed Fix Clearing flags on attachment: 109096 Committed r96279: <http://trac.webkit.org/changeset/96279> All reviewed patches have been landed. Closing bug. |