Skip to content
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

Refactor GM_API #2299

Closed
KOLANICH opened this issue Oct 12, 2015 · 6 comments
Closed

Refactor GM_API #2299

KOLANICH opened this issue Oct 12, 2015 · 6 comments
Milestone

Comments

@KOLANICH
Copy link

Hello. I think the GM_API is obsolete and needs refactoring.

  • Instead of implementing own API the HTML5 one should be sanitized and reused.
    • Fetch API should be allowed xdomain requests
    • WebNotifications API should be adopted
    • for a storage we should use WebStorage and IndexedDB, like is done in WebExtensions
  • I suggest to drop prefix and create a GM namespace for the rest of API
  • metadata block should be accessible as GM.metadata
  • resources should be accessible through GM.resources[resourceName], and the type of resource should be taken in account
    • for js files their text should be available, and if it is a module, the result of import should be available as GM.modules[moduleName]
    • for JSON files they should be parsed and the resulting object should be available
    • for audio, video and graphics it should give their objects (Video, Audio and Image)
    • for stylesheets it should give their object, also they should have a method to easily inject them
    • for another mime types we need to have a way to add a custom preprocessor
    • all the resources should be loaded and processed lazily
@arantius
Copy link
Collaborator

The benefit is quite small, and the cost (every script breaks) is high. Not likely. If you want to use web APIs, just @grant none and they work.

@arantius arantius added this to the Pony milestone Oct 13, 2015
@KOLANICH
Copy link
Author

The benefit is quite small, and the cost (every script breaks) is high.

The old scripts will continue working if the old API won't be eliminated, but deprecated with warnings in devtools/firebug console.

If you want to use web APIs, just @grant none and they work.

I need WebAPI have some properties of GM API : context of the script (if I save the data to WebStorage now, it will save the data to the page's webstorage, not the script's one), non-requesting permissions for the sites (but it can request permission for the script (in the request it should be explicitly marked that the permission is requested by the userscript) and the user should be able to revoke every permission individually in any moment of time).

@the8472
Copy link
Contributor

the8472 commented Oct 15, 2015

I need WebAPI have some properties of GM API : context of the script (if I save the data to WebStorage now, it will save the data to the page's webstorage, not the script's one)

Maybe you're thinking too much in chrome-isms where addons run in full-blown web page contexts (background page) where an isolated set of web APIs are available.

This is not the case with GM scripts, things either come from the page itself or from hand-woven code. There is no re-use opportunity to import something from a separate context. Well, technically one could do something like that with hidden pages, but it would be a lot of work.

You might look into the future webextensions stuff instead: https://wiki.mozilla.org/WebExtensions

@KOLANICH
Copy link
Author

Maybe you're thinking too much in chrome-isms where addons run in full-blown web page contexts (background page) where an isolated set of web APIs are available.

No, i just think that
1 having diferrent APIs for the same purpose, if one of them doesn't work in each case harms code portability.
2 GM_API lacks functionality, for example it has no mean to create WebNotification.

You might look into the future webextensions stuff instead: https://wiki.mozilla.org/WebExtension

IMHO webextensions are too heavy to replace userscripts (they require extension to be packed to zip and separated into pieces, where script having access to dom is unpriveleged), userscripts' task is to modify the page, extensions is to modify the browser.

@the8472
Copy link
Contributor

the8472 commented Oct 15, 2015

Well, my point is that

a) you can use the APIs already available within the page context itself
b) you're asking for a manual, standards-compliant re-implementation of some web APIs from scratch or as translation layers around browser-internal features. This is fairly tedious work. Providing restricted subsets that don't even create an illusion of compatibility is much easier to maintain.
c) you expect re-use of web APIs from a different, possibly more privileged, context. which may be possible for some APIs but has considerable security implications.

Am I missing some middle ground here?

@janekptacijarabaci
Copy link
Contributor

Ad WebNotification:
#1194

See also https://bugzilla.mozilla.org/show_bug.cgi?id=862395
Now - I think it's very hard to use...

@arantius arantius modified the milestones: Pony, Bankruptcy Jul 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants