New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebExtension compatibility #2275
Comments
I've been thinking about this a bunch. I don't have a clear "decision", but some points:
|
Starting with a design doc would be a great idea. Essentially we need to reverse engineer all of Greasemonkey as it exists into a plan for a good way, rather than an unplanned organically grown way, for all of it to be structured. |
I'm certainly not advocating using WebExtensions yet, they are way to immature for something like GM
Hrm, well, I was looking at it mostly from a technology POV. Right now the UI uses XUL overlays and direct script execution in the shared chrome environment. So converting things to HTML and running each things in an independent window context and only communicate via message-passing seem to be how things are supposed to be done in the future. The message manager is basically the lowest level where that's implemented. Higher level abstractions build on that. WebChannel.jsm/BroadcasstChannel/MessageChannel/WebExtension channels and such.
Would the GH wiki be the right place for that? Does it do notifications on edit to make collaborative work simple? I think we mostly need a feature / internal plumbing list and how to implement each in a clean manner. |
If you're interested in this issue's topic, please read: https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion Thanks! |
https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction This is a super interesting API, but "This feature is non-standard and is not on a standards track" and compatibility is very limited. |
All my recent attempts (see #2483, #2484) at designing fully-featured Greasemonkey-under-WebExtensions have been frustrating. I'm starting to consider a more progressive style of development: pick a more limited set of features and support only that. Be a little bit useful, then hopefully find a path towards more functionality later. Inspecting my 3.x install, I see that (for me) every single script is So that seems like a decent target to aim for first: Support plain user scripts in (Side note, because I keep forgetting it: Plan to use sourceURL to make errors slightly more readable. Look into whether multiple sourceURLs are supported, or whether we'd have to (can we?) generate a sourceMap, factoring |
We get access to plain Web APIs in addition to WebExtension ones, so: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API ? What's the storage limit of IndexedDB, for a WebExtension? This looks like a much better option than |
mdn/webextensions-examples#171 seems to have valuable discussion and example for IndexedDB |
I've made some progress. https://github.com/arantius/greasemonkey/tree/webbymonkey (at 88d53b4 ) Reimplemented from scratch. Check out, go to |
Since older versions of Tampermonkey, as well as Violentmonkey, are open source, could some of that code be used here, since WebExtensions is similar to Chromium Extensions? |
@PorygonZRocks: Violentmonkey becoming Greasemonkey? |
I'm not very experienced with coding, but I was thinking it could at least have some guidelines on implementing things. Again, not very experienced/knowledgeable, so I may be wrong. |
It is worth noting that FF56 disabled all non-multiprocess compatible addons so the deadline might need to change. |
See my dev branch. Which is quite rough but is minimally functional. This is being done, there's nothing to track specifically in this broadly scoped issue. |
@arantius Out of curiosity, are you writing new code or reusing the old? Do you need help? Again out of curiosity, for example, is the purpose of "parse-meta-line.js" is merely to parse the meta data into an object? |
Mostly new. Copying when/where it's helpful. (So far, script parsing is a big example.)
Help would be nice. Coordinating would be hard.
One line of it, yes. |
It seems like a lot of code if that is the only objective. |
Yes that's what it does. It's generated code. Please take this discussion to https://groups.google.com/d/topic/greasemonkey-dev . |
I don't use Google groups :( |
The google group does not exist anymore. |
Not entirely sure if this is the correct location for it, but here it is anyway. If you want me to open a separate issue @arantius, sure. |
@Phyxion, if you install 3.14 then the scripts should be migrated. Make sure you restart the browser after installing. After that when you install 4.x you should have the scripts. If you don't then some detailed reproduction steps in a new issue would be helpful. |
Greasemonkey 4 alpha is incompatible with Firefox 57. |
@erkinalp, Could you elaborate? I've been using 4alpha2 for a lot of my testing and modifications, it works, although not all features in 3.x are available. I haven't pulled the changes in 4alpha3, so I don't know the few commits for that version break anything. |
@Sxderp Well, reproducing it on my machine is easy. I have 3.14 installed with 10 user scripts. Go to AMO and download the latest alpha. Restart when asked. Then it just says there are no userscripts installed. Not sure how useful this for reproducing it. |
I haven't tested this yet but I believe GM4 should lose its configuration after an uninstall, while GM3 should keep it, so I'd suggest you try:
Does that help? |
I think the top level await - i.e. wrapping everything in an async function - is a not a good design choice since it restricts future implementations (e.g. if/when we get sandboxes back or es-future realms). It makes things inconsistent with vanilla JS execution where top level await is not available and scripts execute... well... at a top level. |
@arantius |
With what's available now I "have" to wrap in a function for scope purposes. I think I buy your reasoning for not making it async though. (At the least, adding an async wrapper function in the script itself is trivial.) |
Yeah, it was mostly about the async/await, since that's currently intentionally not allowed in javascript, so enabling it in userscripts seems like a hazard for future changes. I know that the wrapper is currently unavoidable, but I hope that things could be moved back to the top level in the future. |
@arantius Why the down vote? |
See greasemonkey#2275 (comment) And tc39/proposal-async-await#9 This is a bad idea for compatibility. Refs greasemonkey#2275
@arantius commented on 2017. szept. 28. 14:57 CEST:
Try deleting the content of [mozilla profile]\storage\default\ (After backing it up) |
Speaking of UserScript objects, I don't quite understand the design decision for having three UserScript classes. At the moment they have a singular inheritance tree which is a little silly. Further, RemoteUserScript is only used once and for that it's only created in order to grab the id. And RunnableUserScript is never directly used. |
Just for Info ... I am on FF57.0a1 and running legacy addons and GM 3.13 It can be installed manually though.. GM 3.16 still hangs the browser on start-up (I guess it is updating the DB) |
With the WebExtensions thing coming up next year and XUL/XPCOM eventually being deprecated it might be good to do some work to restrict the usage of low-level APIs to the places where it's necessary.
I think the following steps might be helpful:
I think most of the work can be done incrementally.
Once the surface of "old" APIs is reduced to some essential parts we can prod the mozilla guys to provide WebExtensions replacements for them.
The text was updated successfully, but these errors were encountered: