On 8/8/18 12:43 PM, Chris Pearce wrote:
Hi Jib,
I appreciate that you care passionately about our users' best interests.
Seeing as you asked "why don't you just?"... Here's why we "didn't just"...
On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
On 8/6/18 4:03 PM, Jan-
On 8/7/18 6:16 PM, Jonathan Watt wrote:
Spec: None. We're reverse engineering Chrome and ignoring
https://drafts.csswg.org/css-ui-4/#appearance-switching
since the 'appearance' property defined there is not
web compatible.
Are we writing down something that could get turned
In early July, we added --enable-nodejs as an optional feature to
configure. This was a first step towards being able to use Node-based
JavaScript and CSS tooling (e.g. Babel, PostCSS, bundlers like Webpack,
etc.) as part of the regular build process. We plan to set --enable-nodejs
as the default o
On 8/8/18 12:53 PM, Boris Zbarsky wrote:
On 8/8/18 12:43 PM, Chris Pearce wrote:
On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
To clarify, I care about Netflix, which is why I question giving up on
persisting autoplay for them, which is what allowedToPlay does.
So I
On Wednesday, August 8, 2018 at 9:54:06 AM UTC-7, Boris Zbarsky wrote:
> On 8/8/18 12:43 PM, Chris Pearce wrote:
> > On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
> >> To clarify, I care about Netflix, which is why I question giving up on
> >> persisting autoplay for them
On 8/8/18 1:00 PM, Chris Pearce wrote:
Google weren't keen on that idea as it doesn't map well to their implicit MEI
method.
Right, that's the "hard problem" bit.
Feels like we should maybe be able to find non-Google allies here,
especially if we have some weasel-wording in the spec about ho
On 8/8/18 12:43 PM, Chris Pearce wrote:
On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
To clarify, I care about Netflix, which is why I question giving up on
persisting autoplay for them, which is what allowedToPlay does.
So I have a question. Would it be at all usef
Hi Jib,
I appreciate that you care passionately about our users' best interests.
Seeing as you asked "why don't you just?"... Here's why we "didn't just"...
On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
> On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote:
> > On 8/1/18 3:36 A
The first iteration of our commit-series-friendly Arcanist wrapper is ready
for use. At this time, it only supports Mercurial (without mq) and doesn't
yet support Windows, but we wanted to get what we have out in front of
users. We are continuing work on Windows support (
https://bugzilla.mozilla.o
Hi Jonathan,
On 8/7/18 5:16 PM, Jonathan Watt wrote:
Summary
---
I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to
turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref
simultaneously changes the behavior of the 'menulist-button' value, and short
On Wed, Aug 8, 2018 at 9:50 AM, Dirkjan Ochtman wrote:
> A related question: is there some place where I can follow along with plans
> relating to Rust upgrades for mozilla-central? As a Linux distribution
> packager, that might be useful information. (I remember seeing there was a
> Rust upgrade
On Wed, Aug 8, 2018 at 3:44 PM Nathan Froyd wrote:
> Given Rust's compatibility guarantees, you may be able to build ESR
> with later Rust releases, but your best bet is using the specific Rust
> version that we're using.
>
A related question: is there some place where I can follow along with pl
On Wed, Aug 8, 2018 at 7:07 AM, wrote:
> What is plan for future Firefox ESR versions? Will ESR version require for
> build new Rust versions as they are releasing or will it stay on version on
> which was required for first ESR revision?
The plan is to keep the ESR versions on the Rust versio
Hi,
What is plan for future Firefox ESR versions? Will ESR version require for
build new Rust versions as they are releasing or will it stay on version on
which was required for first ESR revision?
Thanks,
Petr
___
dev-platform mailing list
dev-platf
14 matches
Mail list logo