mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Alex Vincent: My two cents on WebExtensions, XPCOM/XUL and other announcements

Mozilla planet - sn, 22/08/2015 - 09:02

(tl;dr:  There’s a lot going on, and I have some sage, if painful, advice for those who think Mozilla is just ruining your ability to do what you do.  But this advice is worth exactly what you pay to read it.  If you don’t care about a deeper discussion, just move to the next article.)

 

The last few weeks on Planet Mozilla have had some interesting moments:  great, good, bad, and ugly.  Honestly, all the recent traffic has impacts on me professionally, both present and future, so I’m going to respond very cautiously here.  Please forgive the piling on – and understand that I’m not entirely opposed to the most controversial piece.

  • WebAssembly.  It just so happens I’m taking an assembly language course now at Chabot College.  So I want to hear more about this.  I don’t think anyone’s going to complain much about faster JavaScript execution… until someone finds a way to break out of the .wasm sandboxing, of course.  I really want to be a part of that.
  • ECMAScript 6th Edition versus the current Web:  I’m looking forward to Christian Heilmann’s revised thoughts on the subject.  On my pet projects, I find the new features of ECMAScript 6 gloriously fun to use, and I hate working with JS that doesn’t fully support it.  (CoffeeScript, are you listening?)
  • WebDriver:  Professionally I have a very high interest in this.  I think three of the companies I’ve worked for, including FileThis (my current employer), could benefit from participating in the development of the WebDriver spec.  I need to get involved in this.
  • Electrolysis:  I think in general it’s a good thing.  Right now when one webpage misbehaves, it can affect the whole Firefox instance that’s running.
  • Scripts as modules:  I love .jsm’s, and I see in relevant bugs that some consensus on ECMAScript 6-based modules is starting to really come together.  Long overdue, but there’s definitely traction, and it’s worth watching.
  • Pocket in Firefox:  I haven’t used it, and I’m not interested.  As for it being a “surprise”:  I’ll come back to that in a moment.
  • Rust and Servo:  Congratulations on Rust reaching 1.0 – that’s a pretty big milestone.  I haven’t had enough time to take a deep look at it.  Ditto Servo.  It must be nice having a team dedicated to researching and developing new ideas like this, without a specific business goal.  I’m envious.  :-)
  • Developer Tools:  My apologies for nagging too much about one particular bug that really hurts us at FileThis, but I do understand there’s a lot of other important work to be done.  If I understood how the devtools protocols worked, I could try to fix the bug myself.  I wish I could have a live video chat with the right people there, or some reference OGG videos, to help out… but videos would quickly become obsolete documentation.
  • WebExtensions, XPCOM and XULUh oh.

First of all, I’m more focused on running custom XUL apps via firefox -app than I am on extensions to base-line Firefox.  I read the announcement about this very, very carefully.  I note that there was no mention of XUL applications being affected, only XUL-based add-ons.  The headline said “Deprecration of XUL, XPCOM…” but the text makes it clear that this applies mostly to add-ons.  So for the moment, I can live with it.

Mozilla’s staff has been sending mixed messages, though.  On the one hand, we’re finally getting a Firefox-based SDK into regular production. (Sorry, guys, I really wish I could have driven that to completion.)  On the other, XUL development itself is considered dead – no new features will be added to the language, as I found to my dismay when a XUL tree bug I’d been interested in was WONTFIX’ed.  Ditto XBL, and possibly XPCOM itself.  In other words, what I’ve specialized in for the last dozen years is becoming obsolete knowledge.

I mean, I get it:  the Web has to evolve, and so do the user-agents (note I didn’t say “browsers”, deliberately) that deliver it to human beings have to evolve too.  It’s a brutal Darwinian process of not just technologies, but ideas:  what works, spreads – and what’s hard for average people (or developers) to work with, dies off.

But here’s the thing:  Mozilla, Google, Microsoft, and Opera all have huge customer bases to serve with their browser products, and their customer bases aren’t necessarily the same as yours or mine (other developers, other businesses).  In one sense we should be grateful that all these ideas are being tried out.  In another, it’s really hard for third-parties like FileThis or TenFourFox or NoScript or Disruptive Innovations, who have much less resources and different business goals, to keep up with that brutally fast Darwinian pace these major companies have set for themselves.  (They say it’s for their customers, and they’re probably right, but we’re coughing on the dust trails they kick up.)  Switching to an “extended support release” branch only gives you a longer stability cycle… for a while, anyway, and then you’re back in catch-up mode.

A browser for the World Wide Web is a complex beast to build and maintain, and growing more so every year.  That’s because in the mad scramble to provide better services for Web end-users, they add new technologies and new ideas rapidly, but they also retire “undesirable” technologies.  Maybe not so rapidly – I do feel sympathy for those who complain about CSS prefixes being abused in the wild, for example – but the core products of these browser providers do eventually move on from what, in their collective opinions, just isn’t worth supporting anymore.

