Thunderbird, the future, mozilla-central and comm-central

This is a long-ish message. It covers general topics about Thunderbird and the future, and also the topics of the Foundation involvement (point 9) and the question of merging repositories (point 11). Naturally, I believe it’s worth the time to read through the end. 1. Firefox and

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On Tue, Dec 1, 2015 at 4:26 AM, Ehsan Akhgari wrote: Should we finally bite the bullet and force a flush in reftests/crashtests? You mean force a flush in the load event handler in the test harness, before the test's load event handler runs? > After thinking about

Re: Using the Taskcluster index to find builds

FWIW, I used this for "diditland" - http://www.gijsk.com/blog/2015/11/did-it-land/ and https://gijsk.github.io/diditland/ . It was a significant improvement over scraping archive.mozilla.org's HTML pages for a month, finding the right folder for a nightly, and then scraping that for the right

Re: ESLint is now available in the entire tree

The Gecko JavaScript is also littered with #ifdef and # is really not a token for comment in JS... is there any plan to migrate that away since there is ESLint present? On Sun, Nov 29, 2015 at 10:37 PM, Vivien Nicolas wrote: > On Sun, Nov 29, 2015 at 2:30 PM, David Bruant

Re: ESLint is now available in the entire tree

I don't how much work is involved with getting rid of non-standard spidermonkey syntax and pre-processors, but if it's a lot, then one option would be to fork the espree parser (used by eslint), make it support those, and configure eslint to use our fork:

Re: Dan Stillman's concerns about Extension Signing

On 29/11/2015 02:56, Dan Stillman wrote: You can block known malware signatures with the scanner if you think that's a good use of time. But that doesn't require blocking valid APIs and patterns that have legitimate uses. That's what we're discussing here. AV software doesn't result in long

Re: ESLint is now available in the entire tree

On 30.11.2015 10:29, Patrick Brosset wrote: > I don't how much work is involved with getting rid of non-standard > spidermonkey syntax and pre-processors, but if it's a lot, then one option > would be to fork the espree parser (used by eslint), make it support those, > and configure eslint to use

APZ enabled on Fennec nightly

Hi all, Just a heads up that I landed the patch to enable APZ on Fennec (nightly channel only for now). It should be in the Dec 1 nightly and onwards. This will make scrolling around, and general touch input handling, feel different on Fennec. The main improvement should be that scrolling of

Re: Intent to unship: ISO-2022-JP-2 support in the ISO-2022-JP decoder

On Mon, Nov 30, 2015 at 7:38 AM, Henri Sivonen wrote: > Other browsers don't support this extension, so it clearly can't be a > requirement for the Web Platform Generally speaking, I don't think this reasoning is entirely accurate. We know that there's lots of

Re: Intent to unship: ISO-2022-JP-2 support in the ISO-2022-JP decoder

On 30/11/2015 16:38, Henri Sivonen wrote: Are there any objections to removing the ISO-2022-JP-2 functionality from mozilla-central? Hello, I am currently in the process of repairing long-standing issues with CJK e-mail in general and Japanese e-mail using ISO-2022-JP in particularm see

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On 2015-11-28 1:00 AM, Boris Zbarsky wrote: On 11/27/15 2:15 AM, Axel Hecht wrote: I wonder, how much of the web could rely on this, given our tests do? Our test failures were mostly along the lines of "we expected an assertion here and now we don't get one". I doubt that would much affect

Better mach support for Firefox for Android

In recent months, many improvements have been made to mach commands to support running, testing, and debugging Firefox for Android: - More test commands for Android. These mach test commands now support Firefox for Android explicitly: mach mochitest mach robocop mach reftest mach

Re: Dan Stillman's concerns about Extension Signing

That's one of the suggestions Dan Stillman makes in his post, and it seems like a fine idea to me. Gavin On Mon, Nov 30, 2015 at 11:15 AM, Jonathan Kew wrote: > On 30/11/15 15:45, Gavin Sharp wrote: >>> >>> and it's definitely the wrong thing to do. >> >> >> Fundamentally

Re: Dan Stillman's concerns about Extension Signing

Hi Am 27.11.2015 um 16:50 schrieb Gavin Sharp: > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham wrote: >> But the thing is, members of our security group are now piling into the >> bug pointing out that trying to find malicious JS code by static code >> review is literally

Re: Dan Stillman's concerns about Extension Signing

It looks to me like you're arguing about a separate point (AMO review requirements for add-on updates), when the subject at hand is the add-on signing system's reliance on the AMO validator as the only prerequisite for automatic signing. Gavin On Mon, Nov 30, 2015 at 10:30 AM, Thomas Zimmermann

