This is a weekly call with some of the Reps council members to discuss all matters Reps, share best practices and invite Reps to share...

https://air.mozilla.org/reps-weekly-20151015/

So WebExtensions are the great new way to build Firefox extensions, and soon everybody creating a new extension should be using that over everything else. But what about all the people who already have extensions? How can one be expected to migrate a large extension to WebExtensions and still keep it working? Chances are that you will first spend tons of time rewriting your code, and then even more time responding to complains of your users because that rewrite introduced bugs and unintended changes.

I don’t want to see myself in that hell, a gradual migration is almost always a better idea. So I looked into ways to use WebExtensions APIs from my existing, “classic” extension. And – yes, it works. However, at this point the approach still makes many assumptions and uses internal APIs, so the code example below is merely a proof-of-concept and should be used with caution.

The good news, WebExtensions are currently implemented as a subset of bootstrapped extensions with a very simplistic bootstrap.js. Yay, it is merely creating an Extension instance – I can do that as well! Ok, it’s not quite as simple, and the final code (here based on Add-on SDK but can be done similarly from any extension) looks like this:

let self = require("sdk/self");
let unload = require("sdk/system/unload");
let {Ci, Cu} = require("chrome");

let {Services} = Cu.import("resource://gre/modules/Services.jsm", {});
let {Extension, ExtensionPage, Management} = Cu.import("resource://gre/modules/Extension.jsm", {});
let global = this;

function resolveURI(uri)
{
  if (typeof uri == "string")
    uri = Services.io.newURI(uri, null, null);
  if (uri.scheme == "resource")
  {
    let protoHandler = Services.io.getProtocolHandler("resource")
                                  .QueryInterface(Ci.nsIResProtocolHandler);
    return resolveURI(protoHandler.resolveURI(uri));
  }
  else
    return uri;
}

let extension = new Extension({
  id: self.id,
  version: self.version,
  resourceURI: resolveURI(self.data.url(""))
});
extension.startup().then(function()
{
  let context = new ExtensionPage(extension, {type: "background", contentWindow: global});
  let chrome = Management.generateAPIs(extension, context);
  chrome.tabs.query({active: true}, function(tabs)
  {
    chrome.tabs.executeScript(tabs[0].id, {
      code: "chrome.runtime.sendMessage(window.location.href)"
    });
    chrome.runtime.onMessage.addListener(function(message)
    {
      console.error(message);
    })
  });
}).catch(function(e)
{
  console.error(e);
});
unload.when(() => extension.shutdown());

This code will inject a content script into the current tab to retrieve its URL and print it to console (assuming that you have something loaded in the current tab that you are allowed to access and not about:addons for example, otherwise it will throw an obscure exception). Yes, it’s a very complicated way of doing it but I wanted to make sure that the messaging really works. But there clearly more details here worth explaining:

• The parameter passed to the Extension parameter is fake boostrap data. The interesting part here is resourceURI – that’s where WebExtensions will consider the root of your extension to be, e.g. they will load manifest.json from that directory (make sure to declare "tabs" and "" permissions there). Content script URLs will also be resolved relative to it, so using the data/ directory makes sense for SDK-based extensions.
• At the moment, resourceURI parameter has to be an nsIURI instance and it has to use the file: or jar: scheme, that’s why I have that relatively complicated resolveURI() function there.
• ExtensionPage and Management aren’t actually exported by the module I’m importing there, these are internal API and will likely change in future (in fact, I doubt that the Extension class is really stable at this point).

I filed a bunch of bugs to make this simpler and more reliable, these are tracked under bug 1215035. The biggest issue now is backwards compatibility, somehow browser developers tend to forget that extensions cannot support only the latest nightly build. At the very least, the current and previous stable releases of Firefox are supported, often the latest ESR release as well. The first ESR release with WebExtensions support is expected to come out mid-April 2016, and somehow I don’t have the impression that Mozilla would let us wait until then with the WebExtensions adoption (it’s not really a good idea either because bugs about incomplete or faulty APIs need to be filed ASAP).

https://palant.de/2015/10/15/using-webextensions-apis-in-a-classic-extension

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

• Most nominations for full review are taking less than 10 weeks to review.
• 212 nominations in the queue awaiting review.
• Most updates are being reviewed within 9 weeks.
• 89 updates in the queue awaiting review.
• Most preliminary reviews are being reviewed within 10 weeks.
• 180 preliminary review submissions in the queue awaiting review.