So what do you do if you’re building a third-party product that relies on Mozilla Firefox supporting something that’s fallen out of favor?

Well, obviously, the first thing you do is complain on your weblog that gets syndicated to Planet Mozilla.  That’s what I’m doing, isn’t it?  :-)

Ultimately, though, you have to own the code.  I’m going to speak very carefully here.

In economic terms, we web developers deal with an oligopoly of web browser vendors:  a very small but dominant set of players in the web browsing “market”.  They spend vast resources building, maintaining and supporting their products and largely give them away for free.  In theory the barriers to entry are small, especially for Webkit-based browsers and Gecko:  download the source, customize it, build and deploy.

In practice… maintenance of these products is extremely difficult.  If there’s a bug in NSS or the browser devtools, I’m not the best person to fix it.  But I’m the Mozilla expert where I work, and usually have been.

I think it isn’t a stretch to say that web browsers, because of the sheer number of features needed to satisfy the average end-user, rapidly approach the complexity of a full-blown operating system.  That’s right:  Firefox is your operating system for accessing the Web.  Or Chrome is.  Or Opera, or Safari.  It’s not just HTML, CSS and JavaScript anymore:  it’s audio, video, security, debuggers, automatic updates, add-ons that are mini-programs in their own right, canvases, multithreading, just-in-time compilation, support for mobile devices, animations, et cetera.  Plus the standards, which are also evolving at high frequencies.

My point in all this is as I said above:  we third party developers have to own the code, even code bases far too large for us to properly own anymore.  What do I mean by ownership?  Some would say, “deal with it as best you can”.  Some would say, “Oh yeah? Fork you!”  Someone truly crazy (me) would say, “consider what it would take to build your own.”

I mean that.  Really.  I don’t mean “build your own.”  I mean, “consider what you would require to do this independently of the big browser vendors.”

If that thought – building something that fits your needs and is complex enough to satisfy your audience of web end-users, who are accustomed to what Mozilla Firefox or Google Chrome or Microsoft Edge, etc., provide them already, complete with back-end support infrastructure to make it seamlessly work 99.999% of the time – scares you, then congratulations:  you’re aware of your limited lifespan and time available to spend on such a project.

For what it’s worth, I am considering such an idea.  For the future, when it comes time to build my own company around my own ideas.  That idea scares the heck out of me.  But I’m still thinking about it.

Just like reading this article, when it comes to building your products, you get what you pay for.  Or more accurately, you only own what you’re paying for.  The rest of it… that’s a side effect of the business or industry you’re working in, and you’re not in control of these external factors you subconsciously rely on.

Bottom line:  browser vendors are out to serve their customer bases, which are tens of millions, if not hundreds of millions of people in size.  How much of the code, of the product, that you are complaining about do you truly own?  How much of it do you understand and can support on your own?  The chances are, you’re relying on benevolent dictators in this oligopoly of web browsers.

It’s not a bad thing, except when their interests don’t align with yours as a developer.  Then it’s merely an inconvenience… for you.  How much of an inconvenience?  Only you can determine that.

Then you can write a long diatribe for Planet Mozilla about how much this hurts you.

Categorieën: Mozilla-nl planet

Cameron Kaiser: Mozilla's future footgun add-on policy (or, how MoFo leadership is getting it totally wrong)

Mozilla planet - sn, 22/08/2015 - 06:02
So long, Firefox. It was nice to know you.

First, Electrolysis. As mentioned, we won't support it in TenFourFox; we would need to implement a userland spawn implementation for 10.4 from scratch for starters, and I suspect that the overhead required will end up performing substantially worse on old Macs plus the inevitable OS bugs it will undoubtedly uncover. Currently Mozilla is predicting Electrolysis will reach the release channel by Fx43, which I find incredibly optimistic given predictions for Australis which slipped deadline after deadline, but it's clear Electrolysis' public unveiling in the relative near future is inevitable. Once it becomes no longer possible to launch the browser in single-process mode, likely one or two versions after, that's the end of source parity. My suspicion is that it will actually reach release by Fx45, which is the next ESR anyway, and there should be an emergency fallback to single-process that we can exploit to keep us running at ESR parity for the last time.

To facilitate addons in the new e10s world, Mozilla is effectively announcing that XPCOM/XUL-based addons are now deprecated because of their highly synchronous nature. (Technically, they'll be deprecated six months after Electrolysis goes golden master, and completely unsupported and/or incompatible within six months after that, but as far as I'm concerned announcing a future deprecation is the same as deprecating it now.) This sucks because the use of XPCOM and XUL in the Mozilla Suite and later Firefox and SeaMonkey meant easy cross-platform add-ons that could do powerful things like implementing a completely new protocol within the browser. Although jetpack addons will still work, sort of, any jetpack addon that requires chrome features is subject to this policy also. Mozilla will be enforcing this brave new XUL-free world by refusing to sign addons that rely on XPCOM or XUL in this later timeframe, which dovetails nicely with not allowing unsigned addons starting with Firefox 42. (Parenthetically I don't agree with the mandatory signing policy, and if there is a TenFourFox 45 it will disable this feature. I don't port Gecko code for the walled garden, guys, thanks.)

