Well, it finally happened: Mozilla's going to end support for 10.6-10.8. Actually, I'm surprised it took this long:

The motivation for this change is that we have continued failures that are specific to these old operating systems and don't have the resources on engineering teams to prioritize these bugs. Especially with the deployment of e10s we're seeing intermittent and permanently [sic] failures on MacOS 10.6 that we are not seeing elsewhere.

This confirms my suspicions that Electrolysis would have been seriously problematic on 10.4 and 10.5 given the permafails Mozilla is seeing on 10.6, even if we got it to compile (it doesn't even do that on Tiger yet). That's why we're forking after 45ESR, which doesn't have E10S enabled by default.

Interestingly, Mozilla's plan is nearly identical to ours: move 10.6-10.8 users onto 45ESR as well so that they'll still get a year-ish of support on that branch in a sort of graceful wind-down. The difference is that we plan to make hacks to the core to support certain post-45 features (making TenFourFox essentially into an OS X Classilla), and of course backport future security updates from 52ESR and so on. I guess if you're running Snow Leopard you can use TenFourFox post-fork with the usual limitations, but I still currently have no plans for an Intel-native version unless someone steps up to maintain it (although I have a 10.6 machine that might benefit, I just don't have the time right now).

The interesting part is that Mozilla still has more users on 10.6 than 10.7 and 10.8 combined, and 10.6 still accounts for something like 13% of all Firefox Mac users. As late as 2014 19% of all Macs ran it. Snow Leopard really is the Windows XP of the Intel Mac.

Mozilla also did a wholesale pruning of most of the other Tier-3 ports, as part of shifting from autoconf:

Following our official move off autoconf, the core build team is faced with having to convert more than 17k lines of shell+m4. A large part of those are to support Tier-3 platforms such as Solaris, HPUX, AIX, etc., with compilers that are not MSVC, GCC or clang (e.g. SunPro, XL C++...). To simplify the conversion, from day one, we will support only the following set of platforms and toolchains:

Platforms:
- Linux
- Android
- Windows
- OSX/Darwin
- multiple flavors of BSD (kFreeBSD, FreeBSD, DragonFly, NetBSD, OpenBSD)

Toolchains:
- MSVC
- GCC/mingw
- clang
- clang-cl

This is a little different than the end of 10.[678] support, however:

This does not mean Firefox/Gecko/etc. will forever drop support for these platforms and toolchains. It simply means we can't assess what parts of the shell+m4 are relevant (as opposed to cruft accumulated over years or decades) and will continue to work (since we don't have automation to verify these configurations).

[...]

The good news is that dropping support now will help make the overall conversion happen sooner, *and*, once the conversion is done, interested parties can come back with working patches that should be easier to write.

My SPARC Ultra-3 laptop (a rebadged Tadpole Viper) runs an ESR build of Firefox just fine in Solaris 10, the last Solaris supported on that platform. Unfortunately I don't have the Sun compiler, or I'd take a whack at building it myself. At least someone out there is still popping out contrib builds for SPARC and i386, but I don't know if they will continue to.

On the other hand, some of those other platforms haven't worked in years. I know of a Firefox 3.6 for AIX, at least on POWER (my PowerPC AIX systems barf on it), but HP/sUX ended support somewhere around 3.5.9 and was always a mess to build (I hated HP's ANSI C-compiler back in the day when I had to administer those systems). I even remember seeing some Digital UNIX/Tru64 stuff deep within xpcom/, but I can't imagine full support persisted much beyond Mozilla 1.8 something. None of the rest of them got much further.

Really, these are all dusty legacies of how portable the old codebase used to be. At one time, Netscape ran on Windows (as early as 3.1), Mac OS (System 7 and up), OS/2, Linux, Digital UNIX (Tru64), SunOS 4, VMS (VAX and Alpha), Solaris, BSD, HP/UX, IRIX, AIX, and probably some other minority ports I don't remember, and all with almost total feature parity. In fact, I myself have personally used every single one of those ports at one time or another. As late as Mozilla 1.7 almost all of those platforms were still working (SunOS 4 and VMS were gone, and Mac OS was replaced with OS X, but the rest were still functioning), but Firefox 2 and 3 gradually winnowed the rest, and by Firefox 4 it was pretty much just Windows, OS X (including us), Linux, the BSDs and Solaris. Soon it'll just be those OSes on x86-64 and ARM.

