Re: APNG and Accept-Encoding

[Alexander J. Salas B.]

In my last commercial project 2 month ago I used APNG in the iconography of
my Firefox Add-on.

On Tue, Feb 23, 2016, 20:56 Jonas Sicking  wrote:

> On Tue, Feb 23, 2016 at 6:14 AM, Anne van Kesteren 
> wrote:
> > On Tue, Feb 23, 2016 at 12:37 AM, Mike Lawther 
> wrote:
> >> I'm testing the water here :) Is this at all likely to fly?
> >
> > I think the problem with APNG, as opposed to other image formats,
> > e.g., WebP, is that we already support it. If we added APNG to our
> > Accept header now, and developers would start relying on that, users
> > that haven't updated yet or are on Firefox ESR would suddenly get a
> > worse experience in Firefox. That is not a great incentive.
>
> It doesn't seem likely to me that developers would knowingly drop
> support for some set of users that they already support.
>
> It seems much more likely that some set of developers currently don't
> bother supporting APNG in firefox, either because they worry that it's
> a browser-specific dead-end technology, or because they feel that
> there's not enough firefox users that it's worth their time, or
> because it's too much of a pain to support due to lack of Accept
> header.
>
> The question to me is how large this latter group is, and if it's
> large enough that it warrants adding the header.
>
> / Jonas
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CSS Triggers

[Boris Zbarsky]

On 2/23/16 4:18 PM, Jordan Santell wrote:

are there any other suggestions on how we
can observe this data and minimize incorrect results?


In an automated way, or manually?

Because you can look at nsStyleStruct.cpp to figure out what we will do 
in response to various property changes.  Note that it can be a bit 
complicated, in the sense of depending on the old and new value, and 
possibly on the values of other properties.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

CSS Triggers

[Jordan Santell]

Awhile back, Google's Paul Lewis made a page listing all CSS triggers for
Chrome[0], mapping CSS property changes to whether or not they caused
paint, reflow and compositing. We initially had some data for this from the
devtools timeline/profiler on this, and they're going through an effort to
add other browsers' data to the page as well. Right now they're using some
of our outdated marker data, and I'd like to update this and make sure it's
accurate, both for web developers and gecko hackers.

I made an addon[1] that goes through their test suite and spins up our
timeline marker tracker and records what markers we observe when a CSS
property changes. An issue is, the markers seem non-deterministic at times,
like other things could schedule paints or layouts in the future that
results in cluttering up the results, getting series of paint markers when
idling. In lieu of having our markers have the original cause or source
(possibly a good chunk of work), are there any other suggestions on how we
can observe this data and minimize incorrect results?

[0] https://csstriggers.com/
[1] https://github.com/jsantell/gecko-css-triggers
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Updated chaos mode on rr master

