The Chrome Plugin Support Update
As you may or may not be aware, Google announced earlier this year that they will be pulling support for plugins from Chrome. Unfortunately, they have been fairly tight-lipped on the details and timing. But, over the last few months they have taken a few steps in this direction, adding more speed bumps for any users who wish to permit plugin use within Chrome, and completely disabling plugins on Linux already (as of v35). Google has not yet announced exactly when plugin support will be fully discontinued, but alluded to sometime around the end of 2014. There are two critical questions that will affect our recommendation to clients and future development in this area:

- When will plugin support finally be completely deactivated? (Google won’t say.)

- Will Java still be supported? (Java is currently a functional alternative to using our browser plugin, though we initially built the plugin because many clients wanted to move away from Java.)

Since we heard the news, we have been brainstorming on how best to replace the Shotgun functionality that is facilitated by our custom browser plugin. This includes Local File Linking and some Pipeline Toolkit functions, all of which need some sort of added tech to work around the standard browser security that disallows interaction with the file system from a web page. See this post in our GitHub repo for a bit more background.

Our long term plan is to work this functionality into our Shotgun Desktop client, but we are still in progress on that solution. We originally hoped to have it ready before the end of the year, but we need a bit more time to ensure we have a production-ready replacement. We are now aiming to deploy the new setup in a patch release in early 2015. Also, since locally hosted clients are traditionally delayed on new releases, it could take longer for them to receive the replacement solution compared to clients on hosted sites.

If your studio depends on Chrome and uses Shotgun’s Local File Linking or Pipeline Toolkit functionality, we strongly recommend that you have a contingency plan in place. Current workarounds include:

- Use another supported browser
- Lock off on a version of Chrome that still supports plugins - delay upgrading to the version where plugin support is pulled (of course this may carry some risk, as you may miss out on patches for any security vulnerabilities that are/were discovered after that version’s release)

We know this is not the best news for Chrome users, but it is unfortunately not entirely in our control, and we felt it would be prudent to warn you of the impending situation now so you have time to make alternate plans.

Of course, as always, if you have any questions or concerns, please reach out to our support team and we will do our best to work through this with you and find an acceptable solution.


Cheers,
The Shotgun Team

4 Comments


At November 20, 2014 at 7:43 AM , Blogger Alan said...

FYI with "native messaging" in the newest APIs, a Chrome extension can be permitted to "talk" to an external executable:
https://developer.chrome.com/extensions/messaging#native-messaging
https://developer.chrome.com/extensions/runtime#method-connectNative
https://developer.chrome.com/extensions/runtime#method-sendNativeMessage

Perhaps a temp workaround could be done where the existing extension is adapted to work as a host outside the browser sandbox and the new extension can just communicate with it?

 

At November 20, 2014 at 10:53 PM , Blogger Jimmy Christensen said...

Speaking of Shotgun Desktop. When will you support distros other than Centos/Fedora?

 

At December 3, 2014 at 10:12 AM , Blogger ryanmayeda said...

Hi Jimmy!

What Linux distro do you use?

Ryan.

 

At December 3, 2014 at 10:25 AM , Blogger Rob Blau said...

Hi Alan,

We did investigate native messaging, which is Google's answer to how to talk to a locally running application. That approach would work, but would be Chrome specific and would require registering applications for native message in an OS specific way.

We opted to go with websockets because they allow the same functionality without the need for that registration, and because they are HTML5 standard rather than a Google specific implementation. After having the NPAPI deprecated by Google, it felt safer to move forward with something more standard. Websockets also allow us to have OS and browser independent code.

We've been following the discussion on the FireBreath wiki and mailing list, where there has been an extensive thread about what the options are to replace the deprecated NPAPI functionality.

The wiki page that summarizes the options is here:
http://www.firebreath.org/display/documentation/Browser+Plugins+in+a+post-NPAPI+world

 

Post a Comment

<< Home

<< Older Posts     Newer Posts >>

Our Story

We are industry folk who love production. A handful of us met while building...
Read More

Subscribe to Our Blog

Follow Us!