WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
118163
Audio in apps which embed WebViews is corrupted.
https://bugs.webkit.org/show_bug.cgi?id=118163
Summary
Audio in apps which embed WebViews is corrupted.
Jer Noble
Reported
2013-06-27 18:34:33 PDT
Audio in apps which embed WebViews is corrupted.
Attachments
Patch
(11.79 KB, patch)
2013-06-27 21:55 PDT
,
Jer Noble
mjs
: review+
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from APPLE-EWS-5 for win-future
(1.05 MB, application/zip)
2013-06-28 09:45 PDT
,
Build Bot
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Jer Noble
Comment 1
2013-06-27 21:55:56 PDT
Created
attachment 205663
[details]
Patch
Jer Noble
Comment 2
2013-06-27 22:08:55 PDT
<
rdar://problem/14083280
>
Eric Carlson
Comment 3
2013-06-28 09:07:41 PDT
Comment on
attachment 205663
[details]
Patch Looks good to me, but I am not a WK2 owner so someone else will have to r+.
Anders Carlsson
Comment 4
2013-06-28 09:28:57 PDT
Why does this need to be a setting? Isn't it something we'd want to work for all apps?
Jer Noble
Comment 5
2013-06-28 09:35:27 PDT
(In reply to
comment #4
)
> Why does this need to be a setting? Isn't it something we'd want to work for all apps?
Originally it did. However, some audio intensive apps which embedded a WebView were unhappy to find that the global audio buffer setting had been changed to a very high value. The easiest way for an embedding app to signal that it's fine with this behavior is through a setting.
Jer Noble
Comment 6
2013-06-28 09:36:39 PDT
Though perhaps this should default to TRUE for WebKit2 and FALSE for WebKit1, since in the WebKit2 case, we can be reasonably confident that there are no other sources of audio apart from <audio>, <video>, and Web Audio.
Build Bot
Comment 7
2013-06-28 09:45:46 PDT
Comment on
attachment 205663
[details]
Patch
Attachment 205663
[details]
did not pass win-ews (win): Output:
http://webkit-queues.appspot.com/results/995441
New failing tests: fast/forms/select/popup-closes-on-blur.html
Build Bot
Comment 8
2013-06-28 09:45:48 PDT
Created
attachment 205720
[details]
Archive of layout-test-results from APPLE-EWS-5 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: APPLE-EWS-5 Port: win-future Platform: CYGWIN_NT-6.1-WOW64-1.7.20-0.266-5-3-i686-32bit
Jer Noble
Comment 9
2013-06-28 10:04:19 PDT
(In reply to
comment #7
)
> (From update of
attachment 205663
[details]
) >
Attachment 205663
[details]
did not pass win-ews (win): > Output:
http://webkit-queues.appspot.com/results/995441
> > New failing tests: > fast/forms/select/popup-closes-on-blur.html
Seems unrelated. :)
Maciej Stachowiak
Comment 10
2013-06-29 20:20:46 PDT
Comment on
attachment 205663
[details]
Patch This way of doing it seems ok to me, but if you want to make it have opposite defaults for WK1 and WK2, that would be fine as well.
Sam Weinig
Comment 11
2013-06-30 14:46:44 PDT
Does this really have to be a global? Is there a reason the places where we read this setting can't access settings or some proxy for it?
Radar WebKit Bug Importer
Comment 12
2013-06-30 23:36:26 PDT
<
rdar://problem/14317560
>
Jer Noble
Comment 13
2013-07-01 11:41:20 PDT
Committed
r152234
: <
http://trac.webkit.org/changeset/152234
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug