Re: Proposed W3C Charter: Web Payments Working Group

On Fri, Feb 2, 2018 at 11:40 AM, Peter Saint-Andre wrote: > On 2/2/18 11:57 AM, Anne van Kesteren wrote: >> On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre >> wrote: >>> What you have seems fine (modulo s/Web Auth/Web Authentcation/). The >>> first

Re: New prefs parser has landed

On 2/2/18 4:57 PM, Nicholas Nethercote wrote: It shouldn't be too hard, because the prefs grammar is very simple. I would just implement "panic mode" recovery, which scans for a synchronizing token like ';' or 'pref' and then continues from there. OK. I think that would address my concerns,

Re: New prefs parser has landed

On Sat, Feb 3, 2018 at 12:42 AM, Boris Zbarsky wrote: > > Perhaps I should implement error recovery, so that ill-formed prefs won't >> cause subsequent prefs to be lost. >> > > You mean pick up parsing again after hitting an error? That sounds > complicated... > It shouldn't

Re: Intent to ship: Array.prototype.values

On 02/02/2018 03:27 PM, Andrew Overholt wrote: > On Fri, Feb 2, 2018 at 8:45 AM, Tom Schuster > wrote: > > Chrome seems to > want to add a kill pref for this,  from my experience more difficult > for us with the way we define methods in

Re: Proposed W3C Charter: Web Payments Working Group

On 2/2/18 11:57 AM, Anne van Kesteren wrote: > On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre wrote: >> What you have seems fine (modulo s/Web Auth/Web Authentcation/). The >> first comment is just housekeeping, whereas the second comment is >> substantive and concerning.

Re: Proposed W3C Charter: Web Payments Working Group

On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre wrote: > What you have seems fine (modulo s/Web Auth/Web Authentcation/). The > first comment is just housekeeping, whereas the second comment is > substantive and concerning. Phrasing it as a formal objection might > result

Re: Faster gecko builds with IceCC on Mac and Linux

Hi > On 17 Jan 2018, at 12:38 am, Gregory Szorc wrote: > > On an EC2 c5.17xlarge (36+36 CPUs) running Ubuntu 17.10 and using Clang 5.0, > 9be7249e74fd does a clobber but configured `mach build` in 7:34. Rust is very > obviously the long pole in this build, with C++

Re: Proposed W3C Charter: Web Payments Working Group

On 2/2/18 1:25 AM, L. David Baron wrote: > On Thursday 2018-01-18 19:05 -0700, Peter Saint-Andre wrote: >> On 1/8/18 10:17 PM, mcace...@mozilla.com wrote: >>> >>> On Jan 9, 2018, at 4:29 AM, L. David Baron wrote: Please reply to this thread if you think there's

Re: Intent to ship: Array.prototype.values

I talked to Jan de Mooij and it's feasible to add a pref for this, so we are definitely going to do this. Array.prototype.values has always been enabled on Nightly. Based on where the breakage occurred, internal company webpages, I would not expect EARLY_BETA_OR_EARLIER to shake out any

Re: Intent to ship: Array.prototype.values

On Feb 2, 2018, at 7:45 AM, Tom Schuster wrote: > Any additional ideas how to mitigate the risk here? Chrome seems to > want to add a kill pref for this, from my experience more difficult > for us with the way we define methods in SpiderMonkey. Should that be > a requirement

Re: Intent to Unship: Application Cache over Insecure Contexts

This has now landed into central and appears to be sticking: https://www.fxsitecompat.com/en-CA/docs/2018/support-for-application-cache-on-insecure-sites-has-been-deprecated/ I have filed a follow up bug to remove "OfflineResourceList" interface we use:

Re: Intent to ship: Array.prototype.values

On Fri, Feb 2, 2018 at 2:45 PM, Tom Schuster wrote: > Any additional ideas how to mitigate the risk here? Chrome seems to > want to add a kill pref for this, from my experience more difficult > for us with the way we define methods in SpiderMonkey. Should that be > a

Re: Intent to ship: Array.prototype.values

On 2/2/18 8:45 AM, Tom Schuster wrote: Should that be a requirement for shipping? Imo, yes, given the history of trying to ship this in the past (had to be backed out for web compat fail twice, etc). -Boris ___ dev-platform mailing list

Re: Intent to ship: Array.prototype.values

