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
