You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flagon.apache.org by Joshua Poore <po...@me.com.INVALID> on 2022/11/06 22:25:57 UTC
Re: Web Extension updates
Hi All—
Update:
My team here at UMD has been working on the plugin a bit.
Completely agree with @Rob Foley.
Issues are as follows:
1. Chrome is deprecating MV2 in Jan. We have a nice MV3 version of the Chrome plugin that builds off the example I committed some time ago.
2. FF is following suite with Chrome, but not likely on the same timeline. Notably, they claim that they *will* support background service workers, but not yet. Currently, their MV3 build utilizes “background scripts”. While we do have a working MV3 build for FF, it is not compatible with Chrome, and won’t be until they roll out support for background service workers.
3. We’ve not yet tested on Edge.
I think the near term decision is really which browser build we want to keep on Master. At this point, I see it as a forced choice between Chrome and FF. Certainly we can keep an otherwise level branch that supports the other.
Given that FF eventually will move to Background scripts, I propose:
1. Add support for MV3 for Chrome on Master
2. Keep a branch that supports MV2 (for near term FF support—they are keeping support for MV2 for the near term)
3. Add support for MV3 for FF (and Edge) when FF adds support for Background Service Workers.
Thoughts?
J
> On Sep 2, 2022, at 1:38 PM, Rob Foley <rf...@apache.org> wrote:
>
> I don't recall enough about our initial browser compatibility list, but, if we haven't yet already deprecated IE support, this will do it. For the sake of correctness, |fetch| isn't a protocol, it is just a browser API. Both the |fetch| and |XMLHttpRequest| APIs will make essentially the same |POST| requests.
>
> Here is the browser compatibility list for |fetch|, the picture for the |Service Workers| is similar:
> https://caniuse.com/fetch
>
> On the subject of compatibility, keep in mind that the switch to Manifest V3 will also mean immediate loss of compatibility with the earlier versions of Chrome/Firefox/Edge, since the change isn't backwards compatible. With that in mind, it may be wise for us to temporarily/permanently keep an older Manifest V2 version published.
>
> Regards,
> Rob
>
> On 8/29/2022 9:49 PM, Austin Bennett wrote:
>> Great to be updating to keep compatibility. A web-based tool without
>> chrome and Firefox compatibility seems ... not desirable.
>>
>> I haven't used that part of the tooling. Naturally, if you think valuable,
>> then it seems worth the effort. Not into the specifics enough to have a
>> worthwhile opinion on implementation.
>>
>> Since this is designed to continue functionality, i would expecr changes
>> needed to support to be not especially contentious even if involved
>> significant modification.
>>
>> It sounds like this can be done without breaking things for our users, if
>> that's the case then not concerned about version numbering.
>>
>>
>>
>> On Mon, Aug 29, 2022, 6:28 PM Joshua Poore<po...@apache.org> wrote:
>>
>>> All,
>>>
>>> Looking for comments on this:
>>>
>>> I think there are only few end users that actually use our Web Extension,
>>> however, it’s a pretty valuable tool in user testing uninstrumented
>>> applications.
>>>
>>> Presently, our WebExtension (on Master) is Manifest v2. However, as you
>>> may be aware Chrome is moving to Manifest v3 (MV3). MV2 will be unsupported
>>> by chrome following Dec 2022.
>>>
>>> https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/ < https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/>
>>>
>>> Mozilla/FireFox is following suite, but slowly.
>>>
>>>
>>> https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/
>>> <
>>> https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/
>>> There are some major breaking changes in MV3 that require a bit of
>>> re-engineering in our code base to address. Specially, the big breaking
>>> change is that Background Pages (as scripts) are not supported. Instead,
>>> MV3 moves to a more secure Service Worker model. Service workers will not
>>> support XMLHttpRequest as a POST protocol—they’ll only support Fetch.
>>>
>>> Fetch isn’t a protocol UserALE.js supports and given that UserALE.js is
>>> built directly into the WebExtension, to fix the later we have to mod the
>>> former.
>>>
>>> Proposal:
>>>
>>> 1. Add Fetch protocol to SendLogs as alternative POST method
>>> 2. Add `options` setting allowing users to specify which method is used
>>> (`fetch`, `XMLhttpResquest`), default is XMLHttpRequest.
>>> 3. Configure plugin to specify `fetch` as method in globals
>>>
>>> I built a WIP of this approach, and find that the MV3 spec of the
>>> WebExtension deploys and generates logs without error in Chrome. I’ve
>>> pushed it to a dev branch that can be found here:
>>>
>>> https://github.com/apache/incubator-flagon-useralejs/tree/MV3-update < https://github.com/apache/incubator-flagon-useralejs/tree/MV3-update>
>>>
>>> Note that FireFox has not fully implemented MV3. I have tested on Firefox,
>>> but testing has failed. Still a few more params to set in Firefox.
>>> Expecting that we should push solution to Master (and release) late in Q4
>>> 2022.
>>>
>>> Eager to hear comments,
>>>
>>> Josh
>>>
>>>
Re: Web Extension updates
Posted by Joshua Poore <po...@me.com.INVALID>.
Austin—
You articulated the real issue better than I did:
Given Chromes timeline, and FF’s (which have bigger market share than Edge), we may be in the situation where one )or more) of our releases drops web extension support for one or more browsers…
I think we can coast on MV2 for the time being (as you note) but Chrome’s timeline is sooner and more firm than FF’s. My proposal is that we favor Chrome if/when we’re in a forced choice as to which MV3 build we want to merge with master (release branch).
Again, we can maintain branches that support FF/edge, simultaneously, but there is scenario in which we have to choose which build is on master. I think we should go with Chrome.
Joshua Poore
> On Nov 6, 2022, at 5:35 PM, Austin Bennett <au...@apache.org> wrote:
>
> Looks like Chrome might be slightly more generous on the deprecation
> timeline: https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/
> But, that needn't change the steps proposed here.
>
> From a user/use-case perspective, would it be better to think about what
> browser is supported from master? Rather than feature? We are confident
> that are always supporting X Browser, which can be better publicized, and
> made clear [ ex: it seems feasible if maintaining different
> implementations, whatever is not on master might fall behind ].
>
> Also, IIRC, ASF releases are about the artifact being
> produced/tested/released. Is the plan to release versions from the
> proposed multiple supported branches? Or only release the chrome version
> from master?
>
>
>
>> On Sun, Nov 6, 2022 at 2:26 PM Joshua Poore <po...@me.com.invalid> wrote:
>>
>> Hi All—
>>
>> Update:
>>
>> My team here at UMD has been working on the plugin a bit.
>>
>> Completely agree with @Rob Foley.
>>
>> Issues are as follows:
>>
>> 1. Chrome is deprecating MV2 in Jan. We have a nice MV3 version of the
>> Chrome plugin that builds off the example I committed some time ago.
>>
>> 2. FF is following suite with Chrome, but not likely on the same timeline.
>> Notably, they claim that they *will* support background service workers,
>> but not yet. Currently, their MV3 build utilizes “background scripts”.
>> While we do have a working MV3 build for FF, it is not compatible with
>> Chrome, and won’t be until they roll out support for background service
>> workers.
>>
>> 3. We’ve not yet tested on Edge.
>>
>> I think the near term decision is really which browser build we want to
>> keep on Master. At this point, I see it as a forced choice between Chrome
>> and FF. Certainly we can keep an otherwise level branch that supports the
>> other.
>>
>> Given that FF eventually will move to Background scripts, I propose:
>>
>> 1. Add support for MV3 for Chrome on Master
>> 2. Keep a branch that supports MV2 (for near term FF support—they are
>> keeping support for MV2 for the near term)
>> 3. Add support for MV3 for FF (and Edge) when FF adds support for
>> Background Service Workers.
>>
>> Thoughts?
>>
>> J
>>
>>>> On Sep 2, 2022, at 1:38 PM, Rob Foley <rf...@apache.org> wrote:
>>>
>>> I don't recall enough about our initial browser compatibility list, but,
>> if we haven't yet already deprecated IE support, this will do it. For the
>> sake of correctness, |fetch| isn't a protocol, it is just a browser API.
>> Both the |fetch| and |XMLHttpRequest| APIs will make essentially the same
>> |POST| requests.
>>>
>>> Here is the browser compatibility list for |fetch|, the picture for the
>> |Service Workers| is similar:
>>> https://caniuse.com/fetch
>>>
>>> On the subject of compatibility, keep in mind that the switch to
>> Manifest V3 will also mean immediate loss of compatibility with the earlier
>> versions of Chrome/Firefox/Edge, since the change isn't backwards
>> compatible. With that in mind, it may be wise for us to
>> temporarily/permanently keep an older Manifest V2 version published.
>>>
>>> Regards,
>>> Rob
>>>
>>> On 8/29/2022 9:49 PM, Austin Bennett wrote:
>>>> Great to be updating to keep compatibility. A web-based tool without
>>>> chrome and Firefox compatibility seems ... not desirable.
>>>>
>>>> I haven't used that part of the tooling. Naturally, if you think
>> valuable,
>>>> then it seems worth the effort. Not into the specifics enough to have a
>>>> worthwhile opinion on implementation.
>>>>
>>>> Since this is designed to continue functionality, i would expecr changes
>>>> needed to support to be not especially contentious even if involved
>>>> significant modification.
>>>>
>>>> It sounds like this can be done without breaking things for our users,
>> if
>>>> that's the case then not concerned about version numbering.
>>>>
>>>>
>>>>
>>>> On Mon, Aug 29, 2022, 6:28 PM Joshua Poore<po...@apache.org> wrote:
>>>>
>>>>> All,
>>>>>
>>>>> Looking for comments on this:
>>>>>
>>>>> I think there are only few end users that actually use our Web
>> Extension,
>>>>> however, it’s a pretty valuable tool in user testing uninstrumented
>>>>> applications.
>>>>>
>>>>> Presently, our WebExtension (on Master) is Manifest v2. However, as you
>>>>> may be aware Chrome is moving to Manifest v3 (MV3). MV2 will be
>> unsupported
>>>>> by chrome following Dec 2022.
>>>>>
>>>>> https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/
>> < https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/>
>>>>>
>>>>> Mozilla/FireFox is following suite, but slowly.
>>>>>
>>>>>
>>>>>
>> https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/
>>>>> <
>>>>>
>> https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/
>>>>> There are some major breaking changes in MV3 that require a bit of
>>>>> re-engineering in our code base to address. Specially, the big breaking
>>>>> change is that Background Pages (as scripts) are not supported.
>> Instead,
>>>>> MV3 moves to a more secure Service Worker model. Service workers will
>> not
>>>>> support XMLHttpRequest as a POST protocol—they’ll only support Fetch.
>>>>>
>>>>> Fetch isn’t a protocol UserALE.js supports and given that UserALE.js is
>>>>> built directly into the WebExtension, to fix the later we have to mod
>> the
>>>>> former.
>>>>>
>>>>> Proposal:
>>>>>
>>>>> 1. Add Fetch protocol to SendLogs as alternative POST method
>>>>> 2. Add `options` setting allowing users to specify which method is used
>>>>> (`fetch`, `XMLhttpResquest`), default is XMLHttpRequest.
>>>>> 3. Configure plugin to specify `fetch` as method in globals
>>>>>
>>>>> I built a WIP of this approach, and find that the MV3 spec of the
>>>>> WebExtension deploys and generates logs without error in Chrome. I’ve
>>>>> pushed it to a dev branch that can be found here:
>>>>>
>>>>> https://github.com/apache/incubator-flagon-useralejs/tree/MV3-update
>> < https://github.com/apache/incubator-flagon-useralejs/tree/MV3-update>
>>>>>
>>>>> Note that FireFox has not fully implemented MV3. I have tested on
>> Firefox,
>>>>> but testing has failed. Still a few more params to set in Firefox.
>>>>> Expecting that we should push solution to Master (and release) late in
>> Q4
>>>>> 2022.
>>>>>
>>>>> Eager to hear comments,
>>>>>
>>>>> Josh
>>>>>
>>>>>
>>
>>
Re: Web Extension updates
Posted by Austin Bennett <au...@apache.org>.
Looks like Chrome might be slightly more generous on the deprecation
timeline: https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/
But, that needn't change the steps proposed here.
From a user/use-case perspective, would it be better to think about what
browser is supported from master? Rather than feature? We are confident
that are always supporting X Browser, which can be better publicized, and
made clear [ ex: it seems feasible if maintaining different
implementations, whatever is not on master might fall behind ].
Also, IIRC, ASF releases are about the artifact being
produced/tested/released. Is the plan to release versions from the
proposed multiple supported branches? Or only release the chrome version
from master?
On Sun, Nov 6, 2022 at 2:26 PM Joshua Poore <po...@me.com.invalid> wrote:
> Hi All—
>
> Update:
>
> My team here at UMD has been working on the plugin a bit.
>
> Completely agree with @Rob Foley.
>
> Issues are as follows:
>
> 1. Chrome is deprecating MV2 in Jan. We have a nice MV3 version of the
> Chrome plugin that builds off the example I committed some time ago.
>
> 2. FF is following suite with Chrome, but not likely on the same timeline.
> Notably, they claim that they *will* support background service workers,
> but not yet. Currently, their MV3 build utilizes “background scripts”.
> While we do have a working MV3 build for FF, it is not compatible with
> Chrome, and won’t be until they roll out support for background service
> workers.
>
> 3. We’ve not yet tested on Edge.
>
> I think the near term decision is really which browser build we want to
> keep on Master. At this point, I see it as a forced choice between Chrome
> and FF. Certainly we can keep an otherwise level branch that supports the
> other.
>
> Given that FF eventually will move to Background scripts, I propose:
>
> 1. Add support for MV3 for Chrome on Master
> 2. Keep a branch that supports MV2 (for near term FF support—they are
> keeping support for MV2 for the near term)
> 3. Add support for MV3 for FF (and Edge) when FF adds support for
> Background Service Workers.
>
> Thoughts?
>
> J
>
> > On Sep 2, 2022, at 1:38 PM, Rob Foley <rf...@apache.org> wrote:
> >
> > I don't recall enough about our initial browser compatibility list, but,
> if we haven't yet already deprecated IE support, this will do it. For the
> sake of correctness, |fetch| isn't a protocol, it is just a browser API.
> Both the |fetch| and |XMLHttpRequest| APIs will make essentially the same
> |POST| requests.
> >
> > Here is the browser compatibility list for |fetch|, the picture for the
> |Service Workers| is similar:
> > https://caniuse.com/fetch
> >
> > On the subject of compatibility, keep in mind that the switch to
> Manifest V3 will also mean immediate loss of compatibility with the earlier
> versions of Chrome/Firefox/Edge, since the change isn't backwards
> compatible. With that in mind, it may be wise for us to
> temporarily/permanently keep an older Manifest V2 version published.
> >
> > Regards,
> > Rob
> >
> > On 8/29/2022 9:49 PM, Austin Bennett wrote:
> >> Great to be updating to keep compatibility. A web-based tool without
> >> chrome and Firefox compatibility seems ... not desirable.
> >>
> >> I haven't used that part of the tooling. Naturally, if you think
> valuable,
> >> then it seems worth the effort. Not into the specifics enough to have a
> >> worthwhile opinion on implementation.
> >>
> >> Since this is designed to continue functionality, i would expecr changes
> >> needed to support to be not especially contentious even if involved
> >> significant modification.
> >>
> >> It sounds like this can be done without breaking things for our users,
> if
> >> that's the case then not concerned about version numbering.
> >>
> >>
> >>
> >> On Mon, Aug 29, 2022, 6:28 PM Joshua Poore<po...@apache.org> wrote:
> >>
> >>> All,
> >>>
> >>> Looking for comments on this:
> >>>
> >>> I think there are only few end users that actually use our Web
> Extension,
> >>> however, it’s a pretty valuable tool in user testing uninstrumented
> >>> applications.
> >>>
> >>> Presently, our WebExtension (on Master) is Manifest v2. However, as you
> >>> may be aware Chrome is moving to Manifest v3 (MV3). MV2 will be
> unsupported
> >>> by chrome following Dec 2022.
> >>>
> >>> https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/
> < https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/>
> >>>
> >>> Mozilla/FireFox is following suite, but slowly.
> >>>
> >>>
> >>>
> https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/
> >>> <
> >>>
> https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/
> >>> There are some major breaking changes in MV3 that require a bit of
> >>> re-engineering in our code base to address. Specially, the big breaking
> >>> change is that Background Pages (as scripts) are not supported.
> Instead,
> >>> MV3 moves to a more secure Service Worker model. Service workers will
> not
> >>> support XMLHttpRequest as a POST protocol—they’ll only support Fetch.
> >>>
> >>> Fetch isn’t a protocol UserALE.js supports and given that UserALE.js is
> >>> built directly into the WebExtension, to fix the later we have to mod
> the
> >>> former.
> >>>
> >>> Proposal:
> >>>
> >>> 1. Add Fetch protocol to SendLogs as alternative POST method
> >>> 2. Add `options` setting allowing users to specify which method is used
> >>> (`fetch`, `XMLhttpResquest`), default is XMLHttpRequest.
> >>> 3. Configure plugin to specify `fetch` as method in globals
> >>>
> >>> I built a WIP of this approach, and find that the MV3 spec of the
> >>> WebExtension deploys and generates logs without error in Chrome. I’ve
> >>> pushed it to a dev branch that can be found here:
> >>>
> >>> https://github.com/apache/incubator-flagon-useralejs/tree/MV3-update
> < https://github.com/apache/incubator-flagon-useralejs/tree/MV3-update>
> >>>
> >>> Note that FireFox has not fully implemented MV3. I have tested on
> Firefox,
> >>> but testing has failed. Still a few more params to set in Firefox.
> >>> Expecting that we should push solution to Master (and release) late in
> Q4
> >>> 2022.
> >>>
> >>> Eager to hear comments,
> >>>
> >>> Josh
> >>>
> >>>
>
>