Open laurentj opened 6 years ago
Thanks A LOT for the great efforts of you and other contributors!
Thank you :-)
but I really hope they solve the WebExtensions transition issue and extension devs unhappy about certain features, but probably this doesn't affect SlimerJS
Since XUL extensions are now forbidden, they started to study to remove some XUL features (like XBL), and so it may affect SlimerJS in the long term. We'll see.
Some Mozillians are aware about SlimerJS, and I think it is even used (or was used?) to test some Mozilla projects. About merging SlimerJS in their codebase, I don't think it will happen, because, first, my code doesn't follow their coding guide line, and second because the PhantomJS/SlimerJS API is very old school. A modern API should use more promises and other asynchronous stuff than the current API.
Since XUL extensions are now forbidden, they started to study to remove some XUL features (like XBL), and so it may affect SlimerJS in the long term. We'll see.
Indeed, we're in the process of removing XBL (per http://arewexblstill.com/), and we're planning to replace other XUL features, with the eventual goal of replacing all of XUL in Firefox.
Even if we weren't doing that, it's highly likely that the Firefox APIs that SlimerJS uses will change, and that's probably a good thing, given that the XULRunner API is a complex and clunky way to enable apps like SlimerJS to reuse Firefox's web rendering engine.
In any case, I'd still like to support consumers like SlimerJS, if possible, after we replace XUL features in Firefox. Do you have any thoughts on the kind of Firefox API you'd like to be able to use to build SlimerJS?
Some Mozillians are aware about SlimerJS, and I think it is even used (or was used?) to test some Mozilla projects. About merging SlimerJS in their codebase, I don't think it will happen, because, first, my code doesn't follow their coding guide line, and second because the PhantomJS/SlimerJS API is very old school. A modern API should use more promises and other asynchronous stuff than the current API.
It's hard to land features in Firefox, especially developer-centric ones, as Firefox features generally need to be relevant to large numbers of users, and developer features tend to be relevant to a small subset. Of course, Firefox does include the the Marionette server, but that's a low-level API, and presumably most developers use Marionette via GeckoDriver, which they need to install separately.
Google Chrome similarly supports scriptable browsing via the low-level Chrome DevTools/Debugging Protocol (CDP), while most developers use separate high-level tools like Puppeteer. That seems like a reasonable model, so I suspect that it's the easiest path for tools like SlimerJS. (Of course that doesn't mean it's an easy path, and we could certainly make it easier!)
Out of curiosity (although I know it's not directly relevant to this issue), do you have any plans to modernize SlimerJS's API, perhaps along the lines of the Puppeteer API?
Our implementation of WebDriver, Ghostdriver, is old, not really maintened and it seems a bit buggy. Moreover, Firefox has now an implementation of webdriver with the headless mode.
To avoid to maintain the integration of the library Ghostdriver, we can remove it. We will also remove all command line options about webdriver, except if we can call the webdriver lib of Firefox.