Re: Dan Stillman's concerns about Extension Signing

> and it's definitely the wrong thing to do. Fundamentally the add-on signing system was designed with an important trade-off in mind: security (ensuring no malicious add-ons are installed/executed) vs. maintaining a healthy add-on ecosystem (ensuring that building and distributing add-ons is as

Re: Dan Stillman's concerns about Extension Signing

On 30/11/15 15:45, Gavin Sharp wrote: and it's definitely the wrong thing to do. Fundamentally the add-on signing system was designed with an important trade-off in mind: security (ensuring no malicious add-ons are installed/executed) vs. maintaining a healthy add-on ecosystem (ensuring that

Re: Dan Stillman's concerns about Extension Signing

Could we perhaps organize a MozLando workshop to discuss add-ons security? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: ISO-2022-JP-2 support in the ISO-2022-JP decoder

Japanese *email* is often encoded as ISO-2022-JP, and Web browsers also support ISO-2022-JP even though Shift_JIS and EUC-JP are the more common Japanese legacy encodings on the *Web*. The two UTF-16 variants and ISO-2022-JP are the only remaining encodings in the Web Platform that encode

Re: Dan Stillman's concerns about Extension Signing

Hi Am 30.11.2015 um 16:40 schrieb Gavin Sharp: > It looks to me like you're arguing about a separate point (AMO review > requirements for add-on updates), when the subject at hand is the add-on > signing system's reliance on the AMO validator as the only prerequisite for > automatic signing. OK.

Contributor wishes to help with writing a web bot/crawler (was Fwd: [dev-mdc] Greetings!)

Hi there, Apologies for the multi-list posting, but I’m really not sure where best to send this. If you are interested in talking to Mudit, please trim down the reply-list before posting! So, Mudit (cc’d) wishes to contribute to Mozilla by helping to write a web bot/crawler to help[ the

Re: Intent to unship: ISO-2022-JP-2 support in the ISO-2022-JP decoder

On Mon, Nov 30, 2015, at 01:24 PM, Adam Roach wrote: > Does this mean it might interact with webmail services as well? Or do > they tend to do server-side transcoding from the received encoding to > something like UTF8? They do server-side decoding. It would take a tremendous amount of effort

Re: Better mach support for Firefox for Android

Thanks for all your work in making this happen! I've used some of these commands recently and they work much better than they used to for Fennec :) On Mon, Nov 30, 2015 at 12:32 PM, Geoffrey Brown wrote: > In recent months, many improvements have been made to mach commands to

Re: Intent to unship: ISO-2022-JP-2 support in the ISO-2022-JP decoder

On 11/30/15 09:38, Henri Sivonen wrote: The only known realistic source of ISO-2022-JP-2 data is Apple's Mail application under some circumstances, which may impact Thunderbird and SeaMonkey. Does this mean it might interact with webmail services as well? Or do they tend to do server-side

Re: ESLint is now available in the entire tree

The plan in general for chrome JS is to switch from #ifdefs to having things defined in AppConstants.jsm Fabrice On 11/30/2015 01:05 AM, Tim Guan-tin Chien wrote: > The Gecko JavaScript is also littered with #ifdef and # is really not a > token for comment in JS... is there any plan to

Re: Dan Stillman's concerns about Extension Signing

(Gingerly wading into this thread and hoping not to get sucked in) Given the fundamental limits of static analysis, dynamic analysis might be a better approach. I think we can do a reasonable job (with the help of interpositions) of monitoring the various escape points at which addon code might

Re: Dan Stillman's concerns about Extension Signing

On 2015-11-30 10:29 AM, David Rajchenbach-Teller wrote: Could we perhaps organize a MozLando workshop to discuss add-ons security? I think you need to reach out to the add-ons team. I was not involved in any of the design process; I just happened to note the same issues as Dan noticed after

Re: Dan Stillman's concerns about Extension Signing

On Monday, November 30, 2015 at 8:57:42 PM UTC+1, Dan Stillman wrote: > On 11/30/15 6:24 AM, Gijs Kruitbosch wrote: > > This seems like something we should be able to get data about. (I do > > not have such data.) Have you asked anyone? > > If it's only Zotero that's affected by this, then we

Re: Dan Stillman's concerns about Extension Signing

Just to give some context here, we've been asking for a "trusted author" whitelist for three months. Gijs even helpfully proposed specific rules. The reason things came to this point is that it was still being argued as of last week that the whitelist was inherently more dangerous by allowing

Re: Intent to unship: ISO-2022-JP-2 support in the ISO-2022-JP decoder

On 11/30/2015 1:02 PM, Andrew Sutherland wrote: On Mon, Nov 30, 2015, at 01:24 PM, Adam Roach wrote: Does this mean it might interact with webmail services as well? Or do they tend to do server-side transcoding from the received encoding to something like UTF8? They do server-side decoding.

Using the Taskcluster index to find builds

The RelEng, Cloud Services and Taskcluster teams have been doing a lot of work behind the scenes over the past few months to migrate the backend storage for builds from the old "FTP" host to S3. While we've tried to make this as seamless as possible, the new system is not a 100% drop-in

Re: APZ enabled on Fennec nightly

Fantastic!!! Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh

Web APIs documentation/evangelism meeting Thursday at 8 AM PST

The Web API documentation community meeting, with representatives from the technical evangelism and the API development teams, will take place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time zone). Typical meetings include news about recent API development progress and

