Re: APNG and Accept-Encoding
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
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
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
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
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
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
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
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
[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
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