pepper plugin path is hard coded in the source

[Sam Segers]

Could it be possible for click apps to have the plugin bundled?

An environment variable should be nice. Or in the ./lib/<triplet>/PepperFlash directory of the click app.

Now it's hard coded to the location of the adobe plugin or the chrome version.

It would be nice to be able to package it with the click as it then could be used on systems that don't have it.

I also have this problem with chrome-beta installed. I had to symlink /opt/google/chrome-beta to /opt/google/chrome to make it work.

The same problem is true with chrome-daily.

[Olivier Tilloy (osomon)]

This is where the paths are hardcoded: https://git.launchpad.net/oxide/tree/shared/common/oxide_paths.cc#n30.

[David Barth (dbarth)]

Hi,

To your question about bundling the plugin into a click/snap: you cannot unfortunately. You would need a specific licence for redistributing the plugin.

This explains why the plugin is searched for in standard, hard-coded, locations in Oxide.

The chrome vs chrome-beta part is probably due to an extra check done inside that browser, but that is not related to Oxide.

[Chris Coulson (chrisccoulson)]

Oxide not looking in /opt/google/chrome-beta and /opt/google/chrome-unstable is a deliberate limitation - stable versions of Oxide shouldn't be loading pre-release versions of the Flash player just because you've got Chrome Beta or Chrome Dev installed.

Using the Flash Player from the partner repository is preferable over what is bundled with Chrome anyway. However, this currently doesn't work because of a packaging error with that (will be fixed with the next Flash Player update)

[Sam Segers (sam-sgrs)]

Thanks for the quick reactions.

I also was looking at a way of bundling the arm version from chromeos.
Haven't tried it yet tho. It works on ubuntu on the Pi3, so it could work.

But without the licensing I get that it won't be allowed in production.

[Chris Coulson (chrisccoulson)]

The arm plugin from chromeos isn't going to work anyway, as we're disabling plugin support on arm builds in an effort to trim the binary size, due to persistent build issues with 32-bit architectures