So, while it may have been hell to maintain, that's a lot of history gone that I personally lived through and good cause or not it still makes me sad to see these last remnants drift away, even on the abandoned platforms. (You can cram it if you're going to post some uninsightful comment like "paying back technological debt" or "no one maintains platforms for free." I'm well aware of the cost of cruft. That doesn't mean it doesn't have historical value, and that historical value should be appreciated, even if doing so is best done in archives rather than current code bases.) It used to be neat to compare how heterogeneous and diverse computing platforms were back in the day, but sadly today's platforms are more alike than they're different, and I think we've lost something there.

It's not really fun anymore.

http://tenfourfox.blogspot.com/2016/03/apres-moi-le-tier-3-holocaust.html

We had a lot of new participation for the last couple of weeks on developing the site webcompat.com. That's encouraging.

First of all thanks for the new contributions of:

• Dulshani Gunawardhana, Sri Lanka
• Decky Coss, New-York (USA)
• Carol Chung, Los Angeles (USA)
• Deepthi Venkitaramanan, Bangalore (India)

This is due to the Mozilla outreachy program.

An sudden surge of participation means also new good challenges for our community. From the top of my head this week:

Reading Again your Code

New contributors questions on simple things are forcing you to review your own legacy code. Explaining is the best way to understand again some of your choices or to find dead code.

Contributing Guide

We (webcompat.com) needs a better 101 guide on how to contribute to the code. For a while with Mike, Guillaume, Daniel, Hallvord and Alexa, we kind of agreed on ways to manage the project. More specifically, we have half-written rules for:

1. Coding style
2. Commit style
3. Pull Requests Process
4. Review Process

We need to make these a bit more explicit. When a new contributor is not necessary skilled with git and Github and/or has different habits for working with code, we spend time on fixing the code, he or she just wrote. It probably creates frustration for the new contributor to have to redo things. Providing clear guidelines can help a lot a new contributor to avoid the pitfalls of style and make it easier to focus on code (aka the fun part). It also might remove anxiety in the participation.

Changing your own Job

These last two weeks, I spent a lot less time on doing the job and more on helping others do the job. It reminded me when I was the technical director of a Web Agency for a team of 20 developers. Not much time for coding, but trying to help everyone with their questions and where to find the answers (instead of giving the answer). I'm personally always challenged by these two roles. I like coding, but I also like helping others.

Healthier Community

Having more participation on a Mozilla project is healthier, specifically when there are more volunteer contributors. It means the community owns the project in some fashion. It exists because the community needs it, more than Mozilla needs it. It's even more important for a project like webcompat.com which wants to be cross-browser, even if we haven't seen a lot of participation on the browser side except for Microsoft at the beginning.

• The webcompat.com coding part is healthy and even more so since the last few days. Let's hope that some of the new contributors will stick to it.
• The Web Compatibility issues analysis and outreach still are still too dependant on our Mozilla employees team effort.

Coding a Project / Using a Project

This is personal.

I'm always careful when new contributors arrive through a program driven by a chance of getting something out of it, specifically in such a project as webcompat. Coding for the project is fine and it's valuable. Getting experience on it is really cool for both the community and for the individual participating. But there is also the big picture of the project. Are you interested by the goals of the project itself? Is it something which you think the mission is important? Or maybe it's just my own personal bias, where I think you should try to work for places where you have a certain degree of affinity with the project, the company, the mission. There are certain companies of the Silicon Valley I would not work for, not because of their employees, or the awesome or challenging projects they are developing internally, but because of the global mission of their activity. Facebook and Google are two of these because of their ads goal. The same way as a physicist, I would not work the nuclear industry. Huge means, interesting challenges, projects with big impact, but that pinch the wrong chord of my own ethics.

