Closed Bug 1514809 Opened 2 years ago Closed 1 year ago

Enable userScripts API on release channels

Categories

(WebExtensions :: General, enhancement, P1)

64 Branch
enhancement

Tracking

(firefox68 verified, firefox69 verified)

VERIFIED FIXED
mozilla69
Tracking Status
firefox68 --- verified
firefox69 --- verified

People

(Reporter: robwu, Assigned: zombie)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed)

Attachments

(1 file)

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.
Depends on: 1468579
Blocks: 1516478
Depends on: 1445909
Assignee: nobody → lgreco
Priority: -- → P1

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).

Flags: needinfo?(ismith)
Keywords: dev-doc-needed

(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.

Flags: needinfo?(ismith)

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.

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/

Assignee: lgreco → tomica
Status: NEW → ASSIGNED

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).

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?

Flags: needinfo?(rob)

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.

No longer depends on: 1445909
Flags: needinfo?(rob)
No longer depends on: 1468579
Pushed by tomica@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/e3e8eaff2fd1
Enable userScripts API on release by default r=kmag

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
Attachment #9069093 - Flags: approval-mozilla-beta?
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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 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.

Attachment #9069093 - Flags: approval-mozilla-beta? → approval-mozilla-beta-

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.

Flags: needinfo?(jcristau)

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. :\

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 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 :)

Flags: needinfo?(jcristau)
Attachment #9069093 - Flags: approval-mozilla-beta- → approval-mozilla-beta+

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.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.