Re: Thunderbird, the future, mozilla-central and comm-central

Hi all As a follow on to Mitchell’s post, I want to outline more specifically how the Foundation got involved and the ways in which I believe the Foundation can assist in this situation. Mitchell and I have had a number of discussions regarding Thunderbird. The Thunderbird Council has also

Re: Using the Taskcluster index to find builds

On 11/30/2015 3:43 PM, Chris AtLee wrote: The RelEng, Cloud Services and Taskcluster teams have been doing a lot of work behind the scenes over the past few months to migrate the backend storage for builds from the old "FTP" host to S3. While we've tried to make this as seamless as possible, the

Re: Thunderbird, the future, mozilla-central and comm-central

Hi all As a follow on to Mitchell’s post, I want to outline more specifically how the Foundation got involved and the ways in which I believe the Foundation can assist in this situation. Mitchell and I have had a number of discussions regarding Thunderbird. The Thunderbird Council has also

Re: Using the Taskcluster index to find builds

On Mon, Nov 30, 2015 at 12:43 PM, Chris AtLee wrote: > The RelEng, Cloud Services and Taskcluster teams have been doing a lot of > work behind the scenes over the past few months to migrate the backend > storage for builds from the old "FTP" host to S3. While we've tried to

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On 11/30/15 4:09 PM, Robert O'Callahan wrote: I think we should just grind through reftest/crashtests and add an explicit flush to every onload/load event handler. There may be mochitests affected too. At least the ones using window screenshots, but possibly some other ones that aim to not

Re: Dan Stillman's concerns about Extension Signing

We have data on pre-signing add-ons that we consider malware, but we have no way of knowing (structurally, besides incidental reports on bugzilla with the malware uploaded) the contents of the XPIs in question and/or whether they would have passed the validator - they wouldn't go through the

Re: Dan Stillman's concerns about Extension Signing

On 28/11/2015 19:42, Dan Stillman wrote: On 11/28/15 5:06 AM, Gijs Kruitbosch wrote: On 27/11/2015 23:46, dstill...@zotero.org wrote: The issue here is that this new system -- specifically, an automated scanner sending extensions to manual review -- has been defended by Jorge's saying, from

Re: Intent to ship/unprefix: Canvas2D imageSmoothingEnabled

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2015 04:34 PM, Florian Scholz wrote: > Hi, > > we intend to ship ctx.imageSmoothingEnabled and add a deprecation > warning for ctx.mozImageSmoothingEnabled. > > This is a Canvas2D context property which controls the > interpolation of

Re: ESLint is now available in the entire tree

Yes. See bug 1150859 and friends. ~ Gijs On 30/11/2015 09:05, Tim Guan-tin Chien wrote: The Gecko JavaScript is also littered with #ifdef and # is really not a token for comment in JS... is there any plan to migrate that away since there is ESLint present? On Sun, Nov 29, 2015 at 10:37 PM,

Re: ESLint is now available in the entire tree

Thanks, bug 1150859 only covers ./browser/. Is this a done deal which we want to get rid of #ifdef in all JS code everywhere? (My particular interest would be obviously ./dom/ and ./b2g/) On Mon, Nov 30, 2015 at 5:44 PM, Gijs Kruitbosch wrote: > Yes. See bug 1150859

Re: Dan Stillman's concerns about Extension Signing

On 2015-11-28 2:06 AM, Gavin Sharp wrote: The assumption that the validator must catch all malicious code for add-on signing to be beneficial is incorrect, and seems to be what's fueling most of this thread. It would be really helpful if we can get past defending the add-on validator; the

Re: Dan Stillman's concerns about Extension Signing

On 2015-11-28 8:28 PM, Mike Hoye wrote: On 2015-11-28 2:40 PM, Eric Rescorla wrote: How odd that your e-mail was in response to mine, then. Thanks, super helpful, really moved the discussion forward, high five. To Ehsan's point that "malicious code here might look like this: