As of today (Oct 7, 2016) we intend to turn on support for unprefixed css
multi-column properties by default on all platforms. For now, we'll be
continuing to support the prefixed versions as aliases, and we intend to remove
these aliases in the near future (assuming web-compatibilty allows for
On 07-10-16 20:47, Daniel Holbert wrote:
> On 10/07/2016 12:49 AM, Gian-Carlo Pascutto wrote:
>> This behavior can be controlled via a pref:
>> pref("security.sandbox.content.level", 2);
>>
>> Reverting this to 1 goes back to the previous behavior
>
> Warning: don't actually try to revert this to
On 10/07/2016 12:49 AM, Gian-Carlo Pascutto wrote:
> This behavior can be controlled via a pref:
> pref("security.sandbox.content.level", 2);
>
> Reverting this to 1 goes back to the previous behavior
Warning: don't actually try to revert this to 1, just yet -- at the
moment, that triggers startu
No evidence either way. Given we've had non-compat parameter defaults for a
while, your worry is legit. We'll deal with web compat issues with JS as it
comes up -- unfortunately the reality is that until we ship something, we
have very little idea if it's breaking.
On Fri, Oct 7, 2016 at 8:14 AM,
On 2016-10-07 8:01 AM, Tom Schuster wrote:
> To simplify parsing ES 2016 disallows "use strict" in functions with
> non-simple parameters, like defaults or rest.
>
> For example `function f(a = 1) { "use strict"; }` is going to start
> throwing.
>
> Chrome, JSC and Edge already made this change.
Thanks Morris!
As far as I know, no other engine has shipped this feature, is that correct?
On 2016-10-07 3:34 AM, Morris Tseng wrote:
> In bug 1172796, we shipped ImageBitmapRenderingContext accidentally. Due to
> spec change very rapidly. We would like to unship this feature until the
> spec is
To simplify parsing ES 2016 disallows "use strict" in functions with
non-simple parameters, like defaults or rest.
For example `function f(a = 1) { "use strict"; }` is going to start
throwing.
Chrome, JSC and Edge already made this change.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=127278
On Wednesday, 30 March 2016 04:08:45 UTC+8, Emma Humphries wrote:
> tl;dr
>
> In Quarter Two I'm implementing the work we’ve been doing to improve
> triage, make actionable decisions on new bugs, and prevent us from shipping
> regressions in Firefox.
>
> Today I’m asking for feedback on the plan
Never mind--file:// only does reads.
Haven't had my coffee yet this morning :)
Jason
On Fri, Oct 7, 2016 at 10:13 AM, Jason Duell wrote:
> It sounds like this is going to break all file:// URI accesses until we
> finish implementing e10s support for them:
>
> https://bugzilla.mozilla.org/sho
It sounds like this is going to break all file:// URI accesses until we
finish implementing e10s support for them:
https://bugzilla.mozilla.org/show_bug.cgi?id=922481
That may be more bustage on nightly than is acceptable?
Jason
On Fri, Oct 7, 2016 at 9:49 AM, Gian-Carlo Pascutto wrote:
>
Hi all,
the next Nightly build will have a significantly tightened Linux
sandbox. Writes are no longer allowed except to shared memory (for IPC),
and to the system TMPDIR (and we're eventually going to get rid of the
latter, perhaps with an intermediate step to a Firefox-content-specific
tmpdir).
In bug 1172796, we shipped ImageBitmapRenderingContext accidentally. Due to
spec change very rapidly. We would like to unship this feature until the
spec is ready. But unship a shipped feature is quite risky. So the unship
process is incremental and as follow:
1) In bug 1304767, we'll follow the l
12 matches
Mail list logo