Otsukare!

http://www.otsukare.info/2016/03/17/community-participation

Security of users is paramount. Technology companies need to do everything in their power to ensure the security of their users and build products and services with strong security measures in place to do that.

At Mozilla, it’s part of our mission to safeguard the Web and to take a stand on issues that threaten the health of the Internet. People need to understand and engage with encryption as a core technology that keeps our everyday transactions and conversations secure. That’s why, just days before the Apple story broke, we launched an awareness campaign to educate users on the importance of encryption.

The Apple vs. FBI case

We’ve supported Apple since we first heard of the FBI request to Apple because this case is about user security and public safety.

The government is requiring Apple to create a flawed version of its software without key security features. The precedent this sets could drastically affect our users and every technology company. This can cause ripple effects across the industry to other technologies and companies.  And it would make it more likely that other governments would request the creation of this kind of flawed software. This situation is understandably emotionally-charged, but we don’t have the luxury of saying “just this one time.”

Last week, the FBI said in a brief that Apple purposefully created its products to be warrant-proof and that this fight is a marketing decision for Apple. The view that any company would design products with the goal of being “warrant proof” is ludicrous. Companies like Mozilla decide to create security features to protect users, keep the bad guys away and contribute to public safety, not to make their technology warrant proof. Unfortunately, making something that can be easily hacked by the FBI means making something that can be easily hacked by bad guys too.

Code is Speech

We also think that the FBI’s request raises serious concerns around the First Amendment and free speech. We said so in an amicus brief we filed earlier this month with a coalition of technology companies. For many technology companies their code represents their view on security.  For Mozilla, as an open source company, because our code is made publicly available and guided by our Manifesto, it is an essential way we express our views about security and many other issues.

One of the most important things about this case is that it has created mainstream discourse about some very important topics relevant to all our users – encryption, user security and government access to data. Encryption is an essential and ubiquitous security tool and weakening our security tools undermines everyday Internet users’ security.

Denelle Dixon-Thayer, Chief Business & Legal Officer at Mozilla in conversation with Jochai Ben-Avie, Senior Global Policy Manager on the ongoing encryption conversation & the responsibility of tech companies to defend security.

https://blog.mozilla.org/blog/2016/03/16/user-security-relies-on-encryption/

This is the sumo weekly call We meet as a community every Wednesday 17:00 - 17:30 UTC

https://air.mozilla.org/sumo-community-call-16th-march-2016/

What about using Web Extension APIs to implement core firefox features? Here is the opportunity I would like to discuss today.

Not only new features (Hello, Pocket) but also existing built-in features (e.g Session Restore). I recently blogged about building it as a web extension.

Session restore is a critical feature of Firefox. It uses many mozilla-only technologies: XUL, XPCOM, message managers, jsm and so on. It also involves mostly privileged code whereas it isn’t really needed, possibly leading to security issues. Even if it is living in it’s own folder /browser/components/sessionstore/, there are many hardcoded parts of it elsewhere. It is clearly not self contained.

Instead of just hardcoding this feature into Firefox, we could possibly ship it as an addon. That would have various benefits:

• Let a chance to release this part of firefox faster than the platform,
• Help us experiment by doing some A/B testing with two very different implementations,
• Dogfooding Web Extension APIs would make them more stable and ensure they are both useful and powerful,
• It should open ways to reuse these addons once Servo is ready and implements Web Extension APIs,
• Last but not least, it dramatically reduces the contribution efforts required to modify a core Firefox feature:
  • Forget about building C++ and having a build environment,
  • You can possibly checkout a small repo instead of all mozilla-central,
  • Do not necessarily have to use various mozilla specific tools like mach,
  • No need to even build Firefox itself, instead you could fetch a nightly build and install the addon on it,
  • And forget about all cryptic technologies that we keep using as ancient relics like xul, xpcom and so on!