Calling this a footgun and the future death of Firefox is not merely hyperbole. I suspect, and I suspect Mozilla is ignoring the fact, that many Firefox users use it because of the presence of such powerful addons that just can't be replicated in other browsers. Chrome, for example, doesn't have near the functionality because it doesn't expose it, and its addons are much less useful in general. But Mozilla is not content to merely shoot themselves in the foot here; they've emptied the whole magazine into their leg by making the new add-on world based on the almost completely different WebExtensions API. WebExtensions is Blink-compatible, the engine powering Chrome. That means an author can easily create a much less functional addon that runs not only on Firefox but also on Chrome. Yup, you read that right: soon the only functional difference between Firefox and Chrome at this rate will be the name and the source tree. More to the point, many great classic addons won't work in the new API, and some addons will probably never be made to work with WebExtensions.

Riddle me this, Batman Mozilla leadership: if the addons are the same, the features are the same, the supported standards are the same, the interface is converging and Mozilla's marketshare is shrinking ... why bother using Firefox? I mean, I guess I could start porting SeaMonkey, although this announcement probably kicks the last leg out from under that too, but does Firefox itself, MoCo/MoFo's premier browser brand, serve any useful purpose now? Don't say "because it makes the web free" -- people can just go download and compile WebKit, which is open source, well understood and widely available, and they can even usefully embed it, another opportunity Mozilla leadership shortsightedly threw away. They can fork it like Google did. They can throw a shell around it. Where's the Gecko value now?

Maybe this is a sign that the great Mozilla experiment has finally outlived its usefulness. And frankly there won't be much value in a Gecko-based browser or even a Servo-based one that works exactly the same way as everything else; notice the absolute lack of impact Firefox OS is having on mobile, although I use and prefer Firefox Android personally just because I don't trust Chrome. Maybe that trust will be the only reason to keep using Firefox on any platform, because I certainly can't think of anything else.

Meanwhile, this weekend I'm rewriting TenFourFox wiki documentation on Github ahead of the impending read-only status of Google Code. Since this is true Markdown, I'm using Nathan Hill's SimpleMarkPPC since it works pretty well for simple documents of this type and runs on 10.4. I won't be copying over all the old release notes, but starting with 38.3 all future ones will be on Google Code as well. After that we'll work on the MP3 support to finalize it, and I've got a secret project to share hopefully next week.

Categorieën: Mozilla-nl planet

Mozilla sets plan to dump Firefox add-ons, move to Chrome-like extensions - Ars Technica

Nieuws verzameld via Google - sn, 22/08/2015 - 01:33

Ars Technica

Mozilla sets plan to dump Firefox add-ons, move to Chrome-like extensions
Ars Technica
Back in July, Mozilla disclosed plans to modernize its Firefox browser. Today, the organization made those plans more concrete, with a tentative timeline for introducing long-desired improvements such as the creation of a process per tab—and with it, ...
Mozilla waves add-on model white flagComputerworld
Mozilla drops XUL, changes Firefox APIs; developers unhappyZDNet
Mozilla unveils major changes to Firefox add-on development: Cross-browser ...VentureBeat
Slate Magazine (blog) -Network World -BetaNews
alle 21 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Michael Kaply: My Take on WebExtensions

Mozilla planet - sn, 22/08/2015 - 01:16

Let me start out by saying that I understand the need for something like WebExtensions. A cross browser extension API will be a great thing for the future of browsers. I understand why Mozilla is doing it. What I take issue with is the belief that existing Firefox only add-on developers will jump at the opportunity to use this new API. As far as I’m concerned, the only add-on developers that will benefit from this new API are Chrome developers who will find it much easier to port their extensions to Firefox.

Most Firefox extension developers do it as a hobby. Typically they have an itch about something in Firefox and that write an extension to scratch it. Then they make that extension available to everyone. Over time we all build up a set of extensions that make Firefox behave the way we (and clearly other people) want it to. (Chris Finke is a great example of this.) Every so often something changes in Firefox that breaks one of our extensions. At that point we have to make a decision; it it worth the time and energy to keep this extension going. Sometimes we keep it going, sometimes we give up (hence the ton of dead extensions on AMO). Luckily most of the time Firefox changes don’t break all our extensions, so we usually can keep going. With e10s coming up though, lots of developers have had to make decisions as to whether or not it is worth it to rewrite and some developers have gone through that pain (and it is pain - a lot of pain).

Now developers are being told in the next one to two years they will have to completely rewrite ALL of their add-ons. What are the odds that these hobby add-on developers are going to do that?

Let’s be honest. Availability of APIs isn’t the difficult part of the discussion. Availability of time and energy to even attempt to rewrite all of our add-ons is the problem. And when you add in the fact that Mozilla hasn’t given add-on developers the marketplace we’ve been promised for years (which Chrome has had since day one), you’ll end up with a lot of developers deciding that it’s simply not worth it.

But let's talk availability of APIs. I'll use two of my extensions as examples. Keyword Search accesses the wrappedJSObject of search submissions in order to manipulate the submission. Will there really be an API for that? Or what about the CCK2? Will there really be APIs that allow me to modify the built-in preferences pages including removing pages or controls? Or what about disabling private browsing? Or removing sync? Or removing access to about:config? I doubt it. There are just too many things that extensions do (most of them pretty obscure) to be able to provide an complete API.

I'll watch what goes on and hope that I'm wrong, but I'm not very optimistic.

I will say this, though. It's a great day to be a Chrome developer.

Categorieën: Mozilla-nl planet

Ahmed Nefzaoui: It’s not following chrome, it’s called making the web and the web’s content more compatible

Mozilla planet - fr, 21/08/2015 - 23:50

From DownThemAll:

It is safe to say, that Firefox will not be Firefox anymore as far as extensions go, but instead will become yet another Chrome-clone.

A quote from a blog post I read about Firefox as a friend is going to die so I wanted to quickly echo an opinion I have off the top my head without being too technical:
I personally don’t see how implementing a common set of APIs or a spec that the rest of the browser vendors agreed on and implemented is turning Firefox into a chrome-clone.
WebExtensions’ concept is by far implemented everywhere else except in Firefox. So implementing that here is just as beneficial as when W3C publishes a spec about Flexbox or WebRTC or CSS Logical Properties (wink wink) and chrome implements that, and then Firefox implements it too: that. is. not. following. chrome, it’s called making the web and the web’s content more compatible, and if we are to sit in a corner and implement our own exclusive stuff we will only become another Microsoft of year 2000 with its ActiveX technology where the only way to have the luxury of accessing its features is if developers built their websites mainly for IE.

read more

Categorieën: Mozilla-nl planet

Mozilla: Bitcoin Option Weighed on Online Donations - newsBTC

Nieuws verzameld via Google - fr, 21/08/2015 - 23:06

newsBTC

Mozilla: Bitcoin Option Weighed on Online Donations
newsBTC
According to a study conducted by Mozilla, the addition of a bitcoin option dragged the value of online donations collected through its Firefox browser. Due to popular demand, the company has recently added a bitcoin payment button to its primary ...
Mozilla study shows bitcoin negatively impacts donationsEconoTimes

alle 2 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Air Mozilla: Webdev Beer and Tell: August 2015

Mozilla planet - fr, 21/08/2015 - 23:00

 August 2015 Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...

Categorieën: Mozilla-nl planet

Bill McCloskey: Firefox Add-on Changes

Mozilla planet - fr, 21/08/2015 - 22:03

This post is related to “The Future of Developing Firefox Add-ons” on the add-ons blog. Please read that first for context. A couple of concerns from that post have come up that I would like to address here.

One concern people have is that their favorite add-on is no longer going to be supported, especially add-ons for power users. Some of the ones being mentioned are:

  • Tree Style Tab
  • NoScript
  • Vimperator/Pentadactyl
  • Tab Mix Plus
  • FireGestures
  • Classic theme restorer

We have a lot of ideas about how to make these sorts of extensions work using better APIs than we have now.

  • Opera has a sidebar API. Combined with a way to hide the tab strip, we think this could be used to implement an extension like Tree Style Tab.
  • We’re working with Giorgio Maone, the developer of NoScript, to design the APIs he needs to implement NoScript as a WebExtension.

We’re hoping people will have a lot of other ideas for the extensions that they care about. If you’d like to propose or vote on ideas, please visit webextensions.uservoice.com to express your opinion.

There are also concerns that restricting people to the WebExtensions API will limit innovation: we can make APIs to support the XUL extensions people have already made, but how will we know what other ones we’re missing out on?

It’s likely that we’ll still allow some access to XUL in the future. We want people to be able to experiment with new ideas, and they shouldn’t have to wait for us to design, implement, and finalize a new API. However, we don’t want this to become another feature like require('chrome') in Jetpack, which is used by virtually every add-on. We’re still trying to figure out how to avoid that fate. We know that we need to be more proactive about providing APIs that add-ons need. But is that enough?

Our big fear is that, once we provide a WebExtensions API, there won’t be anything to motivate people to switch over to it. We can try to deprecate access to the parts of XPCOM used to implement the functionality, but often there won’t be a clear mapping between the old and the new APIs.

Again, we’re open to ideas about how to do this. Moving away from XUL will be a long process. We’re announcing all of this early so that we can begin to gather feedback. APIs that are created in a vacuum probably aren’t going to be very useful to people.


Categorieën: Mozilla-nl planet

Mozilla waves add-on model white flag - Computerworld

Nieuws verzameld via Google - fr, 21/08/2015 - 21:37

Computerworld

