Mozilla Nederland LogoDe Nederlandse

Chrome Extensions Coming to Firefox as Mozilla Reveals Security Changes - NDTV

Nieuws verzameld via Google - mo, 24/08/2015 - 11:18


Chrome Extensions Coming to Firefox as Mozilla Reveals Security Changes
Mozilla has announced big changes are coming to the Firefox browser. While the tweaks are designed to make the Web browser more secure and stable, it also makes it possible to run Chrome and Opera extensions in Firefox. Also support for traditional ...
Mozilla Wants All Your Favorite Chrome Extensions for FirefoxSlate Magazine (blog)
Mozilla Says Buh-Bye To Firefox Add-Ons In Favor Of Chrome Extensions: Why ...Tech Times
Mozilla introduces new feature that allows add-ons of Google's ChromeThe Market Business
Ars Technica -The Hoops News
alle 109 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla maakt de browser privé voor onlinediensten -

Nieuws verzameld via Google - mo, 24/08/2015 - 10:56

Mozilla maakt de browser privé voor onlinediensten
Mozilla Firefox De meeste browsers hebben inmiddels een privémodus die ervoor zorgt dat er geen geschiedenis van bezochte sites wordt bijgehouden, zegt TechCrunch. Het voorkomt echter niet dat onlinediensten de gebruiker kunnen volgen, bijvoorbeeld ...

Categorieën: Mozilla-nl planet

Mozilla、「Firefox」のアドオンを「Google Chrome」互換の“WebExtensions”へ - 窓の杜

Nieuws verzameld via Google - mo, 24/08/2015 - 09:35


Mozilla、「Firefox」のアドオンを「Google Chrome」互換の“WebExtensions”へ
Mozillaは21日、公式ブログ“Mozilla Add-ons Blog”で、「Firefox」のアドオンを新しいブラウザー拡張API“WebExtensions”ベースのものへ置き換えていく方針を明らかにした。この施策はマルチプロセス化とサンドボックス機能をはじめとする「Firefox」の近代化のために必要な ...
モジラ、アドオン開発の変更計画を発表--XUL/XPCOMを非推奨へZDNet Japan

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

Emily Dunham: X240 trackpoint speed

Mozilla planet - mo, 24/08/2015 - 09:00
X240 trackpoint speed

The screen on my X1 Carbon gave out after a couple months, and my loaner laptop in the meantime is an X240.

The worst thing about this laptop is how slowly the trackpoint moves with a default Ubuntu installation. However, it’s fixable:

cat /sys/devices/platform/i8042/serio1/serio2/speed cat /sys/devices/platform/i8042/serio1/serio2/sensitivity

Note the starting values in case anything goes wrong, then fiddle around:

echo 255 | sudo tee /sys/devices/platform/i8042/serio1/serio2/sensitivity echo 255 | sudo tee /sys/devices/platform/i8042/serio1/serio2/speed

Some binary search themed prodding and a lot of tee: /sys/devices/platform/i8042/serio1/serio2/sensitivity: Numerical result out of range has confirmed that both files accept values between 0-255. Interestingly, setting them to 0 does not seem to disable the trackpoint completely.

If you’re wondering why the configuration settings look like ordinary files but choke on values bigger or smaller than a short, go read about sysfs.

Categorieën: Mozilla-nl planet

Mozilla Firefox verärgert Entwickler - Vorhandene Erweiterungen funktionieren ... - GameStar

Nieuws verzameld via Google - mo, 24/08/2015 - 07:42


Mozilla Firefox verärgert Entwickler - Vorhandene Erweiterungen funktionieren ...
Im Gegensatz zu Chrome von Google macht Firefox von Mozilla den Nutzern und Entwicklern bislang keine großen Vorschriften, welche Erweiterungen für den Browser möglich sind. Für viele Nutzer dürfte das einer der Gründe sein, warum sie bislang nicht ...
Firefox: Mozilla präsentiert neues System für Add-onsPC Games Hardware
Firefox: Mozilla ändert die Regeln zur Add-on-EntwicklungComputerBase
Mozilla plant Kompatibilitätsbruch bei Firefox-ErweiterungenPro-Linux
WinFuture -Futurezone
alle 10 nieuwsartikelen »
Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 93

Mozilla planet - mo, 24/08/2015 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us an email! Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

From the Blogosphere New Releases & Project Updates What's cooking on nightly?

86 pull requests were merged in the last week.

New Contributors
  • jotomicron
  • Marc-Antoine Perennou
  • Martin Wernstål
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Upcoming Events

If you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.

fn work(on: RustProject) -> Money

No jobs listed for this week. Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

"unsafe is as viral and pernicious as pop music, though obviously not as dangerous."Daniel Keep at TRPLF.

Thanks to llogiq for the tip. Submit your quotes for next week!.