About contribution. I asked about how many people contribute(d) to session restore. There is mostly one active employee working on it: mconley. Then sparse contributions are being made by other employees like ttaubert, yoric, dragana, mystor, mayhemer,… But there seem to be only one non-employee contribution made by Allasso Travesser with just one patch.

I’m convinved we can engage more with simplier workflows (Addon versus built-in) and technologies with a lower learning curve (Web Extension vs XUL).

http://techno-barje.fr/post/2016/03/16/shipping-firefox-features-as-addon/

The Vaani QA team has started working with the Raspberry Pi, and to that end we thought it would be fun to create a few One and Done tasks so that the community can become more familiar with using the RPi. To that end, we had a few of our community members create some tasks you can try out. Note that at least one of them doesn't require a RPi, so you can actually become more familiar with openHAB just be installing it on your Android or IOS device. Please try out these tasks and let us know what

http://mozillamarciaknous.wix.com/mozcommunity#!New-One-and-Done-tasks-for-Project-Vaani/c218b/56e89d2e0cf286cff61d0621

YouTube link

Want to know what’s going on with onboarding new Firefox users? Here’s a recording of today’s onboarding coordination meeting and a link to the presentation.

http://x627.com/onboarding-coordination-march-15-2016/

Used with permission from Microsoft.

Last time I focused on what the Firefox Windows XP user population appeared to be. This time, I’m going to look into what such a large population means to Firefox and Mozilla.

Windows XP users of Firefox are geographically and linguistically diverse, and make up more than one tenth of the entire Firefox user population. Which is great, right? A large, diverse population of users… other open source projects only wish they had the luck.

Except Windows XP is past its end-of-life. Nearly two years past. This means it hasn’t been updated, maintained, serviced, or secured in longer than it takes Mars to make it around the Sun.

The Internet can be a scary place. There are people who want to steal your banking passwords, post your private pictures online, or otherwise crack open your computer and take and do what they want with what’s inside of it.

Generally, this is an arms race. Every time someone discovers a software vulnerability, software vendors rush to fix it before the Bad Guys can use it to exploit people’s computers.

The reason we feel safe enough to continue our modern life using computers for our banking, shopping, and communicating is because software vendors are typically better at this than the Bad Guys.

But what if you’re using Windows XP? Microsoft, the only software vendor who is permitted to fix vulnerabilities in Windows XP, has stopped fixing them.

This means each Windows XP vulnerability that is found remains exploitable. Forever.

These are just a few vulnerabilities that we know about.

And Windows XP isn’t just bad for Windows XP users.

There are a variety of crimes that can be committed only using large networks of “robot” machines (called “botnets“) under the control of a single Bad Guy. Machines can be recruited into botnets against their users’ will through security vulnerabilities in the software they are running. Windows XP’s popularity and lengthening list of known vulnerabilities might make it an excellent source of recruits.

With enough members, a botnet can then send spam emails in sufficient volume to overload mail servers, attack financial institutions, steal information from governmental agencies, and otherwise make the Internet a less nice place to be.

So Firefox has a large, diverse population of users whose very presence connected to the Internet is damaging the Web for us all.

And so does Google! At least for now. Google has announced that it will end Windows XP support for its Chrome browser in April 2016. (It previously announced end-of-life dates for April 2015, and then December 2015.)

So, as of April, Windows XP users will have only one choice for updated, serviced, maintained, and secured web browsing: Firefox.

Which puts Mozilla in a bit of a bind. The Internet is a global, public resource that Mozilla is committed to defend and improve.

Does improving the Internet mean dropping support for Windows XP so that users have no choice but to upgrade to be able to browse safely?

Or does improving the Internet mean continuing to support Windows XP so that those can at least still have a safe browser to access the Web?

Windows XP users might not have a choice in what Operating System their computers run. They might only be using it because they don’t know of an alternative or because they can’t afford to, aren’t allowed to, or are afraid to change.

Firefox is their best hope for security on the Web. And, after April, their only hope.

As of this writing, Firefox supports versions of Windows from XP SP2 on upwards. And this is likely to continue: the latest public discussion about Windows XP support was from last December, reacting to the latest of Google’s Windows XP support blog posts.