Mozilla waves add-on model white flag
Computerworld
Other changes Needham detailed today had been discussed earlier by Mozilla, including progress bringing multiple processes to Firefox -- an initiative dubbed "e10s" that will also affect add-ons -- and a new digital-signing requirement for authorized ...
Mozilla drops XUL, changes Firefox APIs; developers unhappyZDNet
Mozilla unveils major changes to Firefox add-on development: Cross-browser ...VentureBeat
Mozilla's self-destruct course continues: major add-on compatibility changes ...Ghacks Technology News
BetaNews -Slate Magazine (blog) -Hot Hardware
alle 17 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Chris Finke: My Future of Developing Firefox Add-ons

Mozilla planet - fr, 21/08/2015 - 20:53

Mozilla announced today that add-ons that depend on XUL, XPCOM, or XBL will be deprecated and subsequently incompatible with future versions of Firefox:

Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback.

In response to this announcement, I’ve taken the step of discontinuing all of my Firefox add-ons. They all depend on XUL or XPCOM, so there’s no sense in developing them for the next year only to see them become non-functional. AutoAuth, Comment Snob, Feed Sidebar, Links Like This, OPML Support, RSS Ticker, and Tab History Redux should be considered unsupported as of now. (If for any reason, you’d like to take over development of any of them, e-mail me.)

While I don’t like Mozilla’s decision (and I don’t think it’s the best thing for the future of Firefox), I understand it; there’s a lot of innovation that could happen in Web browser technology that is stifled because of a decade-old add-on model. I only hope that the strides a lighter-weight Firefox can make will outweigh the loss of the thousands of add-ons that made it as popular as it is today.

Categorieën: Mozilla-nl planet

Air Mozilla: Edgar Chen: TaskCluster Interactive Sessions

Mozilla planet - fr, 21/08/2015 - 20:00

 TaskCluster Interactive Sessions Come learn about TaskCluster Interactive Sessions in a quick presentation by Edgar Chen!

Categorieën: Mozilla-nl planet

Air Mozilla: Webmaker Demos August 21 2015

Mozilla planet - fr, 21/08/2015 - 19:00

Webmaker Demos August 21 2015 Webmaker Demos August 21 2015

Categorieën: Mozilla-nl planet

Mozilla gaat Chrome-extensies in Firefox ondersteunen - Security.nl

Nieuws verzameld via Google - fr, 21/08/2015 - 18:33

Mozilla gaat Chrome-extensies in Firefox ondersteunen
Security.nl
Mozilla heeft grote veranderingen voor de werking van add-ons binnen Firefox aangekondigd, waaronder de mogelijkheid dat straks extensies voor Google Chrome en Opera en mogelijk ook Microsoft Edge in de browser zullen werken. Daarnaast worden er ...
Mozilla wil Chrome-plugins laten draaien op FirefoxTweakers

alle 2 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Support.Mozilla.Org: What’s up with SUMO – 21st August

Mozilla planet - fr, 21/08/2015 - 17:30

Hello, SUMO Nation! How have you been? We skipped last week as I was away from the keyboard, discovering the wonders of the offline world but… we’re back and ready to share news and updates with you.

A warm welcome to those who joined us recently!
If you joined us recently, don’t hesitate – come over and say “hi” in the forums! Contributors of the week
  • Vanja – for his motivation (with a level of over 9000!) to localize the KB for Firefox into Serbian.
We salute you! Monday SUMO Community meetings
  • The previous one was unfortunately cancelled, which means no notes to share – sorry!
  • Remember that you can watch the archived meeting videos on our YouTube channel.
  • The next one is happening on Monday, 24th of August. Join us!
  • If you want to add a discussion topic to upcoming the live meeting agenda:
    • Start a thread in the Community Forums, so that everyone in the community can see what will be discussed and voice their opinion here before Monday (this will make it easier to have an efficient meeting).
    • Please do so as soon as you can before the meeting, so that people have time to read, think, and reply (and also add it to the agenda).
Help needed – thank you! Developers Community Support Forum
  • Reminder: the One and Done SUMO Contributor Support Training is live. Start here!
L10n Firefox (for Desktop, for Android, for iOS)

That’s it for today, looking forward to seeing you all on Monday – take care, take it easy, and safe travels!

Categorieën: Mozilla-nl planet

Mozilla unveils major changes to Firefox add-on development: Cross-browser ... - VentureBeat

Nieuws verzameld via Google - fr, 21/08/2015 - 17:13

The Next Web

Mozilla unveils major changes to Firefox add-on development: Cross-browser ...
VentureBeat
Mozilla today announced major changes are coming to how Firefox add-ons are built. While this is mainly aimed at add-on developers, the end results will trickle down to Firefox users over the next few months and years. Back in the day when Firefox was ...
Firefox will soon be able to run Chrome extensions following major changesThe Next Web

alle 3 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla Addons Blog: The Future of Developing Firefox Add-ons

