[Webkit-unassigned] [Bug 176119] [GTK][WPE] API for WebView audio mute support

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 11 07:39:14 PDT 2020


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

--- Comment #10 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Comment on attachment 399004
  --> https://bugs.webkit.org/attachment.cgi?id=399004
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=399004&action=review

Let's say I have muted the audio for the web view using webkit_web_view_set_audio_muted(). That changes a property of the view, so it should stay muted if the view swaps to a new page. Now the user loads a new webpage from a different origin. The view's WebPageProxy stays the same, but the WebCore::Page backing it in the web process is swapped. The new page is probably not muted until we mute it by calling getPage(webView).setMuted. So we probably need to do that manually when the process swaps... right? Can you test this please? I bet the muted state gets lost if we don't have any code to persist it.

I see that *somehow* webkitWebViewIsPlayingAudioChanged is being called during process swaps, because the volume indicator on my Epiphany tabs resets properly. But this case is different because here we have to persist the muted state across multiple underlying pages, rather than just indicate what the state is.

Other than that concern, the code LGTM. This also needs approved by a second GTK reviewer since it adds new API, and also an Apple owner since it touches cross-platform WebKit layer.

> Source/WebCore/ChangeLog:3
> +        Add isPageMuteDidChange to inform about audio mute changes.

Just keep the title of the bug report here.

> Source/WebCore/page/Page.cpp:1852
>      forEachDocument([] (Document& document) {
>          document.pageMutedStateDidChange();
>      });
> +
> +    chrome().client().isPageMutedDidChange();
>  }

I wonder what other code might call Page::setMuted? Is it something that will only be used by the web view level? If so, then this is fine. (If not, the API won't work be "sticky" as expected... we don't want anything besides webkit_web_view_set_audio_muted() to override the muted state.)

-- 
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/20200511/35e9e2e5/attachment-0001.htm>


More information about the webkit-unassigned mailing list