[Robert O'Callahan]

Last night I landed some changes to improve chaos mode:
http://robert.ocallahan.org/2016/02/deeper-into-chaos.html

It should be significantly improved. Bugs found in chaos mode before might
take longer to reproduce now, but should still be reproducible. Some bugs
it couldn't find before are now reproducible.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APNG and Accept-Encoding

[Jonas Sicking]

On Tue, Feb 23, 2016 at 6:14 AM, Anne van Kesteren  wrote:
> On Tue, Feb 23, 2016 at 12:37 AM, Mike Lawther  
> wrote:
>> I'm testing the water here :) Is this at all likely to fly?
>
> I think the problem with APNG, as opposed to other image formats,
> e.g., WebP, is that we already support it. If we added APNG to our
> Accept header now, and developers would start relying on that, users
> that haven't updated yet or are on Firefox ESR would suddenly get a
> worse experience in Firefox. That is not a great incentive.

It doesn't seem likely to me that developers would knowingly drop
support for some set of users that they already support.

It seems much more likely that some set of developers currently don't
bother supporting APNG in firefox, either because they worry that it's
a browser-specific dead-end technology, or because they feel that
there's not enough firefox users that it's worth their time, or
because it's too much of a pain to support due to lack of Accept
header.

The question to me is how large this latter group is, and if it's
large enough that it warrants adding the header.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APNG and Accept-Encoding

[maxstepin]

What if, in the future:
1. Safari fully supports  
2. This bug lands https://bugzilla.mozilla.org/show_bug.cgi?id=1160200

Then it would be possible for web-developers to just use this, right?





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APNG and Accept-Encoding

[Xidorn Quan]

On Tue, Feb 23, 2016 at 10:14 PM, Anne van Kesteren  wrote:
> On Tue, Feb 23, 2016 at 12:37 AM, Mike Lawther  
> wrote:
>> I'm testing the water here :) Is this at all likely to fly?
>
> I think the problem with APNG, as opposed to other image formats,
> e.g., WebP, is that we already support it. If we added APNG to our
> Accept header now, and developers would start relying on that, users
> that haven't updated yet or are on Firefox ESR would suddenly get a
> worse experience in Firefox. That is not a great incentive.

If we make the decision now, and make it happen immediately, and
uplift it to Beta 45, we would have the next ESR with this behavior
builtin... FWIW.

I don't know if people would be happy with this, though.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APNG and Accept-Encoding

[Anne van Kesteren]

On Tue, Feb 23, 2016 at 12:37 AM, Mike Lawther  wrote:
> I'm testing the water here :) Is this at all likely to fly?

I think the problem with APNG, as opposed to other image formats,
e.g., WebP, is that we already support it. If we added APNG to our
Accept header now, and developers would start relying on that, users
that haven't updated yet or are on Firefox ESR would suddenly get a
worse experience in Firefox. That is not a great incentive.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: APNG and Accept-Encoding

[Mike Lawther]

[I joined the list and posted this again, I think the previous one got
trapped in moderation]

-- Forwarded message --
From: Mike Lawther 
Date: 19 February 2016 at 17:52
Subject: Re: APNG and Accept-Encoding
To: Jeff Muizelaar 
Cc: Mozilla 


Sorry, I did mean Accept, not Accept-Encoding. My bad - those two always
hash collide in my head for some reason :/

On 19 February 2016 at 01:45, Jeff Muizelaar  wrote:

> Is there a response to the criticism of Accept outlined here:
> https://wiki.whatwg.org/wiki/Why_not_conneg#Negotiating_by_format
>
>
A lot of the criticism there is essentially 'you can't rely on it, because
not everybody sends it'.

It's a fair question. And it's a large reason why I'm asking the question I
did :) If we can coordinate on this then it becomes more reliable.

Our experience with WebP and things such as data compression proxies is
that it does get used. In this use case, the end user gets identical
behaviour, but it has cost them less in network bandwidth. The CDN use case
is similar. The data cost reduction is significant in a lot of markets. And
in these use cases, it doesn't matter if the header is not sent by every
browser. The users of ones that do get a benefit.

I'm testing the water here :) Is this at all likely to fly?

thanks,

mike


> -Jeff
>
> On Wed, Feb 17, 2016 at 6:08 PM, Mike Lawther 
> wrote:
> > Hi Mozilla developers!
> >
> > tl,dr; can Firefox send an Accept-Encoding heading for APNG?
> >
> > I'm an engineer at Google working on Chrome. We're considering support
> for
> > APNG.
> >
> > To support APNG, we think it's important for web developers (including
> for
> > example CDN operators) to be able to decide server-side what content to
> > ship. We want to send an Accept-Encoding header. This would be for
> whatever
> > MIME type APNG ends up with, but that's another topic. The latest I've
> seen
> > on this is "vnd.mozilla.apng" (https://bugzilla.mozilla.org/
> > show_bug.cgi?id=1160200).
> >
> > If Chrome does decide to support APNG, it would be ideal for both our
> > browsers to be compatible in this respect as well.
> >
> > Is this something we can coordinate on?
> >
> > thanks,
> >
> > Mike Lawther
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Generic Task Cluster Tasks / File Based Task Scheduling

[Henrik Skupin]

Gregory Szorc wrote on 02/17/2016 07:59 PM:

> * You can now define tasks that are neither "build" nor "test" tasks. This
> mechanism is probably where you should place one-off tasks such as linting,
> docs generation, code analysis, etc. See
> https://hg.mozilla.org/integration/mozilla-inbound/rev/623765c2381e for
> more on this feature.

This is great. Something else which comes into my mind while reading
your email is if we could reduce the turnaround time e.g. for try builds
in case such a build only contains test changes and wouldn't need a new
binary to be produced.

Not sure if that would work but if we could grab an already existent
binary from the inbound changeset the try push is based off, a lot of
machine power could be saved (compile time vs. download time).

-- 
Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform