Dear ladies & gentlemen, I filled already a related bug here: https://bugs.webkit.org/show_bug.cgi?id=194351 The problem in this bug report is that Epiphany is scanning for plugins even the dconf value says it's "disabled". Terminal output: henrik@debian:~$ epiphany Error scanning plugin /usr/lib/jvm/oracle-java8-jre-amd64/lib/amd64/libnpjp2.so, /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitPluginProcess returned 11 exit status ** (WebKitWebProcess:28441): WARNING **: 19:08:44.386: WebKit wasn't able to find the GStreamer opengl plugin. Hardware-accelerated zero-copy video rendering can't be enabled without this plugin. ** (WebKitWebProcess:28441): WARNING **: 19:08:44.621: WebKit wasn't able to find the GStreamer opengl plugin. Hardware-accelerated zero-copy video rendering can't be enabled without this plugin. ** (WebKitWebProcess:28441): WARNING **: 19:08:45.105: WebKit wasn't able to find the GStreamer opengl plugin. Hardware-accelerated zero-copy video rendering can't be enabled without this plugin. ** (WebKitWebProcess:28441): WARNING **: 19:08:45.315: WebKit wasn't able to find the GStreamer opengl plugin. Hardware-accelerated zero-copy video rendering can't be enabled without this plugin. ^C Plugin dconf check: gsettings get org.gnome.Epiphany.web:/org/gnome/epiphany/web/ enable-plugins false Best regards, Henrik
To be clear: the bug is that WebKit shouldn't be scanning plugins when the enable-plugins setting is disabled.
Created attachment 361906 [details] Patch
Attachment 361906 [details] did not pass style-queue: ERROR: Source/WebKit/WebProcess/Plugins/WebPluginInfoProvider.cpp:152: Multi line control clauses should use braces. [whitespace/braces] [4] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 361906 [details] Patch Style checker is correct! (It's easier to read with the braces, even though they're not necessary.)
Thanks for the review, now we need WebKit2 owner approval.
Youenn, I think you looked into this code last. Could you please take a look?
Ping Youenn, please.
Comment on attachment 361906 [details] Patch Sorry about the delay. I think Youenn is out of office. WK2 Owner LGTM.
Comment on attachment 361906 [details] Patch Clearing flags on attachment: 361906 Committed r241817: <https://trac.webkit.org/changeset/241817>
All reviewed patches have been landed. Closing bug.
<rdar://problem/48239508>
Looks like this change https://trac.webkit.org/changeset/241817/webkit has caused 4 API failures: Failed TestWebKitAPI.WebKit.WKNavigationResponsePDFType Received data during response processing, queuing it. /Volumes/Data/slave/highsierra-release/build/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKNavigationResponse.mm:45 Expected equality of these values: navigationResponse.canShowMIMEType Which is: '\0' self.expectation Which is: '\x1' (1) Timeout TestWebKitAPI.WebKit.GetPDFResourceDataInUnparentedWebView TestWebKitAPI.WebKit.WKPDFViewResizeCrash TestWebKitAPI.WebKit.GetPDFResourceData build: https://build.webkit.org/builders/Apple%20High%20Sierra%20Release%20WK1%20%28Tests%29/builds/11341
Reverted r241817 for reason: Caused 4 API failures Committed r241844: <https://trac.webkit.org/changeset/241844>
It looks like there are some special considerations on the macOS platform. Might need to scan for the PDF plug-in even if plug-ins are disabled or something like that.
EWS doesn't run api tests?
(In reply to Darin Adler from comment #14) > It looks like there are some special considerations on the macOS platform. > Might need to scan for the PDF plug-in even if plug-ins are disabled or > something like that. Right, the setting doesn't affect application plugins (pdf is the only application plugin, I guess).
Created attachment 362602 [details] Patch for landing Made this only for non-cocoa ports.
Attachment 362602 [details] did not pass style-queue: ERROR: Source/WebKit/WebProcess/Plugins/WebPluginInfoProvider.cpp:158: Multi line control clauses should use braces. [whitespace/braces] [4] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
A correct version would tie this to ports that have "application plug-ins", rather than specifically to "Cocoa ports", but perhaps there is no obvious way to do that.
(In reply to Darin Adler from comment #19) > A correct version would tie this to ports that have "application plug-ins", > rather than specifically to "Cocoa ports", but perhaps there is no obvious > way to do that. I assumed cocoa because PDF plugin is apparently the only application plugin and WebPage::pdfPluginEnabled() is in a cocoa platform ifdef.
Committed r241933: <https://trac.webkit.org/changeset/241933>