29 ms·

It used to be that Firefox extensions could have the same capabilities as Firefox itself. It seems that this move is relegating them to second-class status. He

It used to be that Firefox extensions could have the same capabilities as Firefox itself. It seems that this move is relegating them to second-class status. Here's a list of things missing from the Chrome/WebExtensions API that our extension currently does: - Customization of the browser UI beyond a single, simple toolbar button or a few other specially implemented widgets. - Reading/writing arbitrary files to the file system. There is chrome.fileSystem, but it's limited in what it allows, and it isn't available to extensions, only Chrome apps. - Interfacing with other applications. This typically requires using platform-native APIs, which was possible with js-ctypes (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes). Chrome has a socket API, but it's not really the best way to do IPC, and it isn't available to extensions anyway. - Some kind of SQL database. Firefox has an SQLite interface (MozStorage), but it's not part of the WebExtensions API. Chrome actually has WebSQL, but Firefox never implemented that (with good reason, IMO; it's tied to a SQLite and shouldn't be used on the web). I guess you'd better like IndexedDB. - Native-looking UI widgets. This is certainly possible to do in HTML, but it's not always so easy. For example, we have yet to find any reasonable HTML-based replacement for our tree view that's both visually appealing on all platforms and reasonably performant with thousands of items. (If you have suggestions, let us know!) I guess Mozilla's viewpoint is that, since everyone is already supporting Chrome, they don't need these things. However, for our extension, the difference between the Chrome and Firefox implementations is that the Chrome implementation needs to talk to a separate app, while the Firefox implementation can do everything itself. Firefox used to give us a very powerful toolkit for writing apps, the same toolkit they used to create Firefox. Now it looks like all we'll have is a toolkit for writing simple browser extensions. I think many people use Firefox because they can customize it the way they want to. Soon you won't be able to customize Firefox any more than Chrome. Maybe Mozilla is banking on Servo being so fast/secure that people will use it over Chrome even when all the other advantages are gone.

deleted 11y ago
[deleted]
spaceribs 11y ago
The customization element was nice, but I feel like most of these issues will be addressed by future developments. With everyone using close to the same API, we have to move backward a bit, but one browser implementing a feature like file access means developers going to other browsers and saying "Why can't I do the same thing from the other guy?" While this somewhat exists already, it will be much louder if they aren't entirely different plugin architectures and used as a developer excuse.
- simonster 11y ago
  Firefox implemented file system access for extensions long before Chrome existed. They're just taking it away now. If Mozilla wanted to go the standardized API route, they could have done that initially instead of introducing the Add-on SDK (Jetpack). IMO, that would have made more sense. And if they wanted to, Mozilla could still allow XUL/XPCOM add-ons to coexist with WebExtensions add-ons until Firefox itself stops using XUL/XPCOM (which will most likely happen when Servo is ready for prime time). And by that time, maybe they could standardize js-ctypes as part of WebExtensions, which would address the middle 3 issues on my list.
pdkl95 11y ago
> relegating them to second-class status That's the goal. "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. The security sandbox will always have significant restrictions, by definition. If you don't like this, write a native app instead. > Reading/writing arbitrary files to the file system. Are you trying to open up a massive security hole? Filesystem access is banned on purpose. Writing an extension in a way that guarantees arbitrary filesystem access cannot be exploited through some complex interaction with the rest of the browser environment is probably impossible (see: the Halting Problem). It would certainly fail in practice. Seriously, stop treating the browser as the OS+desktop. If your platform doesn't offer any true "native" access that has the features you want, then take that up with the platform's vendor.
- wtbob 11y ago
  > "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. You're right that it's insanity to allow a web app to spoof the native UI. But extensions aren't web apps: they are native (or should be). Extensions are extensions to the browser: they're what can actually provide secure crypto and privacy.
