search

mozilla / qbrt

CLI to a Gecko desktop app runtime
Apache License 2.0
390 stars 31 forks source link

Webextension API support #139

Open Happy-Ferret opened 6 years ago

Happy-Ferret commented 6 years ago

Just an idea, but it would be great if there was a way to support Webextension APIs. Not necessarily browser ones but ones specifically written for qbrt.

With that facility in place the approach to extending qbrt would be easier and more streamlined.

Unfortunately, I have little to no idea how this may be achieved from a technical perspective.

In 2015 Wladimir Palant wrote a tutorial on how to import and use Webextension APIs from within an XUL application. Since then, however, a lot has changed and most of the interfaces mentioned in that article have been moved, removed or otherwise deprecated since then.

mykmelez commented 6 years ago

Extension.jsm is still in mozilla-central, and it's in a toolkit/components/extensions/ directory, which theoretically can be used by other XUL applications (although toolkit/ code may be Firefox-specific in practice, even if it's generic in theory). So this might be possible using that code.

Nevertheless, I wonder if there are other solutions, depending on how you'd like to extend qbrt. What are your use cases for extending the tool?

Happy-Ferret commented 6 years ago

Well. I'm still working on my little hobby OS, so my only use-case is having a solid run-time for apps, really. Since WebExtensions include schema validation and since Chrome OS uses similar APIs for their app runtime, I think they would be the way forward for qbrt/any modern app runtime in general.

Happy-Ferret commented 6 years ago

As for Extension.jsm.

The implementation has seen quite a bit of change.

It appears generateAPIs and ExtensionPage no longer exist within its scope.

Happy-Ferret commented 6 years ago

Another idea that may, at least in theory, be easier to implement:

Implement APIs in a fashion similar to the way full-screen is implemented, using prefs (i e full-screen-api.enabled).

Then we can just add a permissions array to manifest.json, enabling the selected keys at app startup.

mykmelez commented 6 years ago

Hmm, I'm not sure I understand the use case for a permissions section in the application manifest. Applications that use qbrt currently have full access to the runtime's own APIs (and thus all the permissions of a desktop app), so it isn't clear how a permissions section would enable specific APIs for them.

I suppose I could imagine an application (such as a browser) allowing the installation of third-party extensions to which it exposes a limited set of APIs. In that case, however, it seems more straightforward to reuse the existing WebExtensions feature of the runtime.

Happy-Ferret commented 6 years ago

Yea. I guess I was thinking more along the lines of a Chrome App/Webextension-esque architecture. i e only exposing bits an app has permissions for. Not sure why that design isn't more popular (additional testing requirements aside).

mykmelez commented 6 years ago

Yea. I guess I was thinking more along the lines of a Chrome App/Webextension-esque architecture. i e only exposing bits an app has permissions for. Not sure why that design isn't more popular (additional testing requirements aside).

Ah, I see. This makes sense as a security mode of the runtime that is somewhere between the web mode (a limited set of standard permissions) and the desktop mode (all the permissions of a desktop app), the latter of which is the default (ok, only) mode of qbrt currently. I could imagine this either as part of qbrt or as part of a separate project that reuses qbrt and provides a XUL app template with these permissions.

Happy-Ferret commented 6 years ago

Yea. Sounds sensible. I'm already experimenting with it. A runtime that takes some cues from qbrt (I learned a lot about sandbox, security principals and protocols from it), nw.js (I actually think about making main a field that takes a path to an html file and then the current functionality would move into main-js. Will just have to consider the side effects, when it comes to certain globals), electron and yode (the latter I found out about today. It's a cool project if you haven't checked it out yet. Especially the graphical features).

For the CLI I think about using Go, since I also have a vision of a small node-esque runtime and because I'm generally quite fond of that language.