I can reiterate confidently: Firefox will continue to support Windows XP.

For now.

Mozilla will have to find a way to reconcile this with its mission. And Firefox will have to help.

Maybe Mozillians from around the world can seek out Windows XP users and put them in contact with local operations that can donate hardware or software or even just their time to help these users connect to the Internet safely and securely.

Maybe Firefox will start testing nastygrams to pop up at our Windows XP user base when they start their next browsing session: “Did you know that your operating system is older than many Mozillians?”, “It appears as though you are accessing the Internet using a close relative of the abacus”, “We have determined that this is the email address of your closest Linux User Group who can help you secure your computer”

…and you. Yeah, you. Do you know someone who might be running Windows XP? Maybe it’s your brother, or your Mother, or your Babbi. If you see a computer with a button that says “Start” at the bottom-left corner of the screen: you can fix that. There are resources in your community that can help.

Talk to your librarian, talk to the High School computer teacher, talk to a Mozillian! We’re friendly!

Together, we can save the Web.

:chutten

https://chuttenblog.wordpress.com/2016/03/15/mozilla-firefox-and-windows-xp-support/

Weekly project updates from the Mozilla Connected Devices team.

https://air.mozilla.org/connected-devices-weekly-program-review-2/

Reuni'on bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos. Bi-weekly meeting to talk (in Spanish) about Mozilla status, community and...

https://air.mozilla.org/martes-mozilleros-20160315/

Hello! Good news! Friday, March 18th, we will host a new Testday for Firefox 46.0 Beta 3. We will have fun testing Hello (I encourage you to engage our moderators for 1 on 1 calls) and APZ (Async Scrolling). If you want to find out more information visit this etherpad.

You don’t need testing experience to take part in the testday so feel free to join the #qa IRC channel and the moderators will help if you have any questions.

I am waiting forward on seeing you on Friday. Cheers

https://quality.mozilla.org/2016/03/firefox-46-beta-3-testday-march-18th/

My phone just lighted up. POWERMASTER 10 told me something. It said “POWERMASTR 10: KOM OK”.

Over the last few months, I’ve received almost 30 weird text messages from a “POWERMASTER 10”, originating from a Swedish phone number in a number range reserved for “devices”. Yeps, I’m showing the actual number below in the screenshot because I think it doesn’t matter and if for the unlikely event that the owner of +467190005601245 would see this, he/she might want to change his/her alarm config.

Powermaster 10 is probably a house alarm control panel made by Visonic. It is also clearly localized and sends messages in Swedish.

As this habit has been going on for months already, one can only suspect that the user hasn’t really found the SMS feedback to be a really valuable feature. It also makes me wonder what the feedback it sends really means.

The upside of this story is that you seem to be a very happy person when you have one of these control panels, as this picture from their booklet shows. Alarm systems, control panels, text messages. Why wouldn’t you laugh?!

https://daniel.haxx.se/blog/2016/03/15/powermastr-10-kom-ok/

the following changes have been pushed to bugzilla.mozilla.org:

• [1255272] Adding a flag via the MozReview batch-attachment API doesn’t CC the user
• [1229834] extend information we [audit] log to the syslog

discuss these changes on mozilla.tools.bmo.

https://dlawrence.wordpress.com/2016/03/15/happy-bmo-push-day-9/

Software licenses are the constitution for a community. The license a group picks for their software is indicative of how they would like their community to work. GPL-using communities have one set of norms around sharing, BSD or Apache-using communities have another way of working together. That is, of course, as long as everyone using the code plays by the rules.

Basically the only organization attempting to make sure that users of GPL code respect the wishes of the authors of that code is the Software Freedom Conservancy. As well as other excellent work like providing a financial and organizational home for projects, they enforce the GPL – most recently, after five years of fruitless negotiation, in a lawsuit against VMWare, who have taken parts of Linux and put them in their proprietary ESXi product.