We had a regression in review times in the last week or two due to reviewer availability, but we expect to catch up soon. We’re also adding another contractor to our team, hopefully soon.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 42 Compatibility

The compatibility blog post is up. I filed the validator bugs today, so we’ll probably run the bulk validator sometime next week.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition (formerly known as Aurora) to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Changes in let and const in Firefox 44

The latest Nightlies include some breaking changes that you should all be aware of. Please read the post carefully and test your add-ons on Nightly.

Extension Signing

The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions. The current plan is to turn on enforcement by default in Firefox 43.

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running content code in a different process than browser code.

Web Extensions

If you read Kev’s post on the future of add-on development, you should know there are big changes coming. We’re investing heavily on the new WebExtensions API, so we strongly recommend that you start looking into it for your add-ons. You can track progress of its development in http://www.arewewebextensionsyet.com/.

https://blog.mozilla.org/addons/2015/10/14/add-ons-update-72/

This is the meeting where all the Mozilla quality teams meet, swap ideas, exchange notes on what is upcoming, and strategize around community building and...

https://air.mozilla.org/quality-team-qa-public-meeting-20151014/

This is a weekly status meeting, every Wednesday, that helps coordinate the shipping of our products (across 4 release channels) in order to ensure that...

https://air.mozilla.org/product-coordination-meeting-20151014/

Watch mconley livehack on Firefox Desktop bugs!

https://air.mozilla.org/the-joy-of-coding-mconley-livehacks-on-firefox-episode-30/

TL;DR

Many add-ons are currently broken on Nightly (Firefox 44) due to some changes that were done in the way let and const behave. These changes were introduced to make Firefox compliant with the final ES6 standard. These changes can lead to JS errors that break your code entirely, so we suggest you test your add-ons extensively to make sure they continue to work.

All add-ons built with JPM (except the latest version) are currently affected by this. We plan to automatically repack all affected JPM add-ons on AMO, but encourage you to repackage the add-on yourself and save some time. Pre-JPM versions of the SDK aren’t affected.

Please read on for the details of this change, written by Shu-yu Guo. It’s an interesting read even if your add-on isn’t affected.

Did this update break your add-on? This post will help you diagnose and fix issues it caused.

Legacy Semantics

At the global level, legacy let was equivalent to var. Inside the parser, it was in fact parsed as if the token were var.

Global-level legacy const was like var, except that the property it introduced was read-only.

ES6 global lexical bindings are not properties

The biggest incompatibility is that ES6 let and const bindings, unlike their legacy counterparts, are no longer properties on the global object. Instead, they are bindings in the global lexical scope directly below the global object.

For example,

const x = 42;
// Prints false for ES6, true for legacy
dump('x' in this);

Many add-ons have the expectation that global let and const introduce properties. For instance, a legacy JSM might define constants and globals:

// Foo.jsm
const MY_CONSTANT = 42;
let gFoo = "foo";
 
// addon.js
var FooModule = Cu.import("Foo.jsm", {});
dump(FooModule.MY_CONSTANT);
dump(FooModule.gFoo);

With ES6 const, FooModule.MY_CONSTANT and FooModule.gFoo are both undefined, because their bindings are in a separate scope and not properties on the global object. This makes bugs caused by these errors particularly elusive.

For uses of global legacy let bindings that need to be accessed as properties, I recommend declaring them with var.

Unfortunately, there is no ES6 syntax with the same semantics as legacy const. If the read-only aspect of the property is necessary, I recommend manually defining a property on the global object:

Object.defineProperty(globalObject, "MY_CONSTANT", {
  value: 42,
  enumerable: true,
  writable: false
});

If your add-on imports XPCOMUtils, XPCOMUtils.defineConstant(obj, key, value) does exactly that.

ES6 global lexical bindings may not be redeclared

In ES6, global lexical bindings may not be redeclared in any way: not by let, const, nor var. For example, if the global level has let foo or const foo, any subsequent occurrences of let foo, const foo, or var foo will throw.

Redeclaration errors are easy to fix: rename the variable or remove the declarator and assign to the already-declared variable directly.

ES6 global lexical bindings have TDZ

In ES6, no lexical binding may be used before its declaration is reached. For example, the following throws:

dump(x);
let x;

This has long been regarded as poor style in the community, and fortunately, such errors in existing code are rare. If such an error is encountered, it is very likely a bug in the code.

Global lexical scope and JSSubScriptLoader

