Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Enterprise users last remaining users... (Score 1) 236

I mainly use extensions to do things to the UI that Mozilla don't think I should be able to do (things like "look and act like any other Windows program"...)

obviously they're not going to maintain an API for those.

How do you know this? Have you submitted any requests or proposed an API design?

Comment Re:Enterprise users last remaining users... (Score 1) 236

I guess at this point I should mention that I am a Mozilla employee.

"WebExtensions" are just glorified Greasemonkey scripts -- with a much larger API than GM scripts have available, but you're still playing around in a sandbox. These are mostly interesting for extending how a given website works, hence my comparison to GM.

With WebExtensions, you're not playing in a sandbox, you're playing with abstractions. Exposing internal XPCOM objects to extensions offered no abstraction - extensions were messing directly with browser internals, which was severely hampering our ability to improve fundamentals of the Gecko engine. We want to be able to make significant changes to Gecko without constantly worrying about breaking extensions. An abstraction layer is the way to do that.

"Extensions" have access to the browser chrome, and can thus add or change any functionality in the browser. This is the bit that is euphemistically (and wrongly) described as "deprecation of XUL and XPCOM" (even though XUL and XPCOM aren't actually a requirement for this type of extension...).

You're right, XUL and XPCOM are not required for that type of extension. WebExtension APIs are going to allow for modification of browser chrome. Mozilla is working with extension developers to make sure that the functionality that they require will be exposed to them in a way that is future-proof. We fully intend to allow for extensions such as tree-style tabs and Vimperator.

If you have useful ideas for new extension APIs, I encourage you to offer suggestions instead of FUD.

WebExtensions overview
WebExtensions roadmap
WebExtensions experiments

Comment Re:Enterprise users last remaining users... (Score 1) 236

and it's just as extensible as ever

They're working hard on this. Their announced plan is to drop support for extensions soon (to replace them with, approximately, Greasemonkey scripts, which can't do anything like the range of things extensions can).

This is blatantly false. Either back up your statements with citations (which you can't) or stop spreading FUD.

Comment Re: Chromecast-like? (Score 3, Informative) 89

Because those other browsers didn't have a huge extension ecosystem to contend with. Are you going to go and tell every extension author, big or small, new or old, maintained or not, that they need to rewrite their add on to work with electrolysis? No, you have to make e10s seamlessly compatible with the legacy, single-threaded APIs that those extensions use. That's hard.

Comment They didn't use C, but they modified C# (Score 1) 406

From the summary on their page it's quite apparent that they had to create special tools that gave C# direct access to pointers, CPU registers and even code written in straight assembly. All this business about "so there, a kernel CAN be written without C" is nothing more than flamebait; they've created a toolchain that allows them to break out of the pure managed environment and add low-level, C-like features to C#.

Slashdot Top Deals

Asynchronous inputs are at the root of our race problems. -- D. Winker and F. Prosser