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 <poor...@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 <r...@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<poor...@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 > >>> > >>> > >
