WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
198430
getUserMedia requests should be processed sequentially in UIProcess
https://bugs.webkit.org/show_bug.cgi?id=198430
Summary
getUserMedia requests should be processed sequentially in UIProcess
youenn fablet
Reported
2019-05-31 12:22:09 PDT
getUserMedia requests should be processed sequentially in UIProcess
Attachments
Patch
(35.01 KB, patch)
2019-05-31 12:41 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Archive of layout-test-results from ews104 for mac-highsierra-wk2
(2.80 MB, application/zip)
2019-05-31 13:57 PDT
,
EWS Watchlist
no flags
Details
Patch
(35.01 KB, patch)
2019-05-31 15:15 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch
(41.06 KB, patch)
2019-06-03 14:05 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch for landing
(38.77 KB, patch)
2019-06-04 15:18 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch for landing
(38.77 KB, patch)
2019-06-04 15:57 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Fix windows
(39.08 KB, patch)
2019-06-04 16:05 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
youenn fablet
Comment 1
2019-05-31 12:41:36 PDT
Created
attachment 371077
[details]
Patch
Radar WebKit Bug Importer
Comment 2
2019-05-31 12:42:00 PDT
<
rdar://problem/51311420
>
EWS Watchlist
Comment 3
2019-05-31 13:57:57 PDT
Comment on
attachment 371077
[details]
Patch
Attachment 371077
[details]
did not pass mac-wk2-ews (mac-wk2): Output:
https://webkit-queues.webkit.org/results/12342446
New failing tests: http/wpt/service-workers/service-worker-networkprocess-crash.html
EWS Watchlist
Comment 4
2019-05-31 13:57:58 PDT
Created
attachment 371082
[details]
Archive of layout-test-results from ews104 for mac-highsierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-highsierra-wk2 Platform: Mac OS X 10.13.6
youenn fablet
Comment 5
2019-05-31 15:15:09 PDT
Created
attachment 371090
[details]
Patch
youenn fablet
Comment 6
2019-06-03 14:05:26 PDT
Created
attachment 371209
[details]
Patch
Eric Carlson
Comment 7
2019-06-04 07:02:12 PDT
Comment on
attachment 371209
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=371209&action=review
> Source/WebKit/ChangeLog:9 > + getUserMedia requests should be processed sequentially in UIProcess > +
https://bugs.webkit.org/show_bug.cgi?id=198430
> + <
rdar://problem/51311420
> > + > + Reviewed by NOBODY (OOPS!). > + > + * UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
Oops - double Changelogs.
> Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:378 > + if (m_currentUserMediaRequest != request) > return;
How can this happen? It is probably worth logging an error if this should never happen.
> Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:400 > + if (!weakThis || m_currentUserMediaRequest != request)
Ditto.
> Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:404 > + if (!weakThis || m_currentUserMediaRequest != request)
Ditto.
> Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:414 > + if (!weakThis || m_currentUserMediaRequest != request)
Ditto.
youenn fablet
Comment 8
2019-06-04 08:30:55 PDT
> > Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:378 > > + if (m_currentUserMediaRequest != request) > > return; > > How can this happen? It is probably worth logging an error if this should > never happen.
This can happen in this case: - a request is being processed and is doing some async tasks, like prompting user - the manager proxy invalidates all requests (for instance the app sets setCaptureEnabled to false, then back to true) - the page triggers a new request which then becomes the new current request. I'll make it clearer.
youenn fablet
Comment 9
2019-06-04 15:18:29 PDT
Created
attachment 371342
[details]
Patch for landing
youenn fablet
Comment 10
2019-06-04 15:57:42 PDT
Created
attachment 371347
[details]
Patch for landing
youenn fablet
Comment 11
2019-06-04 16:05:53 PDT
Created
attachment 371348
[details]
Fix windows
WebKit Commit Bot
Comment 12
2019-06-04 18:03:10 PDT
Comment on
attachment 371348
[details]
Fix windows Clearing flags on attachment: 371348 Committed
r246093
: <
https://trac.webkit.org/changeset/246093
>
WebKit Commit Bot
Comment 13
2019-06-04 18:03:12 PDT
All reviewed patches have been landed. Closing bug.
Michael Catanzaro
Comment 14
2019-06-04 20:19:18 PDT
Hm: [187/322] Building CXX object Source/W...sources/UnifiedSource-88d1702b-3.cpp.o In file included from DerivedSources/WebKit/unified-sources/UnifiedSource-88d1702b-3.cpp:6: ../../Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp: In member function ‘void WebKit::UserMediaPermissionRequestManagerProxy::requestUserMediaPermissionForFrame(uint64_t, uint64_t, WTF::Ref<WebCore::SecurityOrigin>&&, WTF::Ref<WebCore::SecurityOrigin>&&, WebCore::MediaStreamRequest&&)’: ../../Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:336:10: warning: variable ‘logSiteIdentifier’ set but not used [-Wunused-but-set-variable] 336 | auto logSiteIdentifier = LOGIDENTIFIER; | ^~~~~~~~~~~~~~~~~ Problem is that ALWAYS_LOG is of course only defined on Mac. This is annoying because the warning is ugly to silence.
Michael Catanzaro
Comment 15
2019-06-04 20:24:16 PDT
Youenn, would you be OK with: diff --git a/Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp b/Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp index b1cf20cb787..7568deeee67 100644 --- a/Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp +++ b/Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp @@ -334,6 +334,9 @@ void UserMediaPermissionRequestManagerProxy::requestUserMediaPermissionForFrame( { #if ENABLE(MEDIA_STREAM) auto logSiteIdentifier = LOGIDENTIFIER; +#if RELEASE_LOG_DISABLED + UNUSED_VARIABLE(logSiteIdentifier); +#endif if (!m_page.hasRunningProcess()) return; Or can you think of a better way to write this?
youenn fablet
Comment 16
2019-06-04 20:40:07 PDT
Looking again at it, we probably no longer need logSiteIdentifier. I'll remove it tomorrow.
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