Mozilla planet - fr, 21/08/2015 - 15:00

Today we are announcing some major upcoming changes to Firefox add-ons. Our add-on ecosystem has evolved through incremental, organic growth over the years, but there are some modernizations to Firefox that require some foundational changes to support:

  • Taking advantage of new technologies like Electrolysis and Servo
  • Protecting users from spyware and adware
  • Shortening the time it takes to review add-ons

To help the add-on development community understand how we will enable these improvements, we are making four related announcements today:

  • We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
  • A safer, faster, multi-process version of Firefox is coming soon with Electrolysis; we need developers to ensure their Firefox add-ons will be compatible with it.
  • To ensure third-party extensions provide customization without sacrificing security, performance or exposing users to malware, we will require all extensions to be validated and signed by Mozilla starting in Firefox 41, which will be released on September 22nd 2015.
  • We have decided on an approximate timeline for the deprecation of XPCOM- and XUL-based add-ons.

For our add-on development community, these changes will bring benefits, like greater cross-browser add-on compatibility, but will also require redevelopment of a number of existing add-ons. We’re making a big investment by expanding the team of engineers, add-on reviewers, and evangelists who work on add-ons and support the community that develops them. They will work with the community to improve and finalize the WebExtensions API, and will help developers of unsupported add-ons make the transition to newer APIs and multi-process support.

We’re announcing all of the changes today to make developers aware of our plans and to give everyone an opportunity to offer feedback. We are committed to doing what we can to make this transition as easy as possible. Together with our Mozilla community, we will create the future of Firefox add-ons.

Introducing the WebExtensions API

For some time we’ve heard from add-on developers that our APIs could be better documented and easier to use. In addition, we’ve noticed that many Firefox add-on developers also maintain a Chrome, Safari, or Opera extension with similar functionality. We would like add-on development to be more like Web development: the same code should run in multiple browsers according to behavior set by standards, with comprehensive documentation available from multiple vendors.

To this end, we are implementing a new, Blink-compatible API in Firefox called WebExtensions. Extension code written for Chrome, Opera, or, possibly in the future, Microsoft Edge will run in Firefox with few changes as a WebExtension. This modern and JavaScript-centric API has a number of advantages, including supporting multi-process browsers by default and mitigating the risk of misbehaving add-ons and malware.

WebExtensions will behave like other Firefox add-ons; they will be signed by Mozilla, and discoverable through addons.mozilla.org (AMO) or through the developer’s website. With this API, extension developers should be able to make the same extension available on Firefox and Chrome with a minimal number of changes to repackage for each platform.

A preview release of WebExtensions is available in Firefox 42, which is currently on Developer Edition, and information on how to start testing WebExtensions is available in the Mozilla wiki. We have started discussions with other browser vendors to begin an effort to standardize at least some of this API, and will continue to post additional information and more details about WebExtensions in the wiki.

Multi-process Firefox and Add-ons

Phase one of our Electrolysis project, which uses a separate operating system process to run Web content, has been moving towards our release channel. Subsequent phases will bring multiple content processes and improved sandboxing capabilities. Using a separate rendering process lays the foundation enabling us to bring significant performance and security improvements to Firefox, but it also breaks some add-ons, especially those that modify content. However, there are a number of mitigations in place to keep add-ons functional:

  • WebExtensions are fully compatible with Electrolysis. As the API matures and Electrolysis is enabled by default, this will be the way to port or develop extensions for Firefox.
  • Add-ons based on the Jetpack SDK will work well as long as they don’t use require(‘chrome’) or some of the low-level APIs to touch objects in the content process.
  • Add-ons that haven’t been upgraded to work with Electrolysis will run in a special compatibility environment that resembles single-process Firefox as much as possible. If an add-on touches content, the access will happen via cross-process object wrappers (CPOWs). However, CPOWs are much slower than the equivalent DOM operations in single-process Firefox, and can affect the user experience negatively. Also, some accesses aren’t supported by the compatibility layer and will throw exceptions.

Starting now, add-on developers need to think about their strategy to work with a multi-process Firefox:

The final release schedule for Electrolysis will be determined over the next several months as we test with more users. We would like developers to understand that, although there is a chance that the Electrolysis release schedule will be delayed or modified in the coming months, they should plan to update their add-ons to meet our current release plan as follows:

  • August 11th (Firefox 42 merges to Developer Edition). Electrolysis has been enabled by default on Developer Edition (it is already the default on Nightly).
  • September 22nd (Firefox 42 merges to Beta). Electrolysis will be available to users as an “opt-in” on the beta channel.
  • November 3rd (Firefox 43 merges to Beta). The earliest release Electrolysis will be enabled by default on Beta. When Electrolysis is enabled by default we will begin blocklisting Electrolysis-incompatible add-ons that cause major performance and/or stability problems.
  • December 15th (Firefox 43 merges to release). The earliest release Electrolysis will be enabled on the release channel, and our current planned release.
  • Six months past enabling Electrolysis on Release. The deprecation of CPOWs and compatibility shims will begin. We will release further scheduling information as appropriate, but developers should be aware that any add-ons that depend on them will stop working within six to twelve months of the general availability of Electrolysis.