Categorieën: Mozilla-nl planet

Wladimir Palant: Missing a rationale for WebExtensions

Mozilla planet - mo, 24/08/2015 - 00:40

Mozilla’s announcement to deprecate XUL/XPCOM-based add-ons raises many questions. Seeing the reactions, it seems that most people are very confused now. I mean, I see where this is coming from. XUL and XPCOM have become a burden, they come at a huge memory/performance/maintenance cost, impose significant limitations on browser development and create the danger that a badly written extension breaks everything. Whatever comes to replace them certainly won’t give add-on developers the same flexibility however, especially when it comes to extending the user interface. This is sad but I guess that it has to be done.

What confuses me immensely however is WebExtensions which are touted as the big new thing. My experience with Chrome APIs isn’t all too positive, the possibilities here are very limited and there is a fair number of inconsistencies. The documentation isn’t great either, there are often undocumented details that you only hit when trying things out. This isn’t very surprising of course: the API has grown along with Chrome itself, and many of the newer concepts simply didn’t exist back when the first interfaces were defined. Even worse: Opera, despite using the same engine, occasionally implements the same APIs differently.

So my main question is: does Mozilla really plan to keep bug-for-bug compatibility with Chrome APIs all for the goal of cross-browser extensions? That’s an endless catch-up game that benefits Chrome way more than it helps Firefox. And what is this cross-browser story still worth once Mozilla starts adding their own interfaces which are incompatible to Chrome? Don’t forget that Chrome can add new APIs as well, maybe even for the same purpose as Mozilla but with a different interface.

Further, I don’t see any advantages of WebExtensions over the Add-on SDK. I wasn’t a fan of the SDK back when it was introduced but I must say that it really matured over the years. It took much time for the SDK to become a modern, consistent and flexible framework that it is right now. Mozilla invested significant effort into it and it paid off. What’s even more important, there is now sufficient documentation and examples for it on the web. Why throw all this away for a completely different framework? Note that the announcement says that most SDK-based extension will continue to work in the new world but according to the comments below it won’t be a development focus any more — from my experience, that’s an euphemism for “deprecated.”

As mentioned above, I don’t see how theoretical cross-browser compatibility is going to benefit Firefox. Maybe the advantage lies in the permission model? But Chrome’s permission model is broken — most extensions need APIs that could potentially allow them to access user’s browsing history. While most extensions won’t actually do anything like that, privacy violations are a very common issue with Chrome extensions. The privilege prompt doesn’t help users recognize whether there is a problem, it merely trains users to ignore privacy-related warnings. Oh, and it shifts the blame from Google to the user — the user has been warned, right?

In my opinion, this permission model cannot be seen as a substitute for reviews. Nor will it make reviews easier than for SDK-based extensions: it’s pretty easy to extract the list of SDK modules uses by an extension. That gives one pretty much the same information as a list of permissions, albeit without requiring an explicit list.

There must be a reason why Mozilla chose to develop WebExtension rather than focus that energy on improving the Add-on SDK. Sadly, I haven’t seen it mentioned anywhere so far.

Categorieën: Mozilla-nl planet

Mozilla Wants All Your Favorite Chrome Extensions for Firefox - Slate Magazine (blog)

Nieuws verzameld via Google - snein, 23/08/2015 - 19:59

Slate Magazine (blog)

Mozilla Wants All Your Favorite Chrome Extensions for Firefox
Slate Magazine (blog)
Whether you want to see even more cats on the Internet or you think Alphabet should just go back to calling itself Google, there's a Chrome extension to help. You can even get every website to refer to millennials by their proper name. Though ...
Mozilla's Radical Firefox Changes And How They'll Affect Your Add-OnsGizmodo Australia
Mozilla sets plan to dump Firefox add-ons, move to Chrome-like extensionsArs Technica
Reactions to Mozilla's announcement about upcoming Firefox add-on changesGhacks Technology News
Computerworld -Tech Times
alle 91 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla, Chrome eklentilerini Firefox'a getirmeye hazırlanıyor - Webrazzi

Nieuws verzameld via Google - snein, 23/08/2015 - 13:50


Mozilla, Chrome eklentilerini Firefox'a getirmeye hazırlanıyor
Yeni WebExtensions API ile geliştirilen eklentiler küçük farklılıklarla Chrome, Opera, Firefox ve Microsoft Edge üzerinde kullanılabilecek ve Mozilla bu yenilikle belki de Chrome'a daha fazla kullanıcı kaptırmaktan kurtulacak. Zira Opera tarafında ...
Mozilla Firefox Artık Chrome Eklentileri KullanabilecekTamindir
Firefox, Google Chrome Eklentilerini KullanabilecekWebtekno
Mozilla Artık Chrome Uygulamalarınıda DestekleyecekForumDonanim

