1514809 - Enable userScripts API on release channels

Status: VERIFIED FIXED

(WebExtensions :: General, enhancement, P1)

Description

[Rob Wu [:robwu]]

The userScripts API is disabled by default; the extensions.webextensions.userScripts.enabled defaults to false.

If the API is ready, this preference value should be flipped to true.

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Irene,
Per Bug 1437861 comment 55 we put the documentation for this API on hold because it wasn't yet planned to be enabled on non-Nightly channels, but we have now agreed that we will start promoting this API to the extension developers community while it is still preffed off, can we add it back to dev-doc-needed queue?

(I'm also moving the dev-doc-needed flag from Bug 1437861 and Bug 1437864 on this one, so that we can keep track of the progress related to the docs for this API from a single bugzilla issue).

Comment 2

[Irene Smith]

(In reply to Luca Greco [:rpl] from comment #1)

Hi Irene,
Per Bug 1437861 comment 55 we put the documentation for this API on hold because it wasn't yet planned to be enabled on non-Nightly channels, but we have now agreed that we will start promoting this API to the extension developers community while it is still preffed off, can we add it back to dev-doc-needed queue?

(I'm also moving the dev-doc-needed flag from Bug 1437861 and Bug 1437864 on this one, so that we can keep track of the progress related to the docs for this API from a single bugzilla issue).

Thank you. I've updated my own tasks for this and will make this the primary bug to track the work I've done.

Comment 3

[Mike Conca [:mconca]]

68 is now in the Nightly channel. We should flip the pref to true soon so that we get as much exposure and testing as possible before 68 reaches beta.

Comment 4

[Tomislav Jovanovic :zombie]

Unless there are reasons that I'm not aware of, it looks like this slipped through, and should have been enabled on release two trains ago [1].

Luca seems to be out till next week, so I'm gonna take over, to start the ball rolling in hope we can uplift to current Beta 68.

[1] https://blog.mozilla.org/addons/2019/03/26/extensions-in-firefox-67/

Comment 5

[Tomislav Jovanovic :zombie]

I went through the blocking bugs, and I don't think they need to be blocking the pref flip for release:

Bug 1445909 - Original design there was done before the final API (with the added onBeforeScript event) landed, so the actual way we handle it will likely be slightly different. Implementing for example a script.cancel() method to that API seems strictly additive, and so doesn't need to be done before the main API is enabled.

Bug 1468579 - This one is a bit trickier, since it represents a potential security footgun for providers of userScripts addons. But workarounds exist, and we'll make sure to document and point out the issue in our Intent To Ship announcement.

Additionally, it looks like MDN documentation might not be done before 68 hits release, so we can treat this as a "soft launch" in 68, with the two bugs listed above landing in 69 (I don't recommend rushing and uplifting those to 68).

Comment 6

[Tomislav Jovanovic :zombie]

Hey Rob, it looks like your proposal in bug 1468579 got an OK from Bobby, do you think you could finish that and land during 69?

Comment 7

[Rob Wu [:robwu]]

Removing bug 1445909 as a blocker; it is already part of the bug 1437098 for follow-up work.
While it would be nice to have additional matching capabilities in the onBeforeScript event, it does not block release. Extensions who wish to have additional matching logic can wrap the scripts in a closure, e.g.

if (location.hostname == "example.com") (() => {/*Actual user script code here*/})();

Bug 1468579 is too large for 68, so it will roll with 69. The intended change will reduce the amount of magic behavior of the sandbox. Add-ons are advised to not directly assign to the sandbox, but use userScripts.defineGlobals and userScripts.export when they want to create JS objects for use by user scripts in the sandbox. Once the patch has landed, I will write a detailed list of changes to allow add-on authors to update their code if needed.

Comment 8

[Tomislav Jovanovic :zombie]

Attachment: Bug 1514809 - Enable userScripts API on release by default r=kmag

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e3e8eaff2fd1
Enable userScripts API on release by default r=kmag

Comment 10

[Tomislav Jovanovic :zombie]

Comment on attachment 9069093 [details]
Bug 1514809 - Enable userScripts API on release by default r=kmag

Beta/Release Uplift Approval Request

• User impact if declined: A new web extensions API will not be available to developers, and thus a whole category of addons will not be available to users.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is just a pref-flip for a new API that's been tested on Nightly for 3 trains, now enabling on beta/release channels.
• String changes made/needed: N/A

Comment 11

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/e3e8eaff2fd1

Comment 12

[ExE Boss]

Personally, I’d prefer to ship this with the Xray footgun (bug 1468579) fixed, possibly with a way for the extension to control it, since legacy GreaseMonkey 3 scripts don’t use Xrays.

Comment 13

[Julien Cristau [:jcristau] (back April 22)]

Comment on attachment 9069093 [details]
Bug 1514809 - Enable userScripts API on release by default r=kmag

I'm not seeing a strong justification to have this skip a train. Please elaborate if I'm missing something.

Comment 14

[Tomislav Jovanovic :zombie]

This is not skipping a train, it has been available behind a pref, enabled by default in Nightly since 66, and was planned and announced to be enabled for release in 68 months ago, see: https://blog.mozilla.org/addons/2019/03/26/extensions-in-firefox-67/#userscripts

There were no bugs reported or changes to the code since it landed in 66, it just looks like it slipped people's mind in the aftermath of addongeddon.

Comment 15

[David Durst [:ddurst]]

FWIW, I assume this was used in Nightly by the same people who would use it in Beta, which is developers of Greasemonkey and Tampermonkey -- who have been telling people to flip this (already) to be able to use it. We haven't seen any issues with this, and I assume this is the same issue of me not ensuring this is flipped like we said it was going to be. :\

Comment 16

[erosman]

I have been using the API on nightly since FF65 and my addon 'FireMonkey' has been on AMO since before the release of FF65 and I have not had any issues with the API.

Comment 17

[Julien Cristau [:jcristau] (back April 22)]

Comment on attachment 9069093 [details]
Bug 1514809 - Enable userScripts API on release by default r=kmag

enable new extension api in 68.0b8.

let's try and be better about landing this as planned next time around please :)

Comment 18

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/9c1d9d159b46

Comment 19

[Victor Carciu]

Verified as fixed in FF68.0b11 and Firefox 69.0a1 (2019-06-24) on Windows 10x64 and macOS 10.14.5 . The pref was switched to true everywhere.

Comment 20

[Richard Bloor]

From the commit list on Github, I couldn't find any evidence that information about this preference had been removed from the documentation (nor that it was included in the first place). The change is noted in the 69 release notes. As this API will also be deprecated at some point as part of MV3, I don't see any need to document the preference and have changed to dev-doc-complete.