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 tr
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
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
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
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
fu
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 make
> this as seamles
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 j
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 Thunderbird
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 this for a while, I haven't
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 hneires
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
replacement
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. It
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 w
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 sho
On 11/30/15 6:24 AM, Gijs Kruitbosch wrote:
On 28/11/2015 19:42, Dan Stillman wrote:
As for what, if anything, should block release without override, I'm
happy to talk specifics, but we can't have a discussion about that
without even agreeing on the point of the validator,
Why do we have to ag
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
That sounds like a good idea to me as well.
On 2015-11-30 11:25 AM, Gavin Sharp wrote:
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
Also https://bugzilla.mozilla.org/show_bug.cgi?id=1227867
On 30/11/15 20:31, Bobby Holley wrote:
> (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
(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 do
I've additionally filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1229106 to get an
ESLint-powered mozreviewbot[1] written.
[1]: An automated reviewing bot that bug 1196263 added infrastructure for.
On 30/11/2015 2:13 PM, Dave Townsend wrote:
> Over in https://bugzilla.mozilla.org/show_bug.cgi
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 mi
Over in https://bugzilla.mozilla.org/show_bug.cgi?id=1229097 I'm
proposing a default set of rules that browser and toolkit code should
aspire to. It's based on flagging obvious mistakes and things that
will confuse and then following what I've seen to be the rough
consensus coding style we use.
It
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 t
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 tran
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
> support running, t
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 crashte
On Mon, Nov 30, 2015 at 6:34 AM, Tim Guan-tin Chien
wrote:
> 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/)
>
Make this happen! Fennec (mobile/and
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 browser-specific code paths out ther
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 belo
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 ifram
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 th
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 the add-on signing syst
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 bu
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 projec
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.
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 non-Basic
> 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 e
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
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 _impossible_ (and per
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
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:
console.log("succ
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 only
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 and friends.
>
> ~ Gijs
>
>
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 Mar
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 va
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 o
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 delay
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, Viv
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:
http://eslint.org/docs/user-guide/configuri
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 wrote:
>
> > Hi,
> >
>
-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 image
51 matches
Mail list logo
