Bug 91331

Summary: Windowless WebView not firing JavaScript load event if there is a media element
Product: WebKit Reporter: Joseph Pecoraro <joepeck>
Component: MediaAssignee: Joseph Pecoraro <joepeck>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, ddkilzer, eric.carlson, joepeck, webkit.review.bot
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
[PATCH] Proposed Fix
none
[PATCH] Proposed Fix eric.carlson: review+

Joseph Pecoraro
Reported 2012-07-14 21:18:41 PDT
Loading a page with a media element, such as: <body><audio src="invalid.mp3"></body> In a WebView without a window results in that page not firing its JavaScript "load" event.
Attachments
[PATCH] Proposed Fix (2.88 KB, patch)
2012-07-14 21:43 PDT, Joseph Pecoraro 		no flags
DetailsFormatted DiffDiff
[PATCH] Proposed Fix (11.96 KB, patch)
2012-07-14 21:45 PDT, Joseph Pecoraro 		eric.carlson: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Joseph Pecoraro
Comment 1 2012-07-14 21:19:29 PDT
<rdar://problem/11865836>
Joseph Pecoraro
Comment 2 2012-07-14 21:43:01 PDT
Created attachment 152447 [details] [PATCH] Proposed Fix
WebKit Review Bot
Comment 3 2012-07-14 21:44:42 PDT
Attachment 152447 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files']" exit_code: 1 Total errors found: 0 in 0 files If any of these errors are false positives, please file a bug against check-webkit-style.
Joseph Pecoraro
Comment 4 2012-07-14 21:45:15 PDT
Created attachment 152448 [details] [PATCH] Proposed Fix This time with a real patch and not dragging in the wrong file ;)
Eric Carlson
Comment 5 2012-07-15 09:49:42 PDT
Comment on attachment 152448 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=152448&action=review > Source/WebCore/ChangeLog:12 > + In prepareLoad we start deferring the load event. If we fall into this > + clause where the page can not start loading media we bail, potentially > + indefinitely waiting until we can start loading media. Since we can not > + be certain this will ever happen, we should stop deferring the page's > + load event. Nit: prepareLoad -> prepareForLoad > Source/WebCore/ChangeLog:15 > + Test: WebKit1.WindowlessWebViewWithMedia TestWebKitAPI test since that > + is the port and only way that this path was reachable right now. Nit: "that is the port and only way that ..." is a bit confusing. > Tools/ChangeLog:10 > + Test a windowless WebView loading a page with a media element. The load > + event should happen on the next spin of the run loop, but we spin check > + the page, with a timeout of 250ms. I don't know about WebKit API tests, but a 250ms timeout in a layout test is short enough that the test would be flakey.
Joseph Pecoraro
Comment 6 2012-07-15 14:04:28 PDT
(In reply to comment #5) > (From update of attachment 152448 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=152448&action=review > > > Source/WebCore/ChangeLog:12 > > + In prepareLoad we start deferring the load event. If we fall into this > > + clause where the page can not start loading media we bail, potentially > > + indefinitely waiting until we can start loading media. Since we can not > > + be certain this will ever happen, we should stop deferring the page's > > + load event. > > Nit: prepareLoad -> prepareForLoad Arg, yep, thanks! > > > Source/WebCore/ChangeLog:15 > > + Test: WebKit1.WindowlessWebViewWithMedia TestWebKitAPI test since that > > + is the port and only way that this path was reachable right now. > > Nit: "that is the port and only way that ..." is a bit confusing. You'd think I'd get better at English over time! I'll fix this. > > Tools/ChangeLog:10 > > + Test a windowless WebView loading a page with a media element. The load > > + event should happen on the next spin of the run loop, but we spin check > > + the page, with a timeout of 250ms. > > I don't know about WebKit API tests, but a 250ms timeout in a layout test is short enough that the test would be flakey. In my experience, this test always passes in <100ms. Currently, it really just needs 1 turn of the run loop to determine if it has succeeded or not. The 250ms timeout is a smaller timeout then the TestWebKitAPI timeout, so we would report a failure instead of timing out the long way.
Joseph Pecoraro
Comment 7 2012-07-15 14:27:43 PDT
Landed in r122683: <http://trac.webkit.org/changeset/122683>
Note You need to log in before you can comment on or make changes to this bug.