Bug 198430

Summary: getUserMedia requests should be processed sequentially in UIProcess
Product: WebKit Reporter: youenn fablet <youennf>
Component: WebRTCAssignee: youenn fablet <youennf>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, eric.carlson, ews-watchlist, mcatanzaro, rniwa, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=198575
Attachments:
Description Flags
Patch
none
Archive of layout-test-results from ews104 for mac-highsierra-wk2
none
Patch
none
Patch
none
Patch for landing
none
Patch for landing
none
Fix windows none

Description youenn fablet 2019-05-31 12:22:09 PDT
getUserMedia requests should be processed sequentially in UIProcess
Comment 1 youenn fablet 2019-05-31 12:41:36 PDT
Created attachment 371077 [details]
Patch
Comment 2 Radar WebKit Bug Importer 2019-05-31 12:42:00 PDT
<rdar://problem/51311420>
Comment 3 EWS Watchlist 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
Comment 4 EWS Watchlist 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
Comment 5 youenn fablet 2019-05-31 15:15:09 PDT
Created attachment 371090 [details]
Patch
Comment 6 youenn fablet 2019-06-03 14:05:26 PDT
Created attachment 371209 [details]
Patch
Comment 7 Eric Carlson 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.
Comment 8 youenn fablet 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.
Comment 9 youenn fablet 2019-06-04 15:18:29 PDT
Created attachment 371342 [details]
Patch for landing
Comment 10 youenn fablet 2019-06-04 15:57:42 PDT
Created attachment 371347 [details]
Patch for landing
Comment 11 youenn fablet 2019-06-04 16:05:53 PDT
Created attachment 371348 [details]
Fix windows
Comment 12 WebKit Commit Bot 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>
Comment 13 WebKit Commit Bot 2019-06-04 18:03:12 PDT
All reviewed patches have been landed.  Closing bug.
Comment 14 Michael Catanzaro 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.
Comment 15 Michael Catanzaro 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?
Comment 16 youenn fablet 2019-06-04 20:40:07 PDT
Looking again at it, we probably no longer need logSiteIdentifier.
I'll remove it tomorrow.