[Webkit-unassigned] [Bug 212969] New: [GTK] Add an API to run javascript without forced user gestures

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=212969

            Bug ID: 212969
           Summary: [GTK] Add an API to run javascript without forced user
                    gestures
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cturner at igalia.com
                CC: bugs-noreply at webkitgtk.org

webkit_web_view_run_javascript currently calls runJavaScriptInMainFrame with forceUserGesture set to true in the RunJavaScriptParameters. This caused a problem during the development of an autoplay API https://bugs.webkit.org/show_bug.cgi?id=184845.

If you deny autoplay as a web view policy, and then the page JavaScript tries to call videoElement.play() without you gesturing the video to play, it clearly should not play the video.
However, if you use the GTK API to run the same JS, it will autoplay the video.

It's fair to say that because API users are fully in control of what JS they send in via the API, this is a non-issue and a new public-facing API is not needed.

But, to test autoplay continues to reject play() requests in "normal" cases as above, there does need to be an API for WebViewTest to run JS without user gestures forced. Given that the tests use the public API, I figured a new one is sensible.

Finally, the default could be switched to always run JavaScript without forced user gestures by modifying webkit_web_view_run_javascript. This breaks the webkit/WebKitWebView/fullscreen test. It uses document.documentElement.webkitRequestFullScreen(); to go fullscreen, called via webkit_web_view_run_javascript. I have not debugged why that requires user-gestures on, only assumed it's for good reason and changing that could cause a lot of breakage.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200609/85c119ff/attachment.htm>