RESOLVED FIXED198430
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
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
Patch (35.01 KB, patch)
2019-05-31 15:15 PDT, youenn fablet
no flags
Patch (41.06 KB, patch)
2019-06-03 14:05 PDT, youenn fablet
no flags
Patch for landing (38.77 KB, patch)
2019-06-04 15:18 PDT, youenn fablet
no flags
Patch for landing (38.77 KB, patch)
2019-06-04 15:57 PDT, youenn fablet
no flags
Fix windows (39.08 KB, patch)
2019-06-04 16:05 PDT, youenn fablet
no flags
youenn fablet
Comment 1 2019-05-31 12:41:36 PDT
Radar WebKit Bug Importer
Comment 2 2019-05-31 12:42:00 PDT
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
youenn fablet
Comment 6 2019-06-03 14:05:26 PDT
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.