Bug 194352 – WebKit searches for plugins even if plugins are disabled

• Component: Plug-ins
• Status: RESOLVED FIXED

[[e-mail]]

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

[Michael Catanzaro]

To be clear: the bug is that WebKit shouldn't be scanning plugins when the enable-plugins setting is disabled.

[Carlos Garcia Campos]

Created attachment 361906 [details]
Patch

[EWS Watchlist]

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 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]

Thanks for the review, now we need WebKit2 owner approval.

[Chris Dumez]

Youenn, I think you looked into this code last. Could you please take a look?

[Carlos Garcia Campos]

Ping Youenn, please.

[Chris Dumez]

Comment on attachment 361906 [details]
Patch

Sorry about the delay. I think Youenn is out of office. WK2 Owner LGTM.

[WebKit Commit Bot]

Comment on attachment 361906 [details]
Patch

Clearing flags on attachment: 361906

Committed r241817: <https://trac.webkit.org/changeset/241817>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/48239508>

[Truitt Savell]

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]

Reverted r241817 for reason:

Caused 4 API failures

Committed r241844: <https://trac.webkit.org/changeset/241844>

[Darin Adler]

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]

EWS doesn't run api tests?

[Carlos Garcia Campos]

(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]

Created attachment 362602 [details]
Patch for landing

Made this only for non-cocoa ports.

[EWS Watchlist]

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]

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]

(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]

Committed r241933: <https://trac.webkit.org/changeset/241933>