The subscript loader may load new scripts into the global scope. This interacts with the ES6 global lexical scope. The pitfall is that since lexical bindings may not be redeclared, loading multiple scripts that redeclare globals with let or const now result in error. For example,

// foo.js
let gFoo;
 
// bar.js
let gFoo;
 
// addon.js
loader.loadSubScript("foo.js");
loader.loadSubScript("bar.js"); // throws due to redeclaration of gFoo

Global lexical scope and the component loader

When loading components, such as via Cu.import, each component has its own global scope and global lexical scope, so cross-script redeclaration issues do not arise.

Cu.import returns the global object of the imported component, so the main pitfall is using let and const-declared bindings as properties on that scope.

Global lexical scope and custom scopes

Both the subscript and component loaders let users load scripts whose global variables and properties are stored in a user-provided scope object. For example, suppose we had foo.js:

// foo.js
var gVar;
let gLet;
const gConst;

Calling loader.loadSubScript("foo.js", myScope) would result in parsing foo.js with the following scope chain, from outermost to innermost:

     Global object
           |
  Global lexical scope
           |
        myScope
           |
          ...

Without user-passed scopes, var bindings go on the global object. Lexical let and const bindings go on the global lexical scope.

From the point of view of var bindings, myScope behaves like the global object: they capture var bindings as properties. That is, gVar is a property on myScope, not the global object.

Global lexical let and const bindings shadow global properties: gLet would hide a property reachable via this.gLet. Since myScope captures var bindings, consistency requires myScope to have its own lexical scope that captures let and const bindings:

     Global object
           |
  Global lexical scope
           |
        myScope
           |
  myScope's lexical scope

In the example, gLet and gConst are bindings in myScope‘s lexical scope. Multiple scripts loaded into myScope would get the same lexical scope. Scripts loaded into myOtherScope would get myOtherScope‘s lexical scope, an entirely different scope.

Note that lexical bindings are still not properties on the non-syntactic scope. If your add-on uses custom scopes, you may run into the problems described in “ES6 global lexical bindings are not properties” above.

https://blog.mozilla.org/addons/2015/10/14/breaking-changes-let-const-firefox-nightly-44/

Starting today, a Mozilla LDAP account with Mercurial SSH access is no longer required to hg push into MozReview to initiate code review with Mozilla projects.

The instructions for configuring your client to use MozReview have been updated to reflect how you can now push to MozReview over HTTP using a Bugzilla API Key for authentication.

This change effectively enables first-time contributors to use MozReview for code review. Before, you had to obtain an LDAP account and configure your SSH client, both of which could be time consuming processes and therefore discourage people from contributing. (Or you could just use Bugzilla/Splinter and not get the benefits of MozReview, which many did.)

I encourage others to update contribution docs to start nudging people towards MozReview over Bugzilla/patch-based workflows (such as bzexport).

Bug 1195856 tracked this feature.

http://gregoryszorc.com/blog/2015/10/14/lowering-the-barrier-to-pushing-to-mozreview

El modo de navegaci'on privada ha recibido una actualizaci'on que incluye una mejor explicaci'on de qu'e es, sumado a la opci'on de navegar con una protecci'on de rastreo. ?A qu'e nos referimos con rastreo?

La mayor fuente de ingresos en la Web es la publicidad. El principal diferencial de la publicidad mientras navegas, en comparaci'on con la radio o la televisi'on, es que los anunciantes pueden dirigir esa publicidad con mayor precisi'on a los usuarios supuestamente interesados en sus servicios y/o productos.

