Hi, Is anybody still using the plugin process? I understand that Safari does not allow plugins anymore. Epiphany doesn't either, nor does anything packaged in Linux distros (afaik). If nothing is using it, maybe we can delete a lot of code? Is it exposed in Apple system APIs? WebKitGTK still has an enable-plugins setting that is not yet deprecated. Probably long past time to at least deprecate it. There's also, incredibly, an enable-java setting, which I presume toggles the old Java browser plugin. I sense there must be some history behind that setting. :)
We haven’t removed it from Apple builds yet, because we think there are still some WebKit clients that use them. I.e., WebKit framework users on the platform that are not Safari or one of the other web browsers. We should take another look, because it would be great to get rid of it completely. Thanks, -Brent
On Jul 19, 2020, at 11:12 AM, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
Hi,
Is anybody still using the plugin process? I understand that Safari does not allow plugins anymore. Epiphany doesn't either, nor does anything packaged in Linux distros (afaik). If nothing is using it, maybe we can delete a lot of code? Is it exposed in Apple system APIs?
WebKitGTK still has an enable-plugins setting that is not yet deprecated. Probably long past time to at least deprecate it. There's also, incredibly, an enable-java setting, which I presume toggles the old Java browser plugin. I sense there must be some history behind that setting. :)
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Hi all, On Sun, 19 Jul 2020 15:49:37 -0700, Brent Fulgham <bfulgham@apple.com> wrote:
We haven’t removed it from Apple builds yet, because we think there are still some WebKit clients that use them. I.e., WebKit framework users on the platform that are not Safari or one of the other web browsers.
For the GTK port we have already removed the support for NPAPI plugins that use the GTK2 plugin process in the 2.28.x releases (the current stable series), but using the GTK3 plugin process is still supported. Our tentative plan for sunsetting the NPAPI support is to keep supporting the GTK3 plugin process in the next stable release series. This means that we could remove the support from trunk after creating the stable branch for the 2.30.x releases—that would be around September-October 2020.
We should take another look, because it would be great to get rid of it completely.
Indeed!
On Jul 19, 2020, at 11:12 AM, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
Hi,
Is anybody still using the plugin process? I understand that Safari does not allow plugins anymore. Epiphany doesn't either, nor does anything packaged in Linux distros (afaik). If nothing is using it, maybe we can delete a lot of code? Is it exposed in Apple system APIs?
WebKitGTK still has an enable-plugins setting that is not yet deprecated. Probably long past time to at least deprecate it. There's also, incredibly, an enable-java setting, which I presume toggles the old Java browser plugin. I sense there must be some history behind that setting. :)
AFAIU, the idea is to allow things like enabling plugins in general, but not the Java plugin in particular. Probably the reason has been that the Java browser plugins have historically been plagued by bugs—but this is just me doing a wild guess ;-) I think we would need to make the public API to toggle the support for plugins a no-op and log a warning to avoid breaking applications. When building against GTK4 the plugin process is never supported (and has never been, we decided to avoid it from the very beginning). Cheers, —Adrián
On Mon, Jul 20, 2020 at 11:47 am, Adrian Perez de Castro <aperez@igalia.com> wrote:
Our tentative plan for sunsetting the NPAPI support is to keep supporting the GTK3 plugin process in the next stable release series. This means that we could remove the support from trunk after creating the stable branch for the 2.30.x releases—that would be around September-October 2020.
Well branching normally occurs in August... just a few weeks away now. Then we can make the plugin process specific to PLATFORM(COCOA), until Apple figures out if it can be removed, and we can delete the support for all other platforms. For now, I'll submit a patch to deprecate these settings without changing behavior yet.
I think we would need to make the public API to toggle the support for plugins a no-op and log a warning to avoid breaking applications.
Well a warning certainly doesn't hurt. I suspect no applications are using it, though. Michael
On Mon, 20 Jul 2020 09:35:24 -0500, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
On Mon, Jul 20, 2020 at 11:47 am, Adrian Perez de Castro <aperez@igalia.com> wrote:
Our tentative plan for sunsetting the NPAPI support is to keep supporting the GTK3 plugin process in the next stable release series. This means that we could remove the support from trunk after creating the stable branch for the 2.30.x releases—that would be around September-October 2020.
Well branching normally occurs in August... just a few weeks away now. Then we can make the plugin process specific to PLATFORM(COCOA), until Apple figures out if it can be removed, and we can delete the support for all other platforms.
Oh, I was sleepy when I wrote that… of course you are right: branching for the stable release happens *before* the first release of the series is done, not after. So yes, we can start removing the plugin process from trunk around August.
For now, I'll submit a patch to deprecate these settings without changing behavior yet.
I think we would need to make the public API to toggle the support for plugins a no-op and log a warning to avoid breaking applications.
Well a warning certainly doesn't hurt. I suspect no applications are using it, though.
Cheers, —Adrián
On Mon, Jul 20, 2020 at 9:35 am, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
For now, I'll submit a patch to deprecate these settings without changing behavior yet.
Meh, I did this, but realized that it's easier to write deprecation messages when we remove support for the feature at the same time that it's deprecated. That is, if we wait until after branching to deprecate, we can write: Deprecated: 2.32: NPAPI browser plugins are insecure and no longer supported. Rather than: Deprecated: 2.30: NPAPI browser plugins are insecure and will no longer be supported in 2.32. And then later changing it to: Deprecated: 2.30: NPAPI browser plugins are insecure and no longer supported since 2.32. So let's wait until branching.
On Jul 20, 2020, at 10:23 AM, Darin Adler <darin@apple.com> wrote:
On Jul 20, 2020, at 7:35 AM, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
Then we can make the plugin process specific to PLATFORM(COCOA)
Side note: It will be specific to PLATFORM(MAC).
And we’ll probably attempt to remove it from PLATFORM(MAC) once we get data on the compatibility impact of doing so. Regards, Maciej
participants (5)
-
Adrian Perez de Castro
-
Brent Fulgham
-
Darin Adler
-
Maciej Stachowiak
-
Michael Catanzaro