I'm glad to know that people are using Triage Center!
Pull requests would be gratefully accepted, and if you don't have time, if
you want to point me at relevant APIs and give me a spec for what you need,
I can see what I can do, or recruit helpers.
-- Emma
On Fri, Feb 10, 2017 at 7:40 PM, Brian
On Fri, Feb 10, 2017 at 8:37 PM, James Graham wrote:
>> Should we be requiring people to update the MANIFEST.json whenever
>> they touch a file in testing/web-platform/tests (i.e. not just when
>> they add/remove files)?
>
>
> This is too much to ask of people; it was effectively required when the
On 2/10/17 8:03 PM, Mats Palmgren wrote:
I'm guessing Firefox add-ons might not bother with anything but
-moz-appearance though, but I assume those counts as chrome sheets,
so the property will continue to work there as before. (Please correct me
if I'm wrong about that.)
"Chrome sheets", for
On Fri, Feb 10, 2017 at 8:04 PM, James Graham wrote:
> I don't know what triage-center is, but increasing the visibility of
> failures in web-platform-tests is certainly something that I think I should
> work on; we are currently letting compat problems slip through
> unnecessarily. If there is a
On 02/11/2017 12:28 AM, Justin Dolske wrote:
Do we have any data on existing content usage of -moz-appearance? Or
is this a "ship it and see what breaks" kind of thing?
I'm not aware of any data that would be useful here. Data on how often
-moz-appearance is used isn't very useful since it doe
在 2017/2/11 2:26, t...@ritter.vg 写道:
On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote:
I thought I enumerated the harm at first, but I'll elaborate a little.
1) Flash doesn't know about and breaks our "current and subdirectory only"
file: origin policy.
2) Flash is a high
在 2017/2/10 22:34, Benjamin Smedberg 写道:
On Fri, Feb 10, 2017 at 12:36 AM, 段垚 wrote:
在 2017/2/10 1:28, Benjamin Smedberg 写道:
On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote:
Is this just preventing auto-loading (like "click to play") or completely
disable Flash for non-http(s) contents?
This
Do we have any data on existing content usage of -moz-appearance? Or is
this a "ship it and see what breaks" kind of thing?
I have the vague recollection that this is something that might have
non-trivial usage (especially and specifically "-moz-appearance: none"), so
just want to make sure that's
Awesome news! Building Quantum Render in mozilla-central and running
even a subset of our regular tests is a big step towards shipping.
chris
On 2/10/2017 1:11 PM, Kartikaya Gupta wrote:
(cross-posted to dev-platform and dev-tech-gfx)
This is just a heads up that earlier today we merged the
Makes sense Mats, exactly as you divided it up. Thanks for pushing this.
Note: the 'appearance' property was previously in a CSS3 UI CR:
* https://www.w3.org/TR/2004/CR-css3-ui-20040511/#appearance
Where it was stable for nearly 8 years but dropped subsequently due to
lack of interop (actual diver
Summary: add support for the CSS UI property 'appearance:none | auto' with
'-webkit-appearance' as an alias. Unship '-moz-appearance'.
'appearance:none' works exactly as '-moz-appearance:none' -- it turns off
the native theme for elements that have one. 'appearance:auto' (the
initial value)
On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic wrote:
> First step needs to happen completely before the second step does, so I
> guess the danger is that we start and give up before we get to step 2. I
> don't think that will happen, but it is something we should always think
> about.
It may
Reducing overflow risk and simplifying intersection both seem worth
it, but godspeed whoever works on this!
On Fri, Feb 10, 2017 at 12:45 PM, Milan Sreckovic
wrote:
> First step needs to happen completely before the second step does, so I
> guess the danger is that we start and give up before we
(cross-posted to dev-platform and dev-tech-gfx)
This is just a heads up that earlier today we merged the graphics
branch to m-c, so Quantum Render builds can now be done on central if
you put --enable-webrender in your mozconfig.
We will be running a limited set of builds (linux64 only) and tests
First step needs to happen completely before the second step does, so I
guess the danger is that we start and give up before we get to step 2.
I don't think that will happen, but it is something we should always
think about.
Third step - sure, I can see this not getting completed - examining
On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote:
> I thought I enumerated the harm at first, but I'll elaborate a little.
>
> 1) Flash doesn't know about and breaks our "current and subdirectory only"
> file: origin policy.
>
> 2) Flash is a high-risk attack surface: if you c
We've updated the minimum-required rust version for mozilla-central to 1.15.1.
This version just reached the stable channel, so you'll need to update
your build environment. You should be able to do this just by typing:
rustup update stable
If you don't have rustup, you can get it by running `
There's good feedback in here. Are some of these known, jmaher? Are any
intentional choices, or should we just start turning these into bugs to
get fixed?
On 08/02/2017 12:33 AM, Bill McCloskey wrote:
> Hi Joel,
> I spent about an hour tonight trying to debug a test failure, and I'm
> writing this
On Fri, Feb 10, 2017 at 12:36 AM, 段垚 wrote:
>
> 在 2017/2/10 1:28, Benjamin Smedberg 写道:
>
>> On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote:
>>
>> Is this just preventing auto-loading (like "click to play") or completely
>>> disable Flash for non-http(s) contents?
>>>
>>> This is completely disabling
I thought I enumerated the harm at first, but I'll elaborate a little.
1) Flash doesn't know about and breaks our "current and subdirectory only"
file: origin policy.
2) Flash is a high-risk attack surface: if you can get somebody to download
a SWF they can probably own your system. We don't have
On 10/02/17 06:27, Brian Birtles wrote:
Hi,
It seems like the MANIFEST.json for web platform tests now includes a
checksum of test file contents. As a result, if you run './mach
web-platform-tests --manifest-update yer' on a clean checkout of m-c
you're likely to get a bunch of changes to MANIFE
On 10/02/17 06:34, Brian Birtles wrote:
I don't expect James to file bugs for all the new failures he
encounters when syncing (and I suspect if he did, many of them would
end up being marked invalid/duplicate because they're features we
don't implement yet), but is there somewhere we can get a re
On 10.02.2017 01:09, Xidorn Quan wrote:
> On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:
>> Will this also prevent loading downloaded .swf files into Firefox? This
>> is
>>> useful for running Flash games, which tend to work best in the browser
>>> (some media players also support load
Summary:
Adds a new event that fires when an animation is terminated without
finishing normally (e.g. element is made display:none, animation-name
property is updated etc.). This parallels the recently added
transitioncancel event and allows authors to know that they should not
keep waiting for an
24 matches
Mail list logo
