RESOLVED FIXED 194352
WebKit searches for plugins even if plugins are disabled
https://bugs.webkit.org/show_bug.cgi?id=194352
Summary WebKit searches for plugins even if plugins are disabled
hschoepel@gmail.com
Reported 2019-02-06 11:46:08 PST
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
Attachments
Patch (2.29 KB, patch)
2019-02-13 03:10 PST, Carlos Garcia Campos
no flags
Patch for landing (2.55 KB, patch)
2019-02-21 03:37 PST, Carlos Garcia Campos
no flags
Michael Catanzaro
Comment 1 2019-02-06 13:28:13 PST
To be clear: the bug is that WebKit shouldn't be scanning plugins when the enable-plugins setting is disabled.
Carlos Garcia Campos
Comment 2 2019-02-13 03:10:19 PST
EWS Watchlist
Comment 3 2019-02-13 03:12:27 PST
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.
Michael Catanzaro
Comment 4 2019-02-13 08:51:02 PST
Comment on attachment 361906 [details] Patch Style checker is correct! (It's easier to read with the braces, even though they're not necessary.)
Carlos Garcia Campos
Comment 5 2019-02-13 09:00:44 PST
Thanks for the review, now we need WebKit2 owner approval.
Chris Dumez
Comment 6 2019-02-13 09:03:28 PST
Youenn, I think you looked into this code last. Could you please take a look?
Carlos Garcia Campos
Comment 7 2019-02-20 04:44:09 PST
Ping Youenn, please.
Chris Dumez
Comment 8 2019-02-20 08:45:59 PST
Comment on attachment 361906 [details] Patch Sorry about the delay. I think Youenn is out of office. WK2 Owner LGTM.
WebKit Commit Bot
Comment 9 2019-02-20 09:11:38 PST
Comment on attachment 361906 [details] Patch Clearing flags on attachment: 361906 Committed r241817: <https://trac.webkit.org/changeset/241817>
WebKit Commit Bot
Comment 10 2019-02-20 09:11:40 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 11 2019-02-20 09:18:37 PST
Truitt Savell
Comment 12 2019-02-20 11:23:48 PST
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
Truitt Savell
Comment 13 2019-02-20 15:26:59 PST
Reverted r241817 for reason: Caused 4 API failures Committed r241844: <https://trac.webkit.org/changeset/241844>
Darin Adler
Comment 14 2019-02-20 21:24:43 PST
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.
Carlos Garcia Campos
Comment 15 2019-02-21 03:12:18 PST
EWS doesn't run api tests?
Carlos Garcia Campos
Comment 16 2019-02-21 03:27:40 PST
(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).
Carlos Garcia Campos
Comment 17 2019-02-21 03:37:27 PST
Created attachment 362602 [details] Patch for landing Made this only for non-cocoa ports.
EWS Watchlist
Comment 18 2019-02-21 03:39:44 PST
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.
Darin Adler
Comment 19 2019-02-21 08:55:10 PST
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.
Carlos Garcia Campos
Comment 20 2019-02-21 09:53:33 PST
(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.
Carlos Garcia Campos
Comment 21 2019-02-21 23:02:11 PST
Note You need to log in before you can comment on or make changes to this bug.