Whether you are a keen user of the GPL, or of BSD, or whether you don’t much care about licensing, I hope all my readers are keen that the wishes of authors of software about what happens to it, and the obligations you have if you take advantage of their hard work, are respected. The SFC is a small charity, and corporate donations have suddenly become harder to come by now they are insisting that corporations live up to their responsibilities. (How strange…) I’m proud to say Mozilla has supported SFC in the past, and I hope we will continue to do so. But please would you also consider signing up as a supporter, at the very reasonable cost of US$10 a month.

If people don’t like the terms of the GPL, they are free to write their own software to do whatever they want done. But if they use the hard work of others to save time and effort, they need to respect the wishes of those authors. SFC makes that happen; please give them your support.

http://feedproxy.google.com/~r/HackingForChrist/~3/jR7cNkIjOX4/

[ originally posted on mozilla.dev.platform ]

Hello from Platform Engineering Operations! Once a month we highlight one of our projects to help the Mozilla community discover a useful tool or an interesting contribution opportunity.

This month’s project is Perfherder!

What is Perfherder?

Perfherder is a generic system for visualizing and analyzing performance data produced by the many automated tests we run here at Mozilla (such as Talos, “Are we fast yet?” or “Are we slim yet?”). The chief goal of the project is to make sure that performance of Firefox gets better, not worse over time. It does this by:

• Tracking the performance generated by our automated tests, allowing them to be visualized on a graph.
• Providing a sheriffing dashboard which allows for incoming alerts of performance regressions to be annotated and triaged - bugs can be filed based on a template and their resolution status can be tracked.

In addition to its own user interface, Perfherder also provides an API on the backend that other people can use to build custom performance visualizations and dashboards. For example, the metrics group has been working on a set of release quality indices for performance based on Perfherder data:

https://metrics.mozilla.com/quality-indices/

How it works

Perfherder is part of Treeherder, building on that project’s existing support for tracking revision and test job information. Like the rest of Treeherder, Perfherder’s backend is written in Python, using the Django web framework. The user interface is written as an AngularJS application.

Learning more

For more information on Perfherder than you ever wanted to know, please see the wiki page:

https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder

Can I contribute?

Yes! We have had some fantastic contributions from the community to Perfherder, and are always looking for more. This is a great way to help developers make Firefox faster (or use less memory). The core of Perfherder is relatively small, so this is a great chance to learn either Django or Angular if you have a small amount of Python and/or JavaScript experience.

We have set aside a set of bugs that are suitable for getting started here:

https://bugzilla.mozilla.org/buglist.cgi?list_id=12722722&resolution=---&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=perfherder-starter-bug

For more information on contributing to Perfherder, please see the contribution section of the above wiki page:

https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder#Contribution

https://wlach.github.io/blog/2016/03/platform-engineering-project-of-the-month-perfherder/?utm_source=Mozilla&utm_medium=RSS

The Monday Project Meeting

https://air.mozilla.org/mozilla-weekly-project-meeting-20160314/

http://tantek.com/2016/074/b1/embrace-joy-present

First, a Little Backstory

Presently, Firefox supports two main kinds of add-ons. First were XUL or XPCOM add-ons, which interface directly with the browser’s internals. They are fabulously powerful, as powerful as the browser itself. However, with that power comes security risk and the likelihood that extensions will break as the browser changes.

The Add-on SDK was introduced to provide a stable abstraction API above browser internals to reduce extension compatibility issues between versions of Firefox and make it easier to review extensions for security. As the browser evolved, however, it became clear that we needed something even more robust to take us into the future.

WebExtensions is the new API for building add-ons in Firefox. It seeks to unify the extension APIs and architecture with those of other browsers in the name of interoperability and modern architecture.

The introduction of WebExtensions isn’t an arbitrary change—it stands to improve the stability and security of Firefox for users. It also has a number of advantages for developers.

Cross-Browser Interoperability

Potentially the most impactful aspect of WebExtensions is that it adopts the extension architecture used by browsers built on top of Chromium, notably Chrome and Opera. Mozilla is committed to implementing a large number of the individual APIs presently available to Chrome extensions. This means that it’s possible to have one codebase for an extension that will work in Firefox, Chrome, and Opera with a minimal amount of browser-specific code.