- the8472 11y ago
  > Are you trying to open up a massive security hole? Firefox extensions run in a privileged context. They essentially are not really different from components of firefox itself. Firefox components can obviously access the filesystem. So can extensions. An extension in itself is not any more a security hole than firefox itself. > Seriously, stop treating the browser as the OS+desktop. While I agree with you there, what's needed to get to that point would be browsers actually talking to the native environment more. Pipes, sockets, filesystem access (chroot-style) even limited process launch capabilities. If web or extension APIs allowed that it would be far easier to integrate with native instead of having to build it straight into the browser. But that just addresses the "app" kind of extension. Other extensions instead customize the web browsing experience. For example if you have a file form and want to do automation (filling in the right files?) then you already need access to the file system. This has nothing to do with native apps and yet needs access to native resources.
nwah1 11y ago
As I stated in a comment above, this is why they're working on browser.html so vigorously https://github.com/mozilla/browser.html https://github.com/mozilla/browser.html Web standards are fully capable of rendering entire user interfaces now. GUI toolkits are just needless dependencies for web rendering engines.

deleted 11y ago

[deleted]

spaceribs 11y ago

The customization element was nice, but I feel like most of these issues will be addressed by future developments. With everyone using close to the same API, we have to move backward a bit, but one browser implementing a feature like file access means developers going to other browsers and saying "Why can't I do the same thing from the other guy?" While this somewhat exists already, it will be much louder if they aren't entirely different plugin architectures and used as a developer excuse.

simonster 11y ago
Firefox implemented file system access for extensions long before Chrome existed. They're just taking it away now. If Mozilla wanted to go the standardized API route, they could have done that initially instead of introducing the Add-on SDK (Jetpack). IMO, that would have made more sense. And if they wanted to, Mozilla could still allow XUL/XPCOM add-ons to coexist with WebExtensions add-ons until Firefox itself stops using XUL/XPCOM (which will most likely happen when Servo is ready for prime time). And by that time, maybe they could standardize js-ctypes as part of WebExtensions, which would address the middle 3 issues on my list.

pdkl95 11y ago

> relegating them to second-class status That's the goal. "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. The security sandbox will always have significant restrictions, by definition. If you don't like this, write a native app instead. > Reading/writing arbitrary files to the file system. Are you trying to open up a massive security hole? Filesystem access is banned on purpose. Writing an extension in a way that guarantees arbitrary filesystem access cannot be exploited through some complex interaction with the rest of the browser environment is probably impossible (see: the Halting Problem). It would certainly fail in practice. Seriously, stop treating the browser as the OS+desktop. If your platform doesn't offer any true "native" access that has the features you want, then take that up with the platform's vendor.

wtbob 11y ago
> "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. You're right that it's insanity to allow a web app to spoof the native UI. But extensions aren't web apps: they are native (or should be). Extensions are extensions to the browser: they're what can actually provide secure crypto and privacy.
the8472 11y ago
> Are you trying to open up a massive security hole? Firefox extensions run in a privileged context. They essentially are not really different from components of firefox itself. Firefox components can obviously access the filesystem. So can extensions. An extension in itself is not any more a security hole than firefox itself. > Seriously, stop treating the browser as the OS+desktop. While I agree with you there, what's needed to get to that point would be browsers actually talking to the native environment more. Pipes, sockets, filesystem access (chroot-style) even limited process launch capabilities. If web or extension APIs allowed that it would be far easier to integrate with native instead of having to build it straight into the browser. But that just addresses the "app" kind of extension. Other extensions instead customize the web browsing experience. For example if you have a file form and want to do automation (filling in the right files?) then you already need access to the file system. This has nothing to do with native apps and yet needs access to native resources.

nwah1 11y ago

As I stated in a comment above, this is why they're working on browser.html so vigorously https://github.com/mozilla/browser.html https://github.com/mozilla/browser.html Web standards are fully capable of rendering entire user interfaces now. GUI toolkits are just needless dependencies for web rendering engines.