The Electrolysis team has posted a list of popular add-ons for compatibility testing at http://arewee10syet.com. In addition to the steps above, developers are encouraged to review the list and follow the instructions to submit information about whether their add-ons are Electrolysis-compatible or not.

Signing

We currently use a blocklisting mechanism to defend against malicious add-ons, but additional measures are needed to better protect our users as some add-on developers have adapted to work around blocklisting. Blocklisting is also reactive: users can be harmed by dangerous add-ons that are installed until they are identified and blocked. Starting in Firefox 42, add-on developers will be required to submit extensions for review and signing by Mozilla prior to deployment, and unsigned add-ons cannot be installed or used with Firefox. You can read more about the rationale for signing in a separate blog post.

We realize that the add-on review process can sometimes be inconvenient for developers. Reviewing is a mostly manual, human process today, and moving an extension from the initial submission to passing a full review that meets our guidelines can be a time-consuming process that can take weeks or months. A major advantage of WebExtensions is that they can be reviewed more quickly. In general, it’s easier to develop a correct WebExtension, and the permissions system makes it easier to recognize malicious add-ons.

Our goal is to increase automation of the review process so that the wait time for reviews of new WebExtensions listed on addons.mozilla.org can be reduced to five days, and that the wait time for updates to existing WebExtensions can be reduced to one to two days. Current wait times for unlisted add-ons submitted for signing are less than three days. We are also expanding the team of paid and volunteer add-on reviewers and continue to make improvements to the automatic validator, both of which will reduce existing review queue wait times for all extensions in the immediate future.

While extension signing will not be enforced until Firefox 42, the code has shipped with Firefox 40, allowing users to see if installed extensions have been validated by Mozilla. Users of Firefox Developer Edition will have noticed that unsigned add-ons were blocked beginning on August 14.

The full schedule for add-on signing is currently as follows:

  • Firefox 40: Users will see a warning in the add-ons manager about unsigned extensions, but all extensions will continue to work.
  • Firefox 41: Unsigned extensions will be disabled by default, and Firefox will have a preference (xpinstall.signatures.required) that allows signature enforcement to be turned off.
  • Firefox 42 and beyond:
    • The Beta and Release versions of Firefox based on 42 and above (Beta 42 will be released at the same time as Firefox 41) will remove the preference that allows unsigned extensions to be installed, and will disable and/or prevent the installation of unsigned extensions.
    • The Nightly and Developer Editions of Firefox based on 42 and above will retain the preference to disable signing enforcement, allowing the development and/or use of unsigned add-ons in those versions. Unbranded versions of Firefox based on releases will also be made available for developers, and are expected to be in place for Firefox 42 for release (and potentially beta).
Deprecation of XUL, XPCOM, and the permissive add-on model

XPCOM and XUL are two of the most fundamental technologies to Firefox. The ability to write much of the browser in JavaScript has been a huge advantage for Mozilla. It also makes Firefox far more customizable than other browsers. However, the add-on model that arose naturally from these technologies is extremely permissive. Add-ons have complete access to Firefox’s internal implementation. This lack of modularity leads to many problems.

A permissive add-on model means that we have limited flexibility in changing the foundations of Firefox. The add-on breakage caused by Electrolysis is an important example of this problem. Technologies like CPOWs help us to work around add-on problems; however, CPOWs have been a huge investment in effort and they are still slow and somewhat unreliable.

Without a fundamental shift to the way Firefox add-ons work, we will be unable to use new technologies like Electrolysis, Servo or browser.html as part of Firefox.

The tight coupling between the browser and its add-ons also creates shorter-term problems for Firefox development. It’s not uncommon for Firefox development to be delayed because of broken add-ons. In the most extreme cases, changes to the formatting of a method in Firefox can trigger problems caused by add-ons that modify our code via regular expressions. Add-ons can also cause Firefox to crash when they use APIs in unexpected ways.

Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback. Add-ons that are built using the new WebExtension API will continue to work. We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.

A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible.

Moving forward

The strategy announced here necessarily involves a lot of trade-offs. Developers who already support Chrome extensions will benefit since they will have one codebase to support instead of two. Developers of Firefox-only add-ons will have to make changes. Those changes may require considerable development effort up-front, but we feel the end result will be worth that effort for both Firefox’s users and developers.

We want to reiterate our commitment to our add-on development community, and will work with you in porting extensions, designing new APIs, and creating innovative new add-ons that make Firefox great.

We will continue to post additional resources in the coming weeks and months to outline each of these changes in more detail, as well as provide support through our traditional channels via the Mozilla Developer Network, IRC (in #extdev), and the extension developer group.

Categorieën: Mozilla-nl planet

Mozilla Study Shows Bitcoin has Negative Impact on Donations - Inside Bitcoins

Nieuws verzameld via Google - fr, 21/08/2015 - 05:27

Inside Bitcoins

Mozilla Study Shows Bitcoin has Negative Impact on Donations
Inside Bitcoins
Mozilla, the team behind the well-known Firefox browser, recently announced that it was including Bitcoin as one of the many ways people can choose to support the organization. Mozilla is a non-profit organization dedicated to promoting openness, ...

en meer »
Categorieën: Mozilla-nl planet

Mozilla Study Shows Bitcoin has Negative Impact on Donations - Bitcoinist.net

Nieuws verzameld via Google - to, 20/08/2015 - 21:15

Bitcoinist.net

Mozilla Study Shows Bitcoin has Negative Impact on Donations
Bitcoinist.net
Mozilla, the team behind the well-known Firefox browser, recently announced that it was including Bitcoin as one of the many ways people can choose to support the organization. Mozilla is a non-profit organization dedicated to promoting openness, ...

Categorieën: Mozilla-nl planet

Nathan Froyd: explicit is better than implicit: c++ implicitly defined member functions

Mozilla planet - to, 20/08/2015 - 18:14

In the tradition of The Zen of Python, I’ve been thinking about pushing for explicit declarations of otherwise implicitly-defined member functions in C++, both in code that I write and in code that I review:

// Instances of this class should not be copied. MyClass(const MyClass&) = delete; MyClass& operator=(const MyClass&) = delete; // We are OK with the default semantics. OtherClass(const OtherClass&) = default; OtherClass& operator=(const OtherClass&) = default; OtherClass(OtherClass&&) = default; OtherClass& operator=(OtherClass&&) = default;

[Background: C++ specifies several member functions that the compiler will implicitly define for you in any class: the default constructor, the copy/move constructor(s), and the copy/move assignment operator(s). I say “implicitly define”, as though that always happens, but there are a number of constraints on when the compiler will do this. For the purposes of the discussion below, I’ll ignore the default constructor bit and focus on the copy/move constructor and assignment operator. (I will also happily ignore all the different variants thereof that can occur, e.g. when the compiler defines MyClass(MyClass&) for you.) I think the arguments apply equally well to the default constructor case, but most classes I deal with tend to either declare their own default constructor or have several user-defined constructors anyway, which prohibit the compiler from implicitly declaring the default constructor.]

I think the argument for = delete is more obvious and less controversial, so I’ll start there.  = delete‘ing functions you don’t want used is part of the API contract of the class.  Functions that shouldn’t be used shouldn’t be exposed to the user, and = delete ensures that the compiler won’t implicitly define part of your API surface (and users thereby unknowingly violate API guarantees).  The copy constructor/assignment operator are the obvious candidates for = delete, but using = delete for the move constructor/assignment operator makes sense in some cases (e.g. RAII classes). Using = delete gives you pleasant compiler error messages, and it’s clearer than:

private: MyClass(const MyClass&); MyClass& operator=(const MyClass&);

If you’re lucky, there might be a comment to the effect of // Deliberately not defined.  I know which code I’d prefer to read. (Using = delete also ensures you don’t accidentally use the not-defined members inside the class itself, then spend a while waiting for the linker errors to tell you about your screw-up.)

= default appears to be a little harder to argue for.  “Experienced” programmers always know which functions are provided by the compiler, right?

Understanding whether the compiler implicitly defines something requires looking at the entire class definition (including superclasses) and running a non-trivial decision algorithm. I sure don’t want each reader of the code to do that for two or four different member functions (times superclasses, too), all of which are reasonably important in understanding how a class is intended to be used.

Explicitly declaring what you intend can also avoid performance pitfalls. In reading through the C++ specification to understand when things were implicitly declared, I discovered that the same functions can also be implicitly deleted, including this great note: “When the move constructor is not implicitly declared or explicitly supplied, expressions that otherwise would have invoked the move constructor may instead invoke a copy constructor.” So, if the move constructor was implicitly declared at some point, but then was implicitly deleted through some change, expressions that were previously efficient due to moving would become somewhat less so due to copying. Isn’t C++ great?

Being explicit also avoids the possibility of meaning to define something, but getting tripped up by the finer points of the language:

template<typename T> class MyClass { public: // This does not define a copy constructor for MyClass<T>. template<typename U> MyClass(const MyClass<U>& aOther) : ... { ... } ... };

Comments could serve to notify the reader that we’re OK with the default definition, but if I could choose between encoding something in a place solely intended for humans, or a place both humans and the compiler will understand, I know which one I’d pick.

Categorieën: Mozilla-nl planet

Air Mozilla: Web QA Weekly Meeting

Mozilla planet - to, 20/08/2015 - 18:00

Web QA Weekly Meeting This is our weekly gathering of Mozilla'a Web QA team filled with discussion on our current and future projects, ideas, demos, and fun facts.

Categorieën: Mozilla-nl planet

Pages