Para poder brindar este servicio, las empresas que venden publicidad (Google y Facebook entre las principales, pero no las 'unicas) deben rastrear tus acciones mientras navegas para crear el perfil necesario para ofrecerte lo que imaginan que quieres.

Otros sitios agregan c'odigo a sus p'aginas para que otras empresas puedan construir ese perfil y ofrecer publicidades.

Nueva vista de Navegaci'on privada

C'omo funciona la protecci'on de rastreo de Firefox

Cuando entras a un sitio web, Firefox solicita las diferentes partes que conforman la p'agina. Algunos de ellas no est'an alojadas en el mismo sitio, si no en servidores de otras empresas. Este contenido externo es cotejado con una lista de sitios sospechados de rastrear tu comportamiento y no se descargan. Esta lista es creada y mantenida por Disconnect.me, un servicio fundado en 2011 que trabaja para proteger tu navegaci'on del rastreo de terceros, que cuenta entre sus socios a la Electronic Frontier Foundation y Tor Project.

Por eso, como se ejemplifica en el tour que te aparecer'a la primera vez que uses este nuevo modo de navegaci'on privada, algunas partes de la p'agina a las que estabas acostumbrado, quiz'as desaparezcan. Una imagen vale m'as que mil palabras:

Arriba la vista normal, debajo con la Protecci'on de rastreo activada

Como consecuencia, muchas p'aginas adem'as cargan m'as r'apido, ya que tienen que descargar menos contenido.

Una comparaci'on entre la carga de Clarin.com sin y con protecci'on de rastreo

La misma comparaci'on en Genbeta, donde la cantidad de segundos en carga disminuye perceptiblemente

?Es el bloqueador de publicidad de Firefox?

La respuesta corta es «no». Esta protecci'on de rastreo, aunque relacionada con los avisos, no es un bloqueador de publicidad. Como dijimos antes, el contenido que se bloquea es el que venga de otras empresas/organizaciones que no sean las autoras del sitio web y que son sospechadas de rastrear tu comportamiento.

Citando el blog de Mozilla: El bloqueo «incluye elementos de contenido, anal'iticos, de redes sociales y otros servicios que pueden estar recolectando informaci'on sin tu conocimiento.»

Un ejemplo contrario, si vas a un sitio Web que utiliza el sistema de foros de Facebook, no lo ver'as, porque en general, Facebook rastrea tu comportamiento todo lo que puede.

Ay'udanos a probar su funcionamiento

Ya puedes probar la nueva versi'on de la navegaci'on privada usando el canal Beta de Firefox que puedes descargar desde aqu'i (para Windows y Linux de 32 bits).

Para empezar a usarla, debes ir al men'u y hacer clic en Nueva ventana de navegaci'on privada (o Ctrl+May+p). La primera vez ver'as un tour que te explicar'a el funcionamiento y c'omo habilitar y deshabilitar esta funci'on en cada sitio que quieras. Prueba distintos sitios y ten en cuenta qu'e servicios desaparecen y cu'ales puedes seguir viendo con esta funci'on.

Fuente: Mozilla Hispano

http://firefoxmania.uci.cu/mayor-privacidad-de-tu-navegacion-en-firefox/

Upgrading Buildbot 0.8.6 to 0.8.12

Here are some quick notes on upgrading Buildbot.

python-dev
python-openssl
libffi-dev
libssl-dev

buildbot==0.8.12
boto
pyopenssl
cryptography
SQLAlchemy<=0.7.10

http://edunham.net/2015/10/14/upgrading_buildbot_0_8_6_to_0_8_12.html

This is mostly relevant for *nix users. OpenSSH has a feature that lets you setup a SOCKS proxy pretty easily. This helps work around blocked sites without too much setup overhead.

Here’s what you do.

ssh -ND 10000 user@myserver.com

The -D flag specifies the local port that will be forwarded to the remote server. The -N flag makes sure that after the connection is made, no remote command is executed.

Now, open Firefox -> Preferences -> Advanced -> Network -> Settings. Select the “Manual proxy settings” option and enter localhost into SOCKS Host and 10000 into Port. Press OK. Now when you browse the internet on this instance of Firefox, the traffic should be routed through the server.

I’ve used if often to get around blocks and especially to get around local routing issues.

Remember, if your ssh connection breaks, your can’t visit any websites until you re-establish the connection. After you’re done, set the proxy settings back to the default (“Use System Proxy Settings”).

http://nigelb.me/2015-10-14-quick-socks-proxying-with-ssh.html

This morning Ars Technica had a wonderful article on CSS colour names titled ““Tomato” versus “#FF6347”—the tragicomic history of CSS color names“. It made me look again into the wonderful world of CSS colour names and create an interactive demo showing them when you roll over the colour swatches.

Building up on this, I created a small game, that allows you to train your knowledge of colours and their names.

(The colours in the game don’t change, this is a GIF issue…)

The source code is on GitHub, and it is pretty simple to create these things, once you have the dataset.

There were some fun exercises in there, like how to sort the colours by lightness (split the values each 2 characters, convert to decimal, push into array, sort it) and creating an array_shuffle in JS (hey, PHP has it).

The game keeps your score in local storage and should work fine on mobile – it does on my Huawei Honor.

https://www.christianheilmann.com/2015/10/14/fun-with-css-colour-names/

http://feedproxy.google.com/~r/armenzg_mozilla/~3/vein_Ln1FcY/mozci-0151-buildbot-bridge-support-bug.html

• Use the full 20 byte / 40 character hashes for revisions
• Make the project flake8_docstrings compatible
• Readme and instructions are not usable for non-python-wizards
• Increase our test coverage
• Remove the need for LDAP credentials to determine valid repositories
• Add the ability in mozci scripts to re-trigger all existing jobs / all failed jobs
• Add TaskCluster GitHub integration to Mozci
• Release the pushlog module as a Python package and depend on it
• Release the buildapi module as a Python package and depend on it
• Create script which generates .yml files under Mozilla's Gecko tree
• Handle KeyboardInterrupt for all various scripts
• Add --existing-only support to triggerbyfilters

http://feedproxy.google.com/~r/armenzg_mozilla/~3/r2So56MPW6E/mozilla-ci-tools-contribution.html

If you’re into Mercurial bookmarks, hailed as the Mercurial equivalent to git branches, my excellent colleague Andrew Halberstadt has written an extension that returns commits associated with a particular bookmark called bookbinder.

In his own words, “[a] book binder is a person or machine [that] binds pages to books. In a similar vein, bookbinder binds commits to bookmarks”. It does this by implementing a feature revset allowing bookbinder to subvert all commands that have a REV argument and replace any detected bookmark names with the feature revset.

This normally works by passing the name of your bookmark to any command that supports bookmarks, e.g. hg log -r BOOKMARK, and it will then replace BOOKMARK with a revset containing all changesets “within” this bookmark.

Because the stock hg log doesn’t make much sense to me, especially without passing --graph to graphically display the repository’s DAG, I highly recommend having a look at it to give hg log back some sanity.

Since I never get around to clean up my bookmarks, it would be quite convenient to instruct bookbinder to show me the commits associated with the bookmark of my latest commit.

For this I’ve added an alias to my .hgrc that tells it to pick the bookmark from my last commit, or tip:

[alias]
blog = log --rev 'feature(tip)'

If I have three commits on my bookmark, this will return something akin to what you would expect from git log:

% hg blog
changeset:   267448:66fae38273f2
bookmark:    bug_1202663_super
tag:         tip
user:        Andreas Tolfsen
date:        Tue Oct 13 16:52:26 2015 +0100
summary:     Bug 1213797: Refactor screen capture and SVG document support

changeset:   267447:3cc8741649af
user:        Andreas Tolfsen
date:        Fri Oct 09 12:02:42 2015 +0100
summary:     Bug 1202663: Use dispatcher for screen capture command in listener

changeset:   267446:880e2bdb24ff
parent:      267426:607a236c2299
user:        Andreas Tolfsen
date:        Tue Oct 13 16:58:40 2015 +0100
summary:     Bug 1213800: More exhaustive Marionette screen capture tests

http://sny.no/2015/10/bookbinder

http://home.kairo.at/blog/2015-10/shortening_crash_signatures_dropping_arg

https://fundraising.mozilla.org/eoy-fundraising-preview-getting-ready/

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-20151013/

Esta es una traducci'on del art'iculo original publicado en el blog Future Releases. Escrito por Benjamin Smedberg .

Mozilla ha ido mejorando constantemente su plataforma Web para apoyar caracter'isticas que antes s'olo estaban disponibles a trav'es de plugins NPAPI. Caracter'isticas como el video en vivo (streaming) y, los gr'aficos avanzados y de juegos se han convertido en APIs Web nativas en los 'ultimos a~nos. Mozilla sigue dando prioridad a caracter'isticas que har'an posible a los sitios poder funcionar sin plugins. Caracter'isticas tales como el acceso al portapapeles que sol'ian requerir plugins, ahora est'an disponibles a trav'es de las API Web nativas. ?A qu'e se debe esto? A que los navegadores y la Web han crecido y NPAPI ha mostrado su edad. Los plugins son una fuente de problemas de rendimiento y de accidentes e incidentes de seguridad para los usuarios de la Web.

Mozilla tiene la intenci'on de eliminar el soporte para la mayor'ia de los plugins NPAPI en Firefox antes de finales de 2016. Firefox comenz'o este proceso hace varios a~nos (EN) con la activaci'on manual de plugins, permitiendo a los usuarios activar los plugins s'olo cuando creen que son necesarios. Esta decisi'on refleja las acciones de los otros navegadores modernos, como Google Chrome y Microsoft Edge, que ya han eliminado el soporte para NPAPI. Adem'as, dado que las nuevas plataformas de Firefox no tienen que soportar un ecosistema existente de usuarios y plugins, las nuevas plataformas de 64 bits de Firefox para Windows funcionar'an sin soporte para plugins.

Activaci'on manual de plugins en Firefox

Debido a que Adobe Flash es todav'ia una parte com'un de la experiencia en la Web para la mayor'ia de los usuarios, vamos a seguir siendo compatibles con Flash dentro de Firefox como una excepci'on a la pol'itica de complementos en general. Mozilla y Adobe continuar'an colaborando para traer mejoras a la experiencia de Flash en Firefox, incluyendo la estabilidad y el rendimiento, las caracter'isticas y la arquitectura de seguridad.

Como parte de nuestra estrategia de plugin, Mozilla y Unity est'an orgullosos de anunciar una estrecha colaboraci'on y un plan en conjunto que permitir'a contenido basado en Unity para ser reproducido directamente en el navegador sin necesidad de plugins. Como esta tecnolog'ia sigue evolucionando, Unity ha anunciado (EN) un plan de trabajo actualizado para su tecnolog'ia Web Player.

Los sitios Web y editores que actualmente utilizan plugins como Silverlight o Java deben acelerar su transici'on a tecnolog'ias web. La plataforma Web es de gran alcance y por lo general se puede hacer todo lo que un plugin puede hacer. En los raros casos en que un sitio tiene que extender las tecnolog'ias Web, la soluci'on recomendada es desarrollar las caracter'isticas adicionales como un complemento de Firefox. Los mantenedores de sitios deben prepararse para que los plugins dejen de funcionar en todas las versiones de Firefox para finales de 2016.

Mozilla contin'ua trabajando con Oracle Java Platform Group para asegurar una transici'on sin problemas para los sitios web que utilizan Java. Para m'as informaci'on de Oracle acerca de los planes de transici'on de Java pueden remitirse a este art'iculo (EN) de Oracle Team. Oracle recomienda (EN) que los sitios que utilizan actualmente los applets de Java consideren cambiar a plugins libres tales como Java Web Start.

El equipo de Mozilla quiere trabajar en estrecha colaboraci'on con los editores afectados para que su transici'on sea lo menos problem'atica posible. La Web proporciona un entorno cada vez m'as rico que deber'ia eliminar la necesidad de plugins, y estamos ansiosos por seguir mejorando la plataforma Web para cualquier caso donde a'un pueden ser necesarios plugins para su uso. Para plantear una discusi'on o pregunta sobre el futuro de los plugins en Firefox pueden dirigirse a lista de desarrollo de plugins de Mozilla (EN).

?Y ustedes qu'e opinan? ?Les parece bien que Firefox siga trabajando con Flash Player? ?Qu'e creen de la activaci'on manual de plugins?

Fuente: Mozilla Hispano

http://firefoxmania.uci.cu/el-futuro-de-los-plugins-npapi-en-firefox/

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

https://bugzil.la/1172418 : user fields are cleared when navigating back to a page (eg. after an error)
https://bugzil.la/1211703 : help docs not available for User Preferences
https://bugzil.la/1212721 : gravatar container for comment 0 can be too wide
https://bugzil.la/1207379 : Button edges are hard to see at most zoom-levels, with bmo “experimental user interface”
https://bugzil.la/1204410 : Buttons besides ‘User Story’ overflow if the user story is a one-liner
https://bugzil.la/1181044 : linkification isn’t applied to the user-story field
https://bugzil.la/1200765 : Make login UX mobile friendly to assist mobile authentication workflow
https://bugzil.la/1202281 : BMO login being reset for every browser session
https://bugzil.la/1213033 : make the TOTP MFA code field type=number on mobile
https://bugzil.la/1029800 : Release Tracking Report doesn’t return bugs with tracking flags set to — when searching for “not fixed” values
https://bugzil.la/1178094 : Update crash signatures to match new Socorro signature generation
https://bugzil.la/1150358 : cannot remove other people from the cc list
https://bugzil.la/1149899 : Remember expanded/collapsed sections
https://bugzil.la/1197805 : Always show “never email me about this bug” checkbox
https://bugzil.la/1211891 : needinfo requests where the current user is the requestee shouldn’t be editable
https://bugzil.la/1199089 : add support for duo-security

https://globau.wordpress.com/2015/10/13/happy-bmo-push-day-164/