Summary: | [GTK] Add an internal API to run javascript without forced user gestures | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Charlie Turner <cturner> | ||||
Component: | WebKitGTK | Assignee: | Charlie Turner <cturner> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | berto, bugs-noreply, cgarcia, clopez, ews-watchlist, gustavo, mcatanzaro | ||||
Priority: | P2 | ||||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 184845 | ||||||
Attachments: |
|
Description
Charlie Turner
2020-06-09 05:12:51 PDT
We simulate user interaction in other unit tests when it's required. I guess you're referring to UIClient tests and their simulateUserInteraction method. That method of focusing a hidden input element in the DOM, or artificially injecting key strokes into the event loop does not seem to help in this test, whether I do it before calling webkitRequestFullScreen or after calling it. I'll dig deeper into what going on in webkitRequestFullScreen. I still think we need this API. The fullscreen request will be denied and the test will hang without active user gestures, because document.documentElement.webkitRequestFullScreen() ends up in WebCore::FullscreenManager::requestFullscreenForElement, which early returns if no gesture tokens are installed. User gestures are kept in a static global on the main thread. webkit_web_view_run_javascript and synthetic key events both cause this global to get a gesture installed, so why doesn't it work calling it right before I run the JS without explicitly enabling user gestures? They should be sticky, no? Gestures are only active for the lifetime of the script run by webkit_web_view_run_javascript and the processing of the key event in WebCore::EventHandler::internalKeyEvent respectively. It's a tad tricksy how UserGestureIndicator keeps that static global valid only for the scope in which it's stack allocated. So, we want an API that runs JS without user gestures explicitly. Cocoa has _evaluateJavaScriptWithoutUserGesture, I think we should too after learning the above. Hm, it seems like the only use for this API is to use in our own API tests, right? Is there any case where a real-world app would want to run JS without gesture forced? (In reply to Michael Catanzaro from comment #4) > Hm, it seems like the only use for this API is to use in our own API tests, > right? Is there any case where a real-world app would want to run JS without > gesture forced? I mean, in theory yes. I don't have a compelling use case though, so maybe that alone is enough to expose instead some internal alternative. If that's what we want, I don't see prior art in WebViewTest of calling into internal WebKit APIs without going through the GTK API. Any advice on how to handle that without adding a new API? Lack of prior art is a problem indeed. In theory, any exported function *could* be used in the tests. Carlos might consider it a layering violation, but it's *possible* to do. We use private API from jsc tests, for example. And recently we also added private API that is used from WTR. It's not a problem. In this particular case, I would add a WebKitWebViewInternal.h header with the private api required from unit tests. Created attachment 401661 [details]
Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API Committed r262940: <https://trac.webkit.org/changeset/262940> All reviewed patches have been landed. Closing bug and clearing flags on attachment 401661 [details]. |