On Fri, Feb 2, 2018 at 8:45 AM, Tom Schuster wrote: > Chrome seems to > want to add a kill pref for this, from my experience more difficult > for us with the way we define methods in SpiderMonkey. Should that be > a requirement for shipping? > If it's not too difficult it

Re: Ci, Cr, Cc, and Cu are now automatically defined in all chrome scopes

That's... brilliant. How did it take this many years for that to come up? :) Sheppy On Thu, Feb 1, 2018 at 5:11 PM, Andrew McCreight wrote: > Bug 767640 just merged to mozilla-central. This patch makes it so that Ci, > Cr, Cc, and Cu are automatically defined in any

Re: New prefs parser has landed

Pretty complicated in the general case but might be simple in the case of number overflow. Also, while we shouldn't depend on the UI in libpref, could we send some kind of event or observer notification that the UI could use to display a detailed error message? It would be a shame if Firefox was

Intent to ship: Array.prototype.values

We already tried to ship Array.prototype.values before in Firefox 48, but this broke Microsoft Dynamics CRM 2011 (https://bugzilla.mozilla.org/show_bug.cgi?id=1299593). We are however aware this might have caused other breakages as well. The compatibility risk for this change is high. However

Re: New prefs parser has landed

On 2/1/18 10:27 PM, Nicholas Nethercote wrote: On Fri, Feb 2, 2018 at 12:50 PM, Boris Zbarsky wrote: OK. I assume we've double-checked that? And that this was the case all along, for prefs extensions or about:config might have set in the past? (Especially the

Re: Ci, Cr, Cc, and Cu are now automatically defined in all chrome scopes

On Thu, Feb 1, 2018, at 5:11 PM, Andrew McCreight wrote: > Bug 767640 just merged to mozilla-central. This patch makes it so that Ci, > Cr, Cc, and Cu are automatically defined in any chrome scope that has a > Components object. Rejoice, because you no longer need to add "var Ci = >

Re: PSA: Changes to JSM import APIs (or, Death to Cu.import)

On Fri, Feb 02, 2018 at 10:25:17AM +0100, Marco Bonardo wrote: Hi Kris, this change is awesome. Is it ok to continue use defineLazyModuleGetters (plural), since it internally now uses chromeUtils.defineModuleGetter? Any downsides? It's probably fine for now. There is a downside, though, when

Re: PSA: HTML injection in chrome documents is now automatically sanitized

FWIW, if you're running into this with the usecase "I have a localized string that needs to have links (or other markup) in it" and were formerly using getFormattedString combined with innerHTML, we now have a utility method that can help a little bit. Rather than hand-rolling splitting the

Re: PSA: HTML injection in chrome documents is now automatically sanitized

I don't think these rewrites fit the definition of a good first bug. I'm all for working with volunteers on this, since these are good isolated, non-time-sensitive projects to tackle, but I can't think of an innerHTML example in our codebase that matches the low difficulty we usually apply to

Re: PSA: Changes to JSM import APIs (or, Death to Cu.import)

Hi Kris, this change is awesome. Is it ok to continue use defineLazyModuleGetters (plural), since it internally now uses chromeUtils.defineModuleGetter? Any downsides? On Fri, Feb 2, 2018 at 7:48 AM, Ed Lee wrote: > Great to see these types of broad changes getting wins, so

Re: PSA: HTML injection in chrome documents is now automatically sanitized

Now would be a great time to file good first bugs. New contributors could rewrite innerHTML and friends into code that uses safer alternatives. On 02.02.2018 08:13, Kris Maglione wrote: > As of bug 1432966, any HTML injected into chrome-privileged documents[1] > is automatically sanitized to

Re: Proposed W3C Charter: Web Payments Working Group

On Thursday 2018-01-18 19:05 -0700, Peter Saint-Andre wrote: > On 1/8/18 10:17 PM, mcace...@mozilla.com wrote: > > > > > >> On Jan 9, 2018, at 4:29 AM, L. David Baron wrote: > >> > >> Please reply to this thread if you think there's something we should > >> say as part of

Re: Intent to Ship - Support already-enrolled U2F devices with Google Accounts for Web Authentication

On Tue, Jan 30, 2018 at 6:49 PM, J.C. Jones wrote: > I also recognize that Google > Accounts is the largest player in existing U2F device enrollments. ... > If we choose not to do this, Google Accounts users who currently have U2F > enabled will not be able to authenticate using