← Back to team overview

webapps team mailing list archive

Re: Chromium and NPAPI


You can see a brief overview on what things might look like here; <

Feel free to edit/comment.

- Justin

On Sat, Apr 19, 2014 at 12:40 AM, Alexandre Abreu <
alexandre.abreu@xxxxxxxxxxxxx> wrote:

> On Tue, Apr 15, 2014 at 10:58 AM, Alberto Mardegan <
> alberto.mardegan@xxxxxxxxxxxxx> wrote:
>> Our unity-chromium-extensions is using the NPAPI which has been
>> deprecated last year and will soon stop working (updates will be blocked
>> already in May!)[0].
> definitely ! we had this in mind since early 2014,
> the deprecation will come soon now (starting w/ Linux as always w/
> upstream chromium),
>> When planning for a replacement, I'd like we put some efforts in
>> integrating the Online Accounts experience as well, in order to minimize
>> the amount of extensions we produce.
> Agree, the thing is now the extensions perse are way more minimal than what
> they were previously, so more manageable (some cleanup is still necessary),
> so adding OA into the mix wont make explode,
>> For the record, the existing (but not used) Online Accounts extension is
>> here (both for Firefox and Chromium):
>> http://bazaar.launchpad.net/~online-accounts/webaccounts-browser-extension/trunk/files
>> From the Online Accounts POV, the required informations are: the domain,
>> the username (or anyway an identifier for the user, though we might even
>> do without it maybe) and the cookies.
>> The cookies can be obtained with a specific extension[1], and I believe
>> that they should be useful for the webapp story as well, if we manage to
>> reuse them the first time that the webapp is started.
>> My impression is that we should have an extension which is as slim as
>> possible: only captures the required information, and then delegates all
>> the work of setting up the webapp (and creating the online account) to
>> an external process. In this way we can hopefully share as much code as
>> possible with the Mozilla extension.
> well as much as we can yes, but from experience code sharing has always
> been
> quite tricky in those areas a minimal (we tried since when I joined) since
> the 2
> structure and logic do follow very different flows,
> we can share (as we do already) some helper/small functions or possibly
> some classes
> that encapsulate units of logic (that do not interfere w/ the flow, e.g.
> cookie manipulation),
> After a very quick glance at the options, I find the Native Messaging
>> extension [2] the most suitable for our needs, because my understanding
>> is that a NaCl would be confined, and it's not clear to me in which
>> ways. But that's just my first impression.
> this is what we had in mind already, Justin did some experiemnts w/ it and
> it
> is what is recommended by upstream as a replacement (and is out of process
> which
> is good crash wise),
> The things though, is that there is one thing that we should think about.
> We dont inject
> scripts anymore in the extensions. They are mostly used to install the
> webapps that we
> support and do some light management.
> Now, we would need to reinject some script to access the DOM & capture the
> userid & cookies.
> Those would be lighter than the one used previously. We would need a to
> add them to the webapps
> packages in a meaningful way (or reuse the same script in line 2 different
> mode? might make
> things more complex for nothing ...),
> --
> Mailing list: https://launchpad.net/~webapps
> Post to     : webapps@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~webapps
> More help   : https://help.launchpad.net/ListHelp

Follow ups