Re: [webkit-dev] Upstreaming Tests from WebKit to Web Platform Tests

On Mon, Feb 6, 2017 at 7:32 PM Ryosuke Niwa wrote: > On Mon, Feb 6, 2017 at 4:22 PM, youenn fablet wrote: > > It seems we agree in moving this forward. Any objection? > If so, let's start with small practical steps, something like a script to > automatically

Re: [webkit-dev] Upstreaming Tests from WebKit to Web Platform Tests

FWIW, in Blink we stopped rewriting the testharness.js paths before switching to wptserve, by instead rewriting those URLs only when running LayoutTests:

Re: [webkit-dev] WPT tests and runtime-enabled features

FWIW, in Chromium, if we had an off-by-default feature that we wanted to test using wpt, we would probably use the https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/VirtualTestSuites mechanism. On Sat, Jun 3, 2017 at 1:03 AM, youenn fablet wrote: > Hi Ali, >

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

On Tue, Nov 28, 2017 at 3:37 PM Ryosuke Niwa <rn...@webkit.org> wrote: > On Mon, Nov 27, 2017 at 5:58 PM, Philip Jägenstedt <foo...@chromium.org> > wrote: > >> (From Nov 24, I used the wrong email, resending for the archives.) >> >> On Sat, Nov 1

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

On Fri, Nov 17, 2017 at 5:23 PM, Maciej Stachowiak wrote: > > >> On Nov 17, 2017, at 7:53 AM, Frédéric WANG wrote: >> >> On 17/11/2017 16:26, Maciej Stachowiak wrote: >>> WebKit has a lot of tests that were regression tests for a specific >>> bug fix, not as

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

(From Nov 24, I used the wrong email, resending for the archives.) On Sat, Nov 18, 2017 at 8:02 AM, youenn fablet wrote: > Thanks for taking the time to share this additional information. > I think this is helpful to make progress. > Please see inline for some more comments

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

erTreeAsText (tests in the > compositing layer) > - 3b) tests that dump render object tree (testing browser internals) > > > Thanks, > Danyao > > On Wed, Nov 15, 2017 at 5:02 AM, Philip Jägenstedt <foo...@chromium.org> > wrote: > >> Hello webkit-dev

[webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

Hello webkit-dev! (ecosystem-infra in Bcc) TPAC was last week, and there was much talk about web-platform-tests. Some notes are at https://lists.w3.org/Archives/Public/public-test-infra/2017OctDec/thread.html and in particular https://www.w3.org/2017/11/07-testing-minutes.html. In Blink, we're

Re: [webkit-dev] Editing WPT tests in a WebKit checkout

On Sun, Oct 15, 2017 at 2:39 PM, youenn fablet wrote: > Hi, > > I am working on a script [1] to easily export edits made to WPT tests from a > local WebKit checkout into GitHub. > The procedure would be something like: > 1. Develop a WebKit patch > 2. As part of step 1,

Re: [webkit-dev] Standard process for exporting new WPT tests?

On Wed, May 23, 2018, 23:43 youenn fablet wrote: > Le mer. 23 mai 2018 à 14:11, Frédéric Wang a écrit : > >> On 23/05/2018 22:50, Ryosuke Niwa wrote: >> > As we have preciously discussed, we should NEVER commit new tests into >> >

Re: [webkit-dev] Standard process for exporting new WPT tests?

On Thu, May 24, 2018, 21:40 youenn fablet wrote: > > >>> Ryosuke, correct me if I am wrong, I think you are pointing out the >>> following rule: >>> Changes to LayoutTests/imported/w3c/web-platform-tests tests should land >>> first in WPT repository, then in WebKit repository.

Re: [webkit-dev] Standard process for exporting new WPT tests?

On Fri, May 25, 2018, 00:52 Ryosuke Niwa <rn...@webkit.org> wrote: > > On Thu, May 24, 2018 at 3:22 AM, Philip Jägenstedt <foo...@chromium.org> > wrote: > >> On Wed, May 23, 2018, 23:43 youenn fablet <youe...@gmail.com> wrote: >> >>> Le mer. 2

Re: [webkit-dev] Standard process for exporting new WPT tests?

On Fri, May 25, 2018 at 6:09 PM youenn fablet wrote: > > However, one thing I really like about your order is that it makes it more >> straightforward to make WPT repo failures block browser repo merging. In >> the WPT Travis job, we already detect flakiness for Chrome and Firefox and >> I think

Re: [webkit-dev] WebKit support in web-platform-tests

Thanks for your work on this, Žan! That PR is now up at https://github.com/w3c/web-platform-tests/pull/9666 and in it I linked to https://github.com/w3c/web-platform-tests/pull/8979, which is a PR I updated last week to support Safari, including Technology Review. I wish I'd payed closer

Re: [webkit-dev] Huge improvement in Safari results on wpt.fyi

talled (weird to special case one font, but > probably ok) > > Dean > > > On 12 Oct 2018, at 03:26, Philip Jägenstedt wrote: > > > > Alright, I've written a one-off script [1] to find the Safari-only > > failures, and here's the output: > > https://gist.githu

Re: [webkit-dev] Huge improvement in Safari results on wpt.fyi

On Fri, Oct 12, 2018 at 4:07 PM Geoffrey Sneddon wrote: > > On Fri, Oct 12, 2018 at 4:23 AM Emilio Cobos Álvarez wrote: > > > > On 10/12/18 3:59 AM, Geoffrey Garen wrote: > > > Honest question: What’s gross about using @font-face? > > > > > > It would be lots of test edits. That’s a bummer. > >

Re: [webkit-dev] Huge improvement in Safari results on wpt.fyi

t; - R. Niwa > > On Tue, Oct 2, 2018 at 3:45 AM Philip Jägenstedt wrote: >> >> Hi WebKittens, >> >> Fresh off the bots, I'm excited to report more robust Safari results, >> and that Safari WPT pass rates are clearly improving! Thanks to the >> hard work of Mike

[webkit-dev] Huge improvement in Safari results on wpt.fyi

Hi WebKittens, Fresh off the bots, I'm excited to report more robust Safari results, and that Safari WPT pass rates are clearly improving! Thanks to the hard work of Mike Pennisi [1] we now have the first Safari 12 results: https://wpt.fyi/results/?sha=ee2e69bfb1=safari-12.0 This uses the same

Re: [webkit-dev] Filtering results on wpt.fyi, Safari-specific failures

On Fri, Mar 29, 2019 at 6:16 PM Robert Ma wrote: > On Mon, Feb 25, 2019 at 8:49 AM Philip Jägenstedt > wrote: > >> I'd like to point out right away that diagnosing reftest failures is >> currently cumbersome because we don't store the screenshots. This is >> also a wo

Re: [webkit-dev] Filtering results on wpt.fyi, Safari-specific failures

roblem, or dubious tests that > don’t actually test the standard. > > Regards, > Maciej > > On Feb 25, 2019, at 5:48 AM, Philip Jägenstedt > wrote: > > I'd like to point out right away that diagnosing reftest failures is > currently cumbersome because we don't st

[webkit-dev] Filtering results on wpt.fyi, Safari-specific failures

Hi all, Following the improved Safari results last year [1] and the discussion that generated, I'm happy to announce that the filtering requested as now available in the search box. The full syntax is documented [2] but there's also a new insights view [3] with some useful searches. Especially

Re: [webkit-dev] Filtering results on wpt.fyi, Safari-specific failures

recommend ignoring reftest failures if the cause of failure isn't obvious. On Mon, Feb 25, 2019 at 2:30 PM Philip Jägenstedt wrote: > > Hi all, > > Following the improved Safari results last year [1] and the discussion > that generated, I'm happy to announce that the filtering req

Re: [webkit-dev] Remove SVGTests.hasExtension?

FWIW, here's the original intent to remove it from Chromium: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Ae_lmov16_o/Wa5XhHFoAAAJ We had use counters, and I wrote "Usage is zero for all of them." When concerned about usage in the wild, the tool we usually use for Chromium is

Re: [webkit-dev] Safari Tech Preview 96 available on wpt.fyi!

On Tue, Dec 3, 2019 at 3:05 AM Jiewen Tan wrote: > Hi Maciej, > > On Dec 2, 2019, at 4:10 PM, Maciej Stachowiak wrote: > > > There’s a number of mysterious timeouts with 96. Not sure if flakiness or > real? > > The new WebCrypto failures are surprising, but likely real and should be >

Re: [webkit-dev] WPT at the WebKit Contributors Meeting

Thanks Ryosuke, this was definitely a worthwhile trip for me! I was especially encouraged to see that the focus on engine-specific tests resonated and in fact that there was already work in motion to look into it. While smoother import/export wasn't a big topic and not seen as urgent by anyone on

Re: [webkit-dev] Position on emerging standard: video.requestAnimationFrame()

Hi Simon, Naming is hard as usual and was discussed on https://github.com/w3ctag/design-reviews/issues/429, where you've already commented. Is there a pair of names that you think would work better here? onFrameAvailable() would IMHO be quite unidiomatic, the web platform doesn't have any other