alle 5 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla's Radical Firefox Changes And How They'll Affect Your Add-Ons - Gizmodo Australia

Nieuws verzameld via Google - snein, 23/08/2015 - 04:09

Gizmodo Australia

Mozilla's Radical Firefox Changes And How They'll Affect Your Add-Ons
Gizmodo Australia
As the company's Kev Needham outlines in a blog post on Mozilla's Add-ons Blog, there are some significant incoming changes being made to the browser to “take advantage of new technologies” and better defend users against malicious software.
Mozilla Says Buh-Bye To Firefox Add-Ons In Favor Of Chrome Extensions: Why ...Tech Times
Mozilla sets plan to dump Firefox add-ons, move to Chrome-like extensionsArs Technica UK
Why in the world is Mozilla adding Chrome extensions to Firefox?Morning Ticker
Pioneer News -Computerworld
alle 83 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla makes move to add Chrome extension to Firefox, causing a few sighs for ... - The Standard Daily

Nieuws verzameld via Google - sn, 22/08/2015 - 20:04

Mozilla makes move to add Chrome extension to Firefox, causing a few sighs for ...
The Standard Daily
Those in charge of making decision from Mozilla, who are the mother company of Firefox, which is a very popular web browser have decided to now update their extension and add-on infrastructure which will bring a whole lot of new features to their ...

Google Nieuws
Categorieën: Mozilla-nl planet

Leaked Mozilla Tax Return Causes Furore - iProgrammer

Nieuws verzameld via Google - sn, 22/08/2015 - 16:46


Leaked Mozilla Tax Return Causes Furore
The Mozilla Foundation is a non-profit organization that is exempt from income tax. Even so it has to complete an annual return for the United States Internal Revenue Status. The completed form for 2013 was posted to Hacker News, leading to heated debate.

Categorieën: Mozilla-nl planet

Mozilla Says Buh-Bye To Firefox Add-Ons In Favor Of Chrome Extensions: Why ... - Tech Times

Nieuws verzameld via Google - sn, 22/08/2015 - 15:27

Tech Times

Mozilla Says Buh-Bye To Firefox Add-Ons In Favor Of Chrome Extensions: Why ...
Tech Times
Beginning with the release of Firefox 42, the extensions created by developers will also be first reviewed and then signed by Mozilla before they are deployed. Mozilla, however, hopes that the adoption of the WebExtensions API will lead to faster ...
Mozilla sets plan to dump Firefox add-ons, move to Chrome-like extensionsArs Technica
Mozilla waves add-on model white flagComputerworld
Mozilla's latest Firefox plans may not make developers and users happyNetwork World
Slate Magazine (blog) -ZDNet
alle 39 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla's Working Towards Real Private Browsing in Firefox - TechnoBuffalo

Nieuws verzameld via Google - sn, 22/08/2015 - 15:00


Mozilla's Working Towards Real Private Browsing in Firefox
Mozilla rolled out a few experimental enhancements to its Private Browsing feature that are currently available in pre-beta versions of Firefox, including Firefox Developer Edition on Windows, Mac, and Linux, and Firefox Aurora on Android.

Categorieën: Mozilla-nl planet

Robert O'Callahan: Hooray For WebExtensions

Mozilla planet - sn, 22/08/2015 - 13:14

Many of the comments on WebExtensions miss an important point: basing WebExtensions on the Chrome extension API does not imply limiting WebExtensions to the Chrome API. For example, Bill already made it clear that we want to support addons like Tree Style Tabs and NoScript, which Chrome intentionally does not support. So Firefox addons will continue to be able to do things you can't do in Chrome (though there will be some things you can hack into Firefox's XUL today that won't be supported by WebExtensions, for sure).

WebExtensions is something we need to do and should have done many years ago, before Chrome even existed. It's what Jetpack should have been. But better late than never!

Categorieën: Mozilla-nl planet

Giorgio Maone: WebExtensions API & NoScript

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

Many of you have read a certain announcement about the future of Firefox's add-ons and are worried about some extensions, including NoScript, being deeply rooted into those Mozilla's core technologies, such as XPCOM and XUL, which are going to be deprecated.

Developers and users are also concerned about add-ons being prevented from exploring radically new concepts which would require those "super powers" apparently taken away by the WebExtensions API.

I'd like to reassure them: Mozilla is investing a lot of resources to ensure that complex and innovative extensions can prosper also in the new Web-centric ecosystem. In fact, as mentioned by Bill McCloskey, at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API, which is going to be augmented and shaped around their needs and with their contributions.

I've just published a proposal, tentatively called native.js, to "embrace & extend" the WebExtensions API: all the interested parties are invited to discuss it on

Categorieën: Mozilla-nl planet

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