More than Chrome Parity

While our initial API priorities are focused on allowing Chrome extensions to interoperate with Firefox, we plan to competitively and actively expand the API capabilities of WebExtensions. While we anticipate the vast majority of Firefox Add-ons can be ported to WebExtensions, if you need access to browser components not presently exposed, the Add-on SDK is still available. If your add-on or one you use and love is doing something that is not possible with Chrome extensions or the Add-on SDK, please fill out this survey to help us prioritize new APIs.

Common Functionality is Easier

A large number of browser extensions take the form of content scripts, where Javascript is executed against certain (or in some cases all) web pages. WebExtensions optimizes for this case by allowing developers to reduce these types of extensions to 2 files: the script, and a manifest describing the extension and on which pages it should be injected.

Future-Proofing your Work

XPCOM/XUL add-ons are notoriously brittle, breaking whenever browser internals change. The Add-on SDK provides a more stable API surface, but has many synchronous APIs that cross between add-on contexts and web page contents. Mozilla is committed to moving Firefox to a multi-process architecture this year to increase security and stability (read more here), which will break many of these synchronous APIs. WebExtensions APIs are being implemented from the ground-up to be ready for a multi-process Firefox, using asynchronous message passing and event-driven interfaces to enable extensions to communicate with the browser and web pages.

More Secure Extensions

Because extensions built with the Add-on SDK can request XPCOM privileges, they could still introduce unintentional security and stability issues into Firefox. Even add-ons written by well-meaning developers can accidentally introduce vulnerabilities that could allow malicious code to execute with the full privileges of the browser. WebExtensions uses its manifest.json to mitigate this by requiring add-on authors to declare up front which permissions their code will need to operate. Unlike the Add-on SDK, WebExtensions does not allow arbitrary XUL/XPCOM access, so even insecure/vulnerable code is limited to its whitelisted subset of functionality. This vastly reduces the vulnerability surface of a WebExtension, leading to faster review times and a more stable browser.

The Path Forward

We know WebExtensions is a big change, and we’re committed to helping developers prepare and adapt as we roll it out. Initial support for WebExtensions is coming in Firefox 48, and add-ons built with WebExtensions can already be submitted to addons.mozilla.org. The time is now to start experimenting and porting your add-ons! Here are some links to help you get started:

• If you’re an existing add-on author, check out this collection of resources on migrating your add-on to WebExtensions.
• If you’re the author of a Chrome extension, we have a short guide on adding Firefox support to your existing codebase.
• You can also check out this wiki to see more ways to participate in the evolution of WebExtensions.

https://blog.mozilla.org/addons/2016/03/14/webextensons-whats-in-it-for-developers/

https://blog.mathleap.org/happy-pi-day-from-mathleap-a080af87f7ba?source=rss-3e425d04c8c------2

Session Restore is a built-in Firefox feature which preserve user data after a crash or an unexpected close. I spent a little time exploring if it is possible to build such a feature as an replaceable web extension.

Here is a sketch of session store implemented as a web extension:

This addon currently save’n restore:

• tabs (the url for each tab and the tab order)
• form values
• scroll positions

Missing features (compared to the built-in session restore):

• Does not restore session storage
• Always restore the previous session
• I have no idea what it does regarding private browsing
• No dedicated about:sessionrestore page
• Does not save tab history. Instead it just saves the current tab document/form/scroll

To get the above points working, it is a matter of time and possibly some tweaks to the current Web Extensions APIs.

Yes. It is possible to implement a core Firefox feature with the in-progress implementation of Web Extension APIs. It also shows the limitations of the current Chrome APIs. For example in order to fully support tab history, the APIs may needs to be extended.

Source code is available on github. A pre-release version is also available. Don’t forget to toggle xpinstall.signatures.required preference to false from about:config to be able to install it.

http://techno-barje.fr/post/2016/03/14/session-restore-web-extension/