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.
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.
It's a tad tricksy how UserGestureIndicator keeps that static global valid only for the scope in which it's stack allocated.
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]
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].