Re: [webkit-dev] Request for position on WebRTC Insertable Streams

2020-08-18 Thread youenn fablet
Hi Guido,

The use cases addressed by this proposal seem useful.
I am particularly excited about providing support for WebRTC
end-to-end encryption and hope insertable streams can serve as a basis
for that.
The end-to-end encryption use case would probably best be served by a
native implementation of the crypto parts, for instance using SFrame.

As discussed within the WebRTC WG, the current specification is a
starting point.
It is thus early to provide an assessment, especially given a few
issues that have been filed (ability to define native nodes for
instance as TransformStream in addition to full JS nodes,
off-the-main-thread processing by default) should be dealt with.

Le ven. 14 août 2020 à 13:49, Guido Urdaneta  a écrit :
>
> Hello WebKit-dev,
>
> I'd like to ask for an official position on WebRTC Insertable Streams.
>
> Specification: https://w3c.github.io/webrtc-insertable-streams/
> Explainer: 
> https://github.com/w3c/webrtc-insertable-streams/blob/master/explainer.md
> Chromestatus entry: https://www.chromestatus.com/feature/6321945865879552
> Github repo: https://github.com/w3c/webrtc-insertable-streams
> WG presentation: https://youtu.be/YGYlzlKFpXA?t=1047
>
> Thanks,
> Guido Urdaneta
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position on MediaRecorder constant bitrate audio encoding

2020-08-03 Thread youenn fablet
Hi Simon,

I think CBR for MediaRecorder is fine. It also got consensus within
the WebRTC WG.

Le ven. 31 juil. 2020 à 10:53, Simon Jackson
 a écrit :
>
> Hello WebKit-dev,
>
> I'd like to ask for Webkit's official position on a change to the editors 
> draft of the mediacapture-record specification to make it possible to request 
> either constant or variable bitrate audio encoding from the MediaRecorder.
>
> Specification: https://w3c.github.io/mediacapture-record/#mediarecorder-api
> Pull request & discussion of additions: w3c/mediacapture-record#185
> Explainer: 
> https://docs.google.com/document/d/10OheBob6lP7v-fO89g0A5F9BYnsMEU5Nkh4p-Bk0wMg/edit?usp=sharing
> Chromestatus entry: https://chromestatus.com/feature/5730124735447040
>
> A new enumeration (BitrateMode) has been added for specifying either constant 
> or variable bitrate for audio encoding, MediaRecorderOptions has an extra 
> field called audioBitrateMode for requesting a specific bitrate mode from the 
> MediaRecorder and a field was added to MediaRecorder for retrieving the 
> bitrate mode being used for encoding.
>
>
> Thanks,
>
> Simon
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Can we remove ENABLE_STREAMS_API compile flag?

2020-06-19 Thread youenn fablet
This would be a nice simplification.

Le ven. 19 juin 2020 à 01:02, Tetsuharu OHZEKI
 a écrit :
>
> Hi WebKitten,
>
> As I see the following codes and grep,  I seem today's all (?) ports of WebKit
> have enabled ENABLE_STREAMS_API flag by default.
>
> - 
> https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformEnable.h?rev=263222#L466
> - 
> https://trac.webkit.org/browser/trunk/Source/cmake/OptionsFTW.cmake?rev=263222#L104
> - 
> https://trac.webkit.org/browser/trunk/Source/cmake/OptionsWin.cmake?rev=263222#L58
> - 
> https://trac.webkit.org/browser/trunk/Source/cmake/OptionsMac.cmake?rev=263222#L87
> - 
> https://trac.webkit.org/browser/trunk/Source/cmake/WebKitFeatures.cmake?rev=263222#L210
> - 
> https://trac.webkit.org/browser/trunk/Source/cmake/tools/vsprops/FeatureDefines.props?rev=263222#L276
>
> If my assumption is right, I'd like to propose to remove this
> `ENABLE_STREAMS_API` flag.
>
> What do you think about this?
> If I missed some ports, please tell me about them.
>
> --
> Tetsuharu OHZEKI
> tetsuharu.ohz...@gmail.com
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Position on emerging standard: WebCodecs

2020-05-06 Thread youenn fablet
> > - Providing deep access to codecs (in terms of capabilities,
> > observability of timing of operations...) requires careful thinking of
> > how much fingerprinting this ends up creating and how the processing
> > model will ensure to keep the whole API fingerprinting neutral.
>
> We have avoided providing codec enumeration API for this reason. Since
> a site can already run experiments on the  implementation it's
> not clear that there is substantial new surface, but it may be easier
> to implement those experiments accurately using WebCodecs.

Capabilities is indeed an issue. The more you need to understand the
codec, the wider is the API and the potential fingerprinting surface.
For instance, is the encoder supporting a realtime mode or not? Some
of it might be already retrieved from using a video element but the
potential mitigations might be easier with a video element than with a
JS API.

WebCodec might also potentially expose precise timing information in
how long it takes to decode/encode frames. Is it a way to identify
which hardware is being used underneath?

> > - A codec implementation used for RTC may differ significantly from a
> > codec implementation used for recording/MSE.
>
> Chrome's implementation of  does not really distinguish here.
> There are some tuning parameters (eg. latencyhint) which would be nice
> to expose to WebCodecs users.
>
> Do you foresee cases where usage hints are not sufficient?

I did not look at the usage hints but here are two examples:
1. A RTC decoder might want to do real-time error concealment / A MSE
decoder might not need to do any error concealment.
2. A MediaRecorder encoder might buffer frames to compress more
aggressively / a RTC encoder should not buffer frames.

> > - The complexity behind WebRTC, MSE or the media recorder API is not
> > to be neglected. There might be drawbacks in solving these issues at
> > the JS level instead of the browser level. I am for instance uncertain
> > that the level of complexity of a WebRTC pipeline can best be solved
> > by JS.
>
> Agreed; WebCodecs is a low-level API and is unlikely to be a better
> choice for use cases that are served by current APIs.
>
>
> - Dan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Position on emerging standard: WebCodecs

2020-05-04 Thread youenn fablet
Hi Dan,

Thanks for reaching out. Here is some feedback based on the web codecs
explainer (let me know if there is a more detailed proposal).
- I am generally in favour of trying to unify the various media
pipelines. It is always sad when one feature ships in the video
streaming pipeline, and not automatically to the RTC one (or the
reverse).
- Efficient processing of raw video frames (whatever its source:
camera, RTC, video streaming) seems like a really useful area to work
on.
- Existing APIs (video/image tags, MSE, WebRTC, recording API...)
already provide features that make use of codecs. It should be clear
what the goals/key benefits of directly exposing codecs are.
- Any media pipeline should be off the JS main thread, by default.
This does not seem guaranteed by the proposal.
- Providing deep access to codecs (in terms of capabilities,
observability of timing of operations...) requires careful thinking of
how much fingerprinting this ends up creating and how the processing
model will ensure to keep the whole API fingerprinting neutral.
- A codec implementation used for RTC may differ significantly from a
codec implementation used for recording/MSE. With this proposal, a web
page could try to use for RTC purposes a hardware codec dedicated to
recording/MSE. The results would be disastrous. That will probably
require extensive testing by web developers to ensure their scripts
are working in a wide variety of devices. At some point, that might
require supporting APIs to properly discover and setup
encoders/decoders for the various uses. This might further add to both
complexity and fingerprinting.
- The complexity behind WebRTC, MSE or the media recorder API is not
to be neglected. There might be drawbacks in solving these issues at
the JS level instead of the browser level. I am for instance uncertain
that the level of complexity of a WebRTC pipeline can best be solved
by JS.
- Some code might best stay in control of the browser. Related to
WebCodecs is the insertable stream proposal which could allow
deploying end-to-end encryption quickly to RTC with a JS-only
solution. A JS solution leaves full control to web pages and limits
the ability for user agents to upgrade such security mechanisms like
they can do for other security mechanisms like TLS/DTLS.

As a background information, I would also note the effort done lately
in WebKit to move parts of media processing out of processes running
JavaScript.

Hope this helps,
Y

Le jeu. 30 avr. 2020 à 00:53, Dan Sanders  a écrit :
>
> Hello,
>
> I'm reaching out to see if WebKit would like to weigh in on the
> WebCodecs WICG proposal:
> https://discourse.wicg.io/t/webcodecs-proposal/3662.
>
> The WebCodecs API enables web developers to instantiate codecs
> (audio/video encoders/decoders) and use them to process individual
> frames.
>
> There is a related proposal for image decoders; it enables access to
> individual animation frames:
> https://discourse.wicg.io/t/proposal-imagedecoder-api-extension-for-webcodecs/4418.
>
> An implementation of these APIs is being developed in Chromium.
>
>
> Thank you,
>
> Dan Sanders
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-14 Thread youenn fablet
Is it too late to ask for a std::optional change?

Le ven. 14 déc. 2018 à 13:37, Chris Dumez  a écrit :
>
> Hi,
>
> I have now been caught twice by std::optional’s move constructor. It turns 
> out that it leaves the std::optional being moved-out *engaged*, it merely 
> moves its value.
>
> For example, testOptional.cpp:
> #include 
> #include 
>
> int main()
> {
> std::optional a = 1;
> std::optional b = std::move(a);
> std::cout << "a is engaged? " << !!a << std::endl;
> std::cout << "b is engaged? " << !!b << std::endl;
> return 0;
> }
>
> $ clang++ testOptional.cpp -o testOptional -std=c++17
> $ ./testOptional
> a is engaged? 1
> b is engaged? 1
>
> I would have expected:
> a is engaged? 0
> b is engaged? 1
>
> This impacts the standard std::optional implementation on my machine as well 
> as the local copy in WebKit’s wtf/Optional.h.
>
> As far as I know, our convention in WebKit so far for our types has been that 
> types getting moved-out are left in a valid “empty” state.
> As such, I find that std::optional’s move constructor behavior is error-prone.
>
> I’d like to know how do other feel about this behavior? If enough people 
> agree this is error-prone, would we consider having our
> own optional type in WTF which resets the engaged flag (and never allow the 
> std::optional)?
>
> Thanks,
> --
>  Chris Dumez
>
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Experimental and (new) Internal feature flags

2018-09-12 Thread youenn fablet
> Since an experimental feature flag should not remain off for a long time,
> a per-experimental-feature file listing the tests to which activate the
> feature could be considered.
>
>
> That clashes with Ryosuke's point that moving tests shouldn't change
> behaviour.
>

I think it is better to discover the issue at the moment tests are moved.
When moving/creating such tests in WPT, the potential issue will only arise
after the export/import cycle. Chances are that the issue will get
unnnoticed.


> The larger problems are:
>
> - We don't want experimental features to be on in shipping browsers. It
> might be ok for them to be always on in tests, but then MiniBrowser would
> be different from WKTR. At the moment they are always on in tests, and use
> their default value in MiniBrowser (and shipping).
>

When implementing a new feature, the first thing we usually do is having an
experimental flag turned off by default. At some point, we turn on the
experimental flag for tests. When ready, the flag is turned on by default.

It is nice to keep the cost of implementing this workflow as low as
possible.
Having to tweak layout tests does not go in that direction.
If this workflow was fully implementable by just updating
WebPreferences.yaml, that would be great.
That could also allow running mini browser in a mode where the same flags
would be turned on as WKTR.


> - Internal features can either be on or off by default, because we don't
> expect users to toggle them. The tests should reflect their default value.
> You use the header to test the non-default case.
>


>
> So what we have right now is probably ok. The issue is with things I moved
> from experimental to internal and that have a default value of off. I think
> it is perfectly fine for those features to require test headers, since they
> clearly aren't ready.
>

If these features are for debug purposes only, it seems like they would
never end up being turned on by default, in which case opt-in in tests is
fine.
I would think there would be no need to turn on these features for WPT
tests.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Experimental and (new) Internal feature flags

2018-09-12 Thread youenn fablet
> What about testing?
> 
>
> You can turn both experimental and internal features on via headers in
> WebKitTestRunner. Use experimental:FeatureName or internal:FeatureName. For
> example...
>
> 
>

It seems tedious to add such things to every test.
That would also mean we would need to remove these lines to every test when
we activate the flag by default or when we remove the flag.

As of WPT, modifying tests on the fly at import time is doable but it goes
against the idea of making WPT import/export simpler so I hope we can find
something better.

testharnessreport.js might help activating flags specifically for WPT.
Since an experimental feature flag should not remain off for a long time, a
per-experimental-feature file listing the tests to which activate the
feature could be considered.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fujii Hironori is now a WebKit reviewer

2018-07-14 Thread youenn fablet
Congratulations!
   Y

Le sam. 14 juil. 2018 à 13:30, Michael Catanzaro  a
écrit :

> Hi,
>
> Fujii Hironori is now a WebKit reviewer. He has expertise in Windows
> support, WebKitGTK+, and WebCore bugs. Please congratulate him and send
> him patches to review!
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Objective-C code in libwebrtc already assuming ARC?

2018-06-06 Thread youenn fablet
Dave suggested the same approach in
https://bugs.webkit.org/show_bug.cgi?id=185324.
ARC should be enabled for the whole libwebrtc project in WebKit ToT.
   Y
Le mer. 6 juin 2018 à 09:28, Darin Adler  a écrit :

> Hi folks.
>
> As some of you have probably noticed, I’ve begun making changes with the
> goal of preparing us to move most Objective-C code in WebKit to ARC. In
> doing so, I have been exploring the existing code in the tree and the
> various projects in our source tree. The nine projects with configuration
> files that I have looked at are:
>
> JavaScriptCore, ANGLE, libwebrtc, WebCore, WebCore/PAL, WebInspectorUI,
> WebKit, WebKitLegacy/mac, and bmalloc.
>
> These projects all currently have CLANG_ENABLE_OBJC_WEAK in their
> configuration files, and moving them to ARC involves adding
> CLANG_ENABLE_OBJC_ARC, and then doing lots of other work to ensure the
> projects still work properly, including possibly turning off ARC for
> certain source files that are best keep working with manual retain and
> release. Some of them such as ANGLE, bmalloc, and WebInspectorUI, have no
> Objective-C code, or almost none, so they should be easy to “convert".
>
> But when investigating libwebrtc I discovered a non-tribal amount of code
> that already seems to assume ARC but to be compiled with ARC disabled. One
> example is these two methods:
>
> -[RTCVideoEncoderFactoryH264 supportedCodecs]
> -[RTCVideoDecoderFactoryH264 supportedCodecs]
>
> If we are compiling this without ARC and executing calls to these methods,
> then I think we will have storage leaks.
>
> As far as I can tell, the only source file in libwebrtc that is currently
> compiled with ARC enabled is voice_processing_audio_unit.mm but perhaps I
> am overlooking something.
>
> Do we need to turn ARC on for the entire libwebrtc project?
>
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2018-05-25 Thread youenn fablet
> 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 we should also detect harness errors, and eventually also flag when
> a test goes from passing everywhere to failing everywhere, which is
> probably a mistake. We haven't really figured out how to make that block
> Chromium's CQ yet, and maybe flipping the order would do it.
>

Exactly, WPT infrastructure has some really nice sanity checks that we do
not have in WebKit and it sounds really great to benefit from it.

That said, this will put some burden on WPT infrastructure like being fast
enough to not slow down our own process.

We should also probably run as much as possible the WPT sanity checks
locally.
We are now checking WPT linter as you suggested a while back.
Maybe there are some other WPT checks that could be run in the WebKit
context.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2018-05-25 Thread youenn fablet
> Interesting. What happens happens if the WebKit patch then fails to land
> in WebKit, perhaps because some bot fails the test, a conflict, or anything
> else? Is resolving that a manual affair?
>

If patch lands in WPT and not in WebKit due to conflicts, that is fine.
One will need to resolve the conflict manually as done for other conflicts.


>
> When imports are automated and much more frequent, I take it the upside is
> that you never need to reapply still-being-exported patches like we do in
> Blink. But what about the above case, when the change hasn't been applied
> in WebKit yet? Seems like the importer instead needs to *revert* the
> in-flight change?
>

I guess the question is if the change is made in WPT, not yet in WebKit and
we are reimporting in the middle.
In that case, we will probably have the new test failing, timing out or
crashing.
This will get fixed once the patch lands in WebKit (after conflict
resolution).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2018-05-24 Thread youenn fablet
>
>> 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.
>>
>
> Oh, that is surprising.
>
> https://github.com/w3c/web-platform-tests/pull/10964 is a recent WebKit
> export, and https://trac.webkit.org/changeset/231788/webkit did modify
> the test in place. Do you mean that the WPT PR was merged first, or should
> be in general? Chromium and Gecko do it in the other order, and I'd be
> interested to understand the trade-offs of flipping the order.
>

Yep, WPT PR merged first, then WebKit patch landed.
It makes sure that whenever we are reimporting tests, we are not loosing
any WebKit specific change.
Conflict resolution also happens at a time the patch is being committed in
WebKit.
So far, I encountered very few conflicts.

Any process like this where changes end up in WebKit trunk via anything
> except a full WPT import will mean that divergence is possible. In
> Chromium, regular imports are the safeguard that will eventually resolve
> any issuesinvolves. In practice, much to my surprise, we've really never
> had something funny happen due to the temporary divergence the process
> involves.
>

Agreed that in practice this probably does not matter much.
There is work to allow easier WPT imports so that it can be done more
regularly in WebKit.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2018-05-23 Thread youenn fablet
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
> > LayoutTests/imported/w3c/web-platform-tests.
>

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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2018-05-23 Thread youenn fablet
I think WebKitten should be able to choose between 1 and 2 on a per patch
basis.

In both cases, Tools/Script/export-w3c-test-changes can be used to help
upstreaming to WPT.
The WPT exporter can push the changes to a branch in a GitHub WPT clone.
It can also create the WPT PR on behalf of the WebKitten.

As requested by some folks, integration of WPT exporter with webkit-patch
is on its way (https://bugs.webkit.org/show_bug.cgi?id=184914)

Any WPT PR that is reviewed downstream in WebKit can be merged without
further WPT review.
At the moment, given the WPT infra and the way we currently create WebKit
PR, not every WebKitten is allowed to merge such PRs directly.
Please cc/ping me in such a case.
Y

Le mer. 23 mai 2018 à 02:41, Frédéric Wang  a écrit :

> Hi all,
>
> When implementing new platform features in WebKit, some of us write new
> WPT tests in order to verify spec conformance. One of the reason to use
> this format is that the tests can then be easily shared with web engine
> developers and people involved in standardization, an important feature
> for web platform developers.
>
> Youenn has shared various ideas to export such WPT tests to the W3C
> GitHub repository in the past [1] [2] [3] but I'm not sure the WebKit
> community has reached an agreement.
>
> There are basically two ways to proceed:
>
> 1) Either submit WPT tests to GitHub (or Mozilla / Chromium) repository,
> get them reviewed and do the import within the patch that implements the
> feature in WebKit.
>
> 2) Or submit the patch with new WPT tests to WebKit, get it reviewed and
> export it to GitHub (later sync with Mozilla / Chromium).
>
> The first option has the advantage to get more people involved in test
> review, which sometimes gives faster replies or useful advice from
> people who more familiar with the spec. However, the second option has
> the advantage of not splitting the coding & testing parts and is better
> for the WebKit implementers and reviewers. That latter option also
> aligns with what Mozilla and Chromium developers do.
>
> Can we please agree on a way to proceed? And add documentation somewhere
> for developers/reviewers?
>
> Thanks!
>
>
> [1] https://lists.webkit.org/pipermail/webkit-dev/2017-March/028884.html
> [2] https://lists.webkit.org/pipermail/webkit-dev/2017-April/028932.html
> [3]
> https://lists.webkit.org/pipermail/webkit-dev/2017-December/029837.html
>
> --
> Frédéric Wang - frederic-wang.fr
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Tips to build faster on Mac?

2018-03-16 Thread youenn fablet
If you have a full build and made changes to WebCore, you might only need
to recompile WebCore. With make for instance, one can do:
make d -C Source/WebCore

  Y

On Fri, Mar 16, 2018 at 6:55 AM Danyao Wang  wrote:

> Thanks Brian for the Xcode UI tip! So far I've always used build-webkit. I
> didn't realize there could be a difference.
>
> On Thu, Mar 15, 2018 at 6:01 PM, Brian Burg  wrote:
>
>>
>>
>> > On Mar 15, 2018, at 1:58 PM, Danyao Wang  wrote:
>> >
>> > Hi,
>> >
>> > Being new to WebKit development (and also switching from Linux to Mac),
>> I find my workflow relatively clumsy. Building on a fresh checkout usually
>> takes me 20+ minutes even on my 12-core Mac Pro. Fastest incremental builds
>> are ~2 minutes. This adds a lot to the develop / test / debug cycle.
>>
>> These build times seem normal. WebKit is a big project, and we don’t use
>> CMake/ninja by default when building for Cocoa ports.
>>
>> Are you building via build-webkit on the command line? In my experience,
>> incremental builds are faster via Xcode’s UI.
>>
>> > I heard the good folks from Igalia working on the GTK port use icecc.
>> Has anyone used this on Mac? Any other productivity tips?
>> >
>> > Thanks!
>> > Danyao
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] OWNERS policy

2018-02-21 Thread youenn fablet
Hi Don,

I am not sure there is a well defined policy.
If we want to continue with owners, it would indeed be good to make it
clearer and more functional.

Here is my current understanding.
The multi-process architecture is now well in place so things like updating
IPC encoders/decoders might no longer require a dedicated owner scrutiny.
Exposing the right WK2 APIs is more sensitive on the other hand.

   Y

Le mer. 21 févr. 2018 à 12:52,  a écrit :

> Hi WebKittens,
>
>
>
> As you know we're working on getting WinCairo running on modern WebKit.
> We're working through a backlog of patches we have to upstream and are
> sometimes running into issues where we can't find reviewers for our code.
>
>
>
> Here are some bugs with attachments that have been hanging out for over 5
> days.
>
>
>
> https://bugs.webkit.org/show_bug.cgi?id=182870
>
> https://bugs.webkit.org/show_bug.cgi?id=182869
>
> https://bugs.webkit.org/show_bug.cgi?id=182751
>
>
>
> One thing we're unclear on is the OWNERS policy. The list itself is pretty
> small and has no guidance on who might be the right person(s) to assign a
> bug to when touching shared code. It feels like we're just guessing on
> reviewers which doesn't seem like it helps anything move along.
>
>
>
> There also seem to be commits that were reviewed by non-owners that are
> touching common code. We're not sure if unfamiliarity with Windows might
> prevent some owners from looking over a patch as we move further along in
> our implementation.
>
>
>
> Basically we'd like to get some clarification here so we can keep landing
> patches for modern WebKit on Windows.
>
>
>
> Thanks!
>
> Sony WebKit Team
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2018-02-12 Thread youenn fablet
Hi Zan,

I like the idea of using WebDriver for WPT conformance testing.
Such results will probably be more meaningful for conformance than what WTR
or DRT could produce.
For WPT regression testing, we would stick to using WTR/DRT and internals
methods instead of WebDriver, am I right?
   y

Le lun. 12 févr. 2018 à 07:08,  a écrit :

> Hi,
>
> the web-platform-tests repository includes tooling that enables running
> those tests against a supported browser product. I'd like to propose adding
> generic WebKit support there.
>
>
> Current changes only assume usage of the WebDriver protocol, and the
> WebDriver binary accepting the --port flag. Selenium executors are used for
> test harness and reftests. Same WebDriver implementation can also be tested
> against the WebDriver tests included in the web-platform-tests directory,
> presuming the tests are enabled or explicitly specified.
>
> Only port-specific bit is the specification of capabilities that are
> passed to the WebDriver binary, idea being that these capabilities are the
> same as those supported by the WebDriver implementation.
>
> GTK is for now the only port that's supported, and it's leveraging the
> WebDriver implementation under Source/WebDriver/ in WebKit. WPE will be
> doing the same. Safari I suppose could use its own WebDriver
> implementation, or perhaps even a separate product.
>
> Here's the current set of changes:
>
> https://github.com/zdobersek/web-platform-tests/commit/c2ee920876ca6df7c4739feb8a6e03c77dffdb7f
>
>
> The web-platform-tests suite can then be run like this for the GTK port,
> assuming a tip-of-trunk build:
>
> $ /work/web-platform-tests/wpt run --webkit-port=gtk \
> --webdriver-binary=WebKitBuild/Release/bin/WebKitWebDriver \
> --binary=WebKitBuild/Release/bin/MiniBrowser \
> --binary-arg=--automation \
> --binary-arg=--javascript-can-open-windows-automatically=true \
> --binary-arg=--enable-xss-auditor=false \
> webkit /2dcontext
>
> This can be further wrapped into a python script and run as part of the
> continuous integration system. These changes add a run-web-platform-tests
> script that invokes the web-platform-tests runner tool, also allowing each
> port to specify what tests to enable and what the expected failures are:
>
> https://github.com/Igalia/webkit/commit/df1aeeb9476c6dd220067f4fc3c6ad69a8f948ba
>
> Only a small subset of tests is enabled there, for prototype purposes. The
> expected results system could also be improved to avoid each expected
> failure having to be marked as such in separate .ini files.
>
>
> But foremost, I'd like to have a consensus of sorts about how various
> WebKit ports should be handled in the web-platform-tests repository, so
> that the changes there can proceed -- whether it's fine to implement a
> generic WebKit product, or whether Safari would like to be treated as a
> separate browser[1], etc.
>
>
> Regards,
> Zan
>
>
> [1] There's for instance this from a year ago (though not sure about its
> functionality):
> https://github.com/w3c/web-platform-tests/tree/wptrunner-safari
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Exporting WPT tests

2017-12-20 Thread youenn fablet
Hi all,

Just to let you know that a new script landed in WebKit:
Tools/Scripts/export-w3c-test-changes.
Please have a look if you are interested in and ping me if you have any
question or suggestion.
This script can:
- Push your LayoutTests/imported/w3c/web-platform-tests changes made within
a WebKit repository to your own GitHub WPT clone
- Create a PR on W3C WPT repo and add a comment on the related WebKit
bugzilla (-c option)

There is some information that is needed the first time: your GitHub
username, a GitHub token to allow the script to create a PR on your behalf.
Script documentation might help.

One potential workflow could be something like:
1. Author a webkit patch
2. Upload patch to bugzilla
3. At the time patch is set to "r?" on bugzilla, use the script to create a
W3C WPT PR.
When the patch is "r+", merge the W3C WPT PR and land the WebKit patch.

Merry Christmas,
   y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-11-21 Thread youenn fablet
I filed https://github.com/w3c/web-platform-tests/issues/8391 for the WPT
server performances issues.
As of upstreaming the tests, would the following solve identified issues
and keep the upstream process lightweight enough?
- Meta tag each upstreamed test to identify this is an upstreamed version
of a WebKit test (and maybe which WebKit test).
- Keep relative paths for upstreamed tests.
y

Le ven. 17 nov. 2017 à 23:02, youenn fablet <youe...@gmail.com> a écrit :

> 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 related to the points you are
> bringing to the table.
>
> Stepping back from the WPT server specific issue, being optimistic and
> assuming that we are able to run WPT tests with good enough performances.
> Migration potential downsides I heard so far:
> - Prioritization of tests to investigate might be harder.
> - Sharing tests with other teams might be harder if subresource links are
> not relative.
> These two seem like solvable issues to me.
>
> Le ven. 17 nov. 2017 à 10:09, Alexey Proskuryakov <a...@apple.com> a écrit :
>
>>
>> 17 нояб. 2017 г., в 9:18, youenn fablet <youe...@gmail.com> написал(а):
>>
>>
>> Chris recently noticed that some heavily used files (testharness*) were
>> cacheable through Apache but not WPT.
>> This is now fixed and should improve WPT performances.
>>
>>
>> This is part of <https://bugs.webkit.org/show_bug.cgi?id=178277>,
>> another part is that the server is 10x slower than Apache.
>>
>
> Other measurements showed 3x slower, which makes it still worthwhile to
> explore.
> We need to be cautious here though since optimization is all about chasing
> where time is actually spent.
>
> If we can prove to ourselves that this is an important issue, we should
> discuss with the WPT community to see how to fix this issue.
> In addition to better caching, other optimization like
> https://github.com/w3c/wptserve/pull/86 may bring some additional benefit.
>
> If we do not find any good solution at WPT server level, we still have the
> option to run some tests as file-based.
> Ryosuke mentioned the possibility to classify tests at import time by
> checking their results when served through WPT server and as file URLs.
>
> I just tested on my MacBook Pro, and WPT tests took 23% of time while
>> being only 9% of the total count. Taking in mind that WebKit own tests have
>> higher value due to the way we choose what to test (see below), that's not
>> a great story in my opinion.
>>
>
> These numbers are difficult to interpret.
> WPT authoring style is multiple tests in a single file, which is bad for
> stability but potentially good for performances.
> WebKit usually prefers one file/one test.
>
> If we want to talk to WPT community about this, we need to provide some
> more tangible numbers.
> We could try to run a large subset of WPT tests that run the same through
> Apache and WPT.
> I just did that on a small subset of IDB tests. This seems to show
> something like a 25% slowdown.
>
> One other thing that we discussed before was the operational complexity of
>> running WPT tests. We frequently need to share tests with people who don't
>> work on WebKit directly, but have the need to edit and run our tests.
>> Inability to drag and drop a local copy into a Safari window is a deterrent
>> to addressing problems caught by the tests. I think that the response we
>> got was that tests will continue to require a server to run.
>>
>
> Tests are available at https://w3c-test.org which makes it easy to share
> through any tool supporting hyperlinks.
> A webarchive can also be made so that it is easy to share and probably
> edit such tests.
> Tools like jsfiddle are also a great way to create/share/edit tests.
> I received several bug reports on bugzilla using it and this proved to be
> efficient.
>
>
>> Let me explain why I think that WebKit tests are often more valuable as
>> regression tests than WPT tests are. We add tests as we fix bugs, so we
>> know that the tests are generally for problems that have a high impact on
>> users and developers - that's because someone actually discovered the
>> problem, and someone prioritized it highly enough to fix. We also know that
>> our tests cover code that is error prone, which is why we had bugs in the
>> first place. Of course, anything can be broken, but certain things are less
>> likely to. Compliance tests written for specs are also valuable, but at
>> some point we need to prioritize which tests to investigate and even to run.
>>
>
> I don't

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

2017-11-17 Thread youenn fablet
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 related to the points you are
bringing to the table.

Stepping back from the WPT server specific issue, being optimistic and
assuming that we are able to run WPT tests with good enough performances.
Migration potential downsides I heard so far:
- Prioritization of tests to investigate might be harder.
- Sharing tests with other teams might be harder if subresource links are
not relative.
These two seem like solvable issues to me.

Le ven. 17 nov. 2017 à 10:09, Alexey Proskuryakov <a...@apple.com> a écrit :

>
> 17 нояб. 2017 г., в 9:18, youenn fablet <youe...@gmail.com> написал(а):
>
>
> Chris recently noticed that some heavily used files (testharness*) were
> cacheable through Apache but not WPT.
> This is now fixed and should improve WPT performances.
>
>
> This is part of <https://bugs.webkit.org/show_bug.cgi?id=178277>, another
> part is that the server is 10x slower than Apache.
>

Other measurements showed 3x slower, which makes it still worthwhile to
explore.
We need to be cautious here though since optimization is all about chasing
where time is actually spent.

If we can prove to ourselves that this is an important issue, we should
discuss with the WPT community to see how to fix this issue.
In addition to better caching, other optimization like
https://github.com/w3c/wptserve/pull/86 may bring some additional benefit.

If we do not find any good solution at WPT server level, we still have the
option to run some tests as file-based.
Ryosuke mentioned the possibility to classify tests at import time by
checking their results when served through WPT server and as file URLs.

I just tested on my MacBook Pro, and WPT tests took 23% of time while being
> only 9% of the total count. Taking in mind that WebKit own tests have
> higher value due to the way we choose what to test (see below), that's not
> a great story in my opinion.
>

These numbers are difficult to interpret.
WPT authoring style is multiple tests in a single file, which is bad for
stability but potentially good for performances.
WebKit usually prefers one file/one test.

If we want to talk to WPT community about this, we need to provide some
more tangible numbers.
We could try to run a large subset of WPT tests that run the same through
Apache and WPT.
I just did that on a small subset of IDB tests. This seems to show
something like a 25% slowdown.

One other thing that we discussed before was the operational complexity of
> running WPT tests. We frequently need to share tests with people who don't
> work on WebKit directly, but have the need to edit and run our tests.
> Inability to drag and drop a local copy into a Safari window is a deterrent
> to addressing problems caught by the tests. I think that the response we
> got was that tests will continue to require a server to run.
>

Tests are available at https://w3c-test.org which makes it easy to share
through any tool supporting hyperlinks.
A webarchive can also be made so that it is easy to share and probably edit
such tests.
Tools like jsfiddle are also a great way to create/share/edit tests.
I received several bug reports on bugzilla using it and this proved to be
efficient.


> Let me explain why I think that WebKit tests are often more valuable as
> regression tests than WPT tests are. We add tests as we fix bugs, so we
> know that the tests are generally for problems that have a high impact on
> users and developers - that's because someone actually discovered the
> problem, and someone prioritized it highly enough to fix. We also know that
> our tests cover code that is error prone, which is why we had bugs in the
> first place. Of course, anything can be broken, but certain things are less
> likely to. Compliance tests written for specs are also valuable, but at
> some point we need to prioritize which tests to investigate and even to run.
>

I don't really see why we should prioritize the tests to run when all of
them provide clear value to some WebKit members.
I agree that we need to prioritize tests we investigate. There can be a
solution inside WPT, like adding WebKit specific metadata so that:
- WPT contributors would communicate with WebKit members whenever changing
such tests
- WebKit contributors would prioritize WPT-WebKit-metadata failing tests

That said, if these tests are so beneficial to WebKit, they are potentially
very useful to other teams as well.
And vice-versa, we might find really good WPT tests that show useful
crashes and failures in WebKit.
I am experiencing that nowadays with WPT service worker tests.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-11-17 Thread youenn fablet
>From my experience, the people behind WPT are quite responsive to WebKit
community.
Here are two examples:
Chris recently noticed that some heavily used files (testharness*) were
cacheable through Apache but not WPT.
This is now fixed and should improve WPT performances.
In January, was discussed the idea to automate WPT manual tests.
WebKit requirement to use test runner API instead of WebDriver was taken
into account.
I am pretty confident that WPT can accommodate other WebKit issues.

We have a lot of conformance-only tests in WebKit LayoutTests.
It would make a lot of sense to upstream them/replace them.
Having an up-to-date version and an obsolete version of the same test at
the same time is not appealing.
It makes writing a conformance-fixing patch longer and it takes more time
to run the test suite for no good reason.

Regression tests are of course more difficult to process and probably less
of a priority.  This was discussed quickly at TPAC.
Upstreaming such tests could be done as long as these tests are marked as
WebKit-specific and changes to them would require validation from WebKit
community.
Keeping history through git should be possible.

I would also like to mention that, from my personal experience, WPT tests
are of a high quality.
This probably comes from WPT nature which is focused just on tests and
developed a specific review process and validation process for the sole
purpose of tests.

y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-10-15 Thread youenn fablet
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, update/create WPT tests and test them in WebKit
environment
3. Export WPT-related changes to a WPT GitHub fork and/or PR to W3C WPT
repository using the script

This allows authoring WPT tests and WebKit patch at the same time.
This removes the annoying steps of manually copying WebKit changes to an
external WPT checkout.

At that point, one can wait for WPT PR to land or start uploading changes
to bugzilla in parallel.
The usual WebKit review process will happen with the possibility to merge
the corresponding WPT PR when related WebKit patch is r+ed.
Changes to WPT tests should be committed in WebKit trunk when already
merged to W3C WPT.

There are some benefits of doing both PR and bugzilla at the same time.
It allows for instance validating stability of test, style of test and
results on other browsers through WPT GitHub infrastructure.

Any feedback welcome, here or in [1].

Thanks
   y

[1]: https://bugs.webkit.org/show_bug.cgi?id=169462
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Where do we put WPT tests to be exported

2017-07-11 Thread youenn fablet
Hi Ali,

I think it is valuable to upload a patch containing source code changes
with the new/modified WPT tests covering these changes.
I would recommend to do the GitHub submission in parallel and add a
reference to the GitHub PR in WebKit bugzilla.
Ideally, the GitHub PR would be merged before the WebKit patch is committed.
y

Le mar. 11 juil. 2017 à 16:14, Ali Juma <aj...@chromium.org> a écrit :

> Hi all,
>
> Just wanted to check what the current recommended approach is for new WPT
> tests. Is it now ok to add new tests directly in
> LayoutTests/imported/w3c/web-platform-tests and then upstream them, or
> should tests still be added elsewhere first (in LayoutTests/http/wpt?),
> upstreamed, and then moved into LayoutTests/imported/w3c/web-
> platform-tests?
>
> Thanks,
> Ali
>
> On Sun, May 21, 2017 at 11:14 PM youenn fablet <youe...@gmail.com> wrote:
>
>> Filed https://bugs.webkit.org/show_bug.cgi?id=172435 about that
>>
>>
>> Le dim. 21 mai 2017 à 00:40, Maciej Stachowiak <m...@apple.com> a écrit :
>>
>>> On May 18, 2017, at 2:08 PM, Philip Jägenstedt <foo...@google.com>
>>> wrote:
>>>
>>> On Tue, May 16, 2017 at 5:38 PM youenn fablet <youe...@gmail.com> wrote:
>>>
>>>>
>>>> There was a suggestion that LayoutTests/imported/w3c/web-platform-tests
>>>> be moved to a shorter path like LayoutTests/web-platform-tests. That would
>>>> also make it clear that this folder is not only about one-way-sync.
>>>>
>>>
>>> In Blink we renamed it to LayoutTests/external/wpt/ to avoid the "read
>>> only" implications of the old name.
>>>
>>>
>>> If we go forward with two-way sync, I think this is a good name.
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-06-02 Thread youenn fablet
Hi Ali,

Yes this is something we should have a solution for. Right now, we have two
ways:
- Enabling the runtime-enabled flag only in DumpRenderTree/WebKitTestRunner
- Updating WebKit testharnessreport.js to call internal APIs for some/all
WPT tests

Ideally, we should be able to set additional configuration information to
WPT tests without modifying them.
A configuration file alongside the WPT test might be feasible and could
supersede the 
technique.
Folder-based hierarchical configuration might be nice but I am unsure
whether that would meet the complexity tradeoff bar.
Nothing yet started there so any help would be greatly appreciated!
y

Le ven. 2 juin 2017 à 13:37, Ali Juma  a écrit :

> Hi all,
>
> While a feature is in development behind a runtime-enabled flag, is there
> a way to write tests in web-platform-tests that enable the feature when
> they're run as part of LayoutTests? Adding "" tags would technically work but seems a bit
> questionable.
>
> The point of this would be to be able to use web platform tests as
> regression tests while developing a feature, allowing the tests to be
> upstreamed sooner and saving having to write them outside of
> web-platform-tests first and then move them over later.
>
> Thanks,
> Ali
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Where do we put WPT tests to be exported

2017-05-21 Thread youenn fablet
Filed https://bugs.webkit.org/show_bug.cgi?id=172435 about that


Le dim. 21 mai 2017 à 00:40, Maciej Stachowiak <m...@apple.com> a écrit :

> On May 18, 2017, at 2:08 PM, Philip Jägenstedt <foo...@google.com> wrote:
>
> On Tue, May 16, 2017 at 5:38 PM youenn fablet <youe...@gmail.com> wrote:
>
>>
>> There was a suggestion that LayoutTests/imported/w3c/web-platform-tests
>> be moved to a shorter path like LayoutTests/web-platform-tests. That would
>> also make it clear that this folder is not only about one-way-sync.
>>
>
> In Blink we renamed it to LayoutTests/external/wpt/ to avoid the "read
> only" implications of the old name.
>
>
> If we go forward with two-way sync, I think this is a good name.
>
> Regards,
> Maciej
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Where do we put WPT tests to be exported

2017-05-19 Thread youenn fablet
> > Sure, it is good to test conformance, but there is no longer regression
> > testing on the deprecated feature behavior itself.
> > Ideally, this would require tighter syncing between the browsers. Might
> have
> > positive and/or negative consequences.
>
> I don't think we should be changing anything about our process to
> deprecate a feature based on changes to web platform tests or its
> limitations.
>

Agreed.


>
> If web platform tests end up deleting tests that we decide to continue
> to support, we should keep them elsewhere in WebKit repository instead
> of deleting those features.
>

Exactly, we should be ready for those cases.
When doing a full resync, it is just impossible to check whether each
modification is about feature removal.


> I would most vocally and strongly oppose to making any feature or
> policy decisions in WebKit solely based on changes to or processes in
> web platform tests.
>
> - R. Niwa
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Where do we put WPT tests to be exported

2017-05-19 Thread youenn fablet
Le ven. 19 mai 2017 à 09:44, Anne van Kesteren <ann...@annevk.nl> a écrit :

> On Fri, May 19, 2017 at 5:11 PM, youenn fablet <youe...@gmail.com> wrote:
> > When a spec gets updated, the WPT tests will ideally be updated at the
> same
> > time.
> > The updated tests will no longer ensure non-regression until the browser
> > implements the new behavior.
>
> Ideally if importing test updates results in failures those end up
> being tracked as new bugs. I realize that's not how it works today,
> but that's how it should work I think.
>

Right, and that is very good as long as there is effort to match the
implementation with the spec.
Until the bug is fixed, regressions related to the no-longer compliant
behavior might not be caught by WPT.


>
>
> > The same applies to deprecated features for which WPT tests might be
> removed
> > for instance.
>
> In this case it's expected that a "historical" test is added that
> tests the feature isn't supported, so there's still coverage.
>

Sure, it is good to test conformance, but there is no longer regression
testing on the deprecated feature behavior itself.
Ideally, this would require tighter syncing between the browsers. Might
have positive and/or negative consequences.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Where do we put WPT tests to be exported

2017-05-19 Thread youenn fablet
Le jeu. 18 mai 2017 à 05:09, Philip Jägenstedt  a écrit :

>
>> FWIW, I think it makes sense to treat wpt as both regression tests and
> conformance tests. They're regression tests because they can in fact catch
> regressions. And they're conformance tests because they're supposed to be
> derived from the specs, and that should be true of local modifications as
> well if they're intended to be upstreamed.
>
>
When a spec gets updated, the WPT tests will ideally be updated at the same
time.
The updated tests will no longer ensure non-regression until the browser
implements the new behavior.
The same applies to deprecated features for which WPT tests might be
removed for instance.
I don't know what WPT can do there. This issue is probably limited in
practice.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Where do we put WPT tests to be exported

2017-05-16 Thread youenn fablet
That is a fair point!
For importing tests, effort was done to ease the use of the
import-w3c-tests script.
Documentation should be in "Tools/Scripts/import-w3c-tests --help"
I will be happy to beef it up based on suggestions.
y

Le mar. 16 mai 2017 à 07:55, Michael Catanzaro  a
écrit :

> On Mon, May 15, 2017 at 11:01 PM, Ryosuke Niwa  wrote:
> > Hi all,
> >
> > Youenn is working on a patch to automatically create a GitHub PR to
> > export tests from a WebKit patch which includes changes to
> > web-platform-tests [1].
> >
> > That raises a question as to where we should put new tests or modified
> > tests intended to be exported to web-platform-tests from WebKit.
>
> Whatever you wind up doing, it would be helpful to add a README
> somewhere that explains the workflow, so the process doesn't turn into
> folklore only known to the developers who work on it regularly and
> those who read this mailing list thread.
>
> Thanks,
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Where do we put WPT tests to be exported

2017-05-16 Thread youenn fablet
Le lun. 15 mai 2017 à 23:15, Maciej Stachowiak <m...@apple.com> a écrit :

>
> On May 15, 2017, at 9:08 PM, youenn fablet <youe...@gmail.com> wrote:
>
> I see two main cases:
> - Writer of the patch is making sure to upstream WPT test changes at
> WebKit landing time. It is ok to make the changes directly in
> LayoutTests/imported/w3c/web-platform-tests/
> - Writer plans to upstream WPT test changes at some point but wants more
> time. It is better to develop the tests in LayoutTests/http/wpt and then
> migrate them later on.
>
>
> My proposal was different from either of these, it was to have a directory
> specifically for tests meant to be upstreamed (LayoutTests/http/wpt should
> contain only tests not meant
>

The possibility to have LayoutTests/http/wpt/to-be-imported was mentionned
previously.
I think it makes sense to run to-be-imported tests behind WPT as this is
the way they will end up being run when upstreamed.


>
> I think adding new tests directly to
> LayoutTests/imported/w3c/web-platform-tests/ is needlessly messy. Most
> stuff in the imported/ directory is an exact copy of an upstream test
> suite, so if you run only a specific directory of tests, you know you are
> running an official conformance suite. With this proposal, it might also
> contain random tests that will hopefully be upstreamed but maybe not, or
> might be changed before the PR lands upstream, or might get renamed, or
> whatever. There's no guarantee that updating from the official version will
> ever fully resolve the delta.
>

LayoutTests/imported/w3c/web-platform-tests is mostly about regression
testing.
For conformance testing, it is probably more accurate to either use
w3c-test.org (probably not reliable enough though) or make a clone of W3C
WPT, do the set up as specified in their README (etc/hosts...) and use
wptrunner.


>
> I think it would be more elegant to have a parallel directory
> (LayoutTests/for-export/w3c/web-platform-tests). Then when something is
> actually upstreamed and then pulled back down, we could delete the staged
> version. Directly modifying our local copy seems like it could easily lead
> to long-term divergences slipping through the cracks.
>

A parallel directory is fine when starting a test suite.
Often, changes are limited to modifying a test, which might be best done
in-place.
Often, adding a test is easier by adding it in an already existing file.

Tooling should protect us from diverging.
Authoring in LayoutTests/for-export/w3c/web-platform-tests might not allow
you to use WPT tools and common resources.
At upstream time, reviewers will probably tell to use that and that
existing resource.

There is agreement that a imported/w3c/web-platform-test layout test change
that lands in WebKit can be merged upstreamed.
I am not sure what would be the process with
LayoutTests/for-export/w3c/web-platform-tests tests.


>
> Of course, people could always go run the official copy from w3c-test.org .
> But we usually leave imported conformance test suites unmodified except the
> minimum necessary to make them run.
>
> I would start with an experimental phase with some of us making direct
> changes in LayoutTests/imported/w3c/web-platform-tests/.
> When we are happy with the tools and think the risk for issues is low
> enough (or when the bots can handle most of it for us), hacking
> LayoutTests/imported/w3c/web-platform-tests/ could be the default.
>
>
> I think the problem with this plan is not tools risk, it's the fact that a
> directory of imported tests can no longer be trusted to actually just be
> imported tests. So a smaller number of people doing it to start would not
> address my concern. It might be that other people don't care about this. My
> opinion counts no more than anyone else's, and I'd be interested in hearing
> from others.
>

I am not sure to understand precisely what the consequences of "imported
tests can no longer be trusted to actually just be imported tests" are.
Ideally, a WPT test change landing in WebKit should be merged at the same
time on W3C WPT.

There was a suggestion that LayoutTests/imported/w3c/web-platform-tests be
moved to a shorter path like LayoutTests/web-platform-tests. That would
also make it clear that this folder is not only about one-way-sync.


>
> Regards,
> Maciej
>
>
> Le lun. 15 mai 2017 à 21:02, Ryosuke Niwa <rn...@webkit.org> a écrit :
>
>> Hi all,
>>
>> Youenn is working on a patch to automatically create a GitHub PR to
>> export tests from a WebKit patch which includes changes to
>> web-platform-tests [1].
>>
>> That raises a question as to where we should put new tests or modified
>> tests intended to be exported to web-platform-tests from WebKit.
>>
>> I think the most obviou

Re: [webkit-dev] Another WPT bite

2017-05-15 Thread youenn fablet
It makes sense to run WPT tests as HTTP URLs for conformance/regression
purposes.
It is fine to run WPT tests as file based URLs for development purposes.

Tooling should make it possible to run WPT tests as HTTP URLs for
development purposes with minimum to no cost.
We are not there yet.

Le lun. 15 mai 2017 à 22:08, Anne van Kesteren  a écrit :

> On Tue, May 16, 2017 at 5:45 AM, Ryosuke Niwa  wrote:
> >> I think the main problem with not running a server is that behavior
> >> for file URLs is not defined. And browsers tend to impose different
> >> restrictions there. So you might end up debugging something only to
> >> later found out it didn't work due to file URL restrictions. And you
> >> can't guarantee that something will work from a file URL, because
> >> there's no agreement on what will.
> >
> > That's not an issue with most ref or testharness.js tests which tests
> > WebIDL, CSS OM, etc... because none of them have to do network
> > requests.
>
> Regardless of the feature, there's no defined agreement on how it
> should work when loaded from a file URL. A test author cannot divide
> "this can load from a file URL" from "this needs to be loaded over
> HTTP(S)". Except that loading over HTTP(S) always ought to work as
> that much we've written down in standards.
>
>
> --
> https://annevankesteren.nl/
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Where do we put WPT tests to be exported

2017-05-15 Thread youenn fablet
I see two main cases:
- Writer of the patch is making sure to upstream WPT test changes at WebKit
landing time. It is ok to make the changes directly in
LayoutTests/imported/w3c/web-platform-tests/
- Writer plans to upstream WPT test changes at some point but wants more
time. It is better to develop the tests in LayoutTests/http/wpt and then
migrate them later on.

I would start with an experimental phase with some of us making direct
changes in LayoutTests/imported/w3c/web-platform-tests/.
When we are happy with the tools and think the risk for issues is low
enough (or when the bots can handle most of it for us), hacking
LayoutTests/imported/w3c/web-platform-tests/ could be the default.

Le lun. 15 mai 2017 à 21:02, Ryosuke Niwa  a écrit :

> Hi all,
>
> Youenn is working on a patch to automatically create a GitHub PR to
> export tests from a WebKit patch which includes changes to
> web-platform-tests [1].
>
> That raises a question as to where we should put new tests or modified
> tests intended to be exported to web-platform-tests from WebKit.
>
> I think the most obvious option is to use
> LayoutTests/imported/w3c/web-platform-tests/.  However, in the other
> thread about adopting testharness.js (titled Another WPT bite), Maciej
> briefly expressed the preference for creating a new directory:
> https://lists.webkit.org/pipermail/webkit-dev/2017-May/029022.html
>
> Do other people have strong opinions about this?
>
> - R. Niwa
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=169462
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
I filed https://bugs.webkit.org/show_bug.cgi?id=172068 to track the need
for some extra tooling for HTTP/WPT served tests.
We already gathered information about related requirements & workflows here.
Let's add more there!

Le ven. 12 mai 2017 à 19:50,  a écrit :

>
> 12 мая 2017 г., в 19:38, Brian Burg  написал(а):
>
>
> I think that I explained it very clearly, but let me try again.
>
> When there is a test failure that I need to communicate to others, I say
> something "please open <
> https://trac.webkit.org/export/216812/webkit/trunk/LayoutTests/fast/images/destroyed-image-load-event.html
> >
> in Safari to reproduce". That's very easy to do, and makes it very easy for
> others to work on the issue.
> If your test requires complex setup, like WPT does, then I may not have
> the time to write up complicated steps to reproduce, or the person who gets
> the bug may not have the time to follow them. Those people don't have a
> WebKit checkout, so scripts won't help. This makes the test less effective,
> as problems that it finds are less likely to be addressed.
>
>
> If the person works on WebKit, then it seems unreasonable that they would
> do work without a checkout.
>
>
> It is correct that people who work on WebKit usually have a checkout. So I
> was taking about people who don't work on WebKit.
>
> If they don’t work on WebKit, then you could run wptserve on a machine
> somewhere and link to that copy. We have several servers that exist solely
> to host test content, it doesn’t seem like a big deal to make one of them
> update regularly and relaunch wptserve to pick up test harness changes.
>
>
> Yes, there is a number of things one could do. Those things would work in
> some cases but not in others - I mentioned linking to a stable version that
> won't change, which is something that trac gives us for free, and it would
> be non-trivial to implement otherwise.
>
> In practice, the best approach would be to reduce the test to a minimum
> that doesn't use complex harnesses before ending it over. Everyone likes
> minimal test cases.
>
> - Alexey
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
> On the topic of LayoutTest/imported tests, can someone describe the
> current process of working with LayoutTest/imported?
>
> How do we handle a broken test in our tree?
>
> • Do we modify our expectations?
>
> - If so, how do we remember to change the expectations in a later import?
>
>
If a test breaks, you are supposed to rebase the expected file.
A later import will rebase the expected file.

When importing, some subtests may not be passing.
This is ok, keep the expectation as is and do not add a FAIL line in
TestExpectations.


> • Do we modify the test? More generally, are any modifications allowed
> inside of LayoutTest/imported?
> - If so, how do we track the fact that we have modifications so that a
> later import doesn't just wipe out our changes?
> - Without tooling, is the person who modifies the test responsible for
> making an upstream pull request?
>
>
It is ok to modify the test only if you are making sure the test change is
upstreamed at landing time.
The author of the patch is currently responsible for upstreaming the
changes.
We will make things better in a not-too-far future.



> How do we handle a new imported test that WebKit fails?
>
> To avoid bots being red this test will end up getting skipped or marked as
> flakey.
>
> If it is flaky, mark it as such or mark it as skip
If it is consistently failing, it is doing some level of regression testing.
Another possibility is to not import it at all.
Please use LayoutTests/imported/w3c/resources/import-expectation.json for
that purpose.

How do we ensure this actually gets addressed and not ignored / forgotten
> about?
>
>
This is currently the responsibility of the developer doing the feature
work.
When a feature is complete, we should look at how much tests are passing
vs. skipped/failing.
This is conformance testing, we can use our own copy of WPT or W3C one.


>
> To make upstream changes someone has to make a pull-request:
>
>
> I've had some upstream patches reviewed immediately and others are still
> in review after 3+ months.
>
> In an earlier webkit-dev email Youenn mentioned:
> https://lists.webkit.org/pipermail/webkit-dev/2017-April/028932.html
>
> As done by other browser teams, a test that is reviewed in WebKit bugzilla
> and
>
> landed in WebKit can be readily merged into WPT without additional review
>
> (although additional review is always great!).
>
>
> I don't have commit access to the WPT GitHub. So ultimately I still have
> to go through another review to get my pull requests accepted.
>
>
You might get commit access.
Otherwise, some WebKit members have it and will do the cq for you.
Please ping me for that purpose. I am sure others might help too.

>
> - Joe
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
I would guess Chromium and Mozilla to have the same issues there.
Incidentally, some work is being done right now to ease the
run-a-server-then-launch-a-browser thing.
We should be able to piggy-back on that effort and also handle the same
thing for LayoutTetsts/http/tests.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
Filed https://github.com/w3c/web-platform-tests/issues/5909 and
https://github.com/w3c/web-platform-tests/issues/5910.


Le ven. 12 mai 2017 à 12:08, Rick Byers <rby...@chromium.org> a écrit :

> On Fri, May 12, 2017 at 2:43 PM, youenn fablet <youe...@gmail.com> wrote:
>
>>
>> Le ven. 12 mai 2017 à 11:07, Alexey Proskuryakov <a...@webkit.org> a
>> écrit :
>>
>>>
>>> 9 мая 2017 г., в 11:27, Simon Fraser <simon.fra...@apple.com>
>>> написал(а):
>>>
>>>
>>> Another consideration here is "would my test be useful for other browser
>>> vendors". I don't think the answer is a unanimous "yes", so I think we
>>> should only use WPT for tests that will think are worth sharing.
>>>
>>>
>>> Since imported WPT tests are very flaky, and are not necessarily written
>>> to defend against important regressions, investigating issues with them is
>>> relatively lower priority than investigating issues observed with WebKit
>>> tests. So I would recommend not mixing tests for WebKit regressions with
>>> WPT tests - if your test eventually ends up in LayoutTests/imported, it
>>> will become a lot less effective.
>>>
>>
>> WPT tests are flaky in WebKit because WPT stability bots do not run yet
>> Safari, and most tests are written in non-WebKit environment.
>> Often, it is due to the fact that tests are not passing and flakiness is
>> only seen with failing assertions.
>>
>> From my experience with fetch API tests, I disagree that broken WPT tests
>> are lower priority.
>> I think it will change as more WebKit contributors will author WPT tests.
>>
>> I agree that tests doing subtle WebKit-specific regression checks are not
>> good candidates for WPT upstream.
>> When the test is all about conformance with a spec, it is a very good
>> candidate.
>>
>>
>>> Using the complicated harness has a similar consequence - if you use any
>>> WPT goodies like templates or server side scripts, the cost of
>>> investigating issues on the test increases, and makes the test less
>>> valuable.
>>>
>>
>> It is true that WPT put some emphasis on easing authoring of tests.
>> I guess there is a learning curve here in WPT test debugging.
>>
>> If you have a file with 20 tests, it is harder to debug.
>> It is also increasing the chances for flakiness/timeouts.
>> Maybe we could send that feedback.
>>
>> WPT infra could also be improved: more verbose debug-only output,
>> enabling running selected subtest only...
>> testharness.js is actively maintained and is continuously improving.
>> Since we have specific requirements as you are describing, we should push
>> them.
>>
>
> Concretely, please file issues with the "infra" label
> <https://github.com/w3c/web-platform-tests/issues?q=is%3Aissue+is%3Aopen+label%3Ainfra>
>  to
> track upstream WPT infrastructure bugs and feature requests.  Google has an
> ongoing contract with Bocoup (Bob and Mike cc'd) who are improving the
> infrastructure every day.  Of course there's an opportunity to make it even
> better fast with more funding from additional organizations who would
> benefit :-)
>
>>
>> I don't know if there is any way to adopt WPT that won't make testing
>>> less effective. WPT tests may be useful in very rare cases, where we
>>> actively want to communicate certain subtle behavior details to other
>>> vendors - but even so, I imagine that other vendors may not put high
>>> priority on those, for the same reasons.
>>>
>>
>> My own experience is that WPT tests are actually very valuable, at least
>> when we are talking about interoperability/spec conformance.
>> I also see WPT as an efficient way to author tests.
>>
>>
>>>
>>> - Alexey
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
Le ven. 12 mai 2017 à 11:07, Alexey Proskuryakov  a écrit :

>
> 9 мая 2017 г., в 11:27, Simon Fraser  написал(а):
>
>
> Another consideration here is "would my test be useful for other browser
> vendors". I don't think the answer is a unanimous "yes", so I think we
> should only use WPT for tests that will think are worth sharing.
>
>
> Since imported WPT tests are very flaky, and are not necessarily written
> to defend against important regressions, investigating issues with them is
> relatively lower priority than investigating issues observed with WebKit
> tests. So I would recommend not mixing tests for WebKit regressions with
> WPT tests - if your test eventually ends up in LayoutTests/imported, it
> will become a lot less effective.
>

WPT tests are flaky in WebKit because WPT stability bots do not run yet
Safari, and most tests are written in non-WebKit environment.
Often, it is due to the fact that tests are not passing and flakiness is
only seen with failing assertions.

>From my experience with fetch API tests, I disagree that broken WPT tests
are lower priority.
I think it will change as more WebKit contributors will author WPT tests.

I agree that tests doing subtle WebKit-specific regression checks are not
good candidates for WPT upstream.
When the test is all about conformance with a spec, it is a very good
candidate.


> Using the complicated harness has a similar consequence - if you use any
> WPT goodies like templates or server side scripts, the cost of
> investigating issues on the test increases, and makes the test less
> valuable.
>

It is true that WPT put some emphasis on easing authoring of tests.
I guess there is a learning curve here in WPT test debugging.

If you have a file with 20 tests, it is harder to debug.
It is also increasing the chances for flakiness/timeouts.
Maybe we could send that feedback.

WPT infra could also be improved: more verbose debug-only output, enabling
running selected subtest only...
testharness.js is actively maintained and is continuously improving.
Since we have specific requirements as you are describing, we should push
them.

I don't know if there is any way to adopt WPT that won't make testing less
> effective. WPT tests may be useful in very rare cases, where we actively
> want to communicate certain subtle behavior details to other vendors - but
> even so, I imagine that other vendors may not put high priority on those,
> for the same reasons.
>

My own experience is that WPT tests are actually very valuable, at least
when we are talking about interoperability/spec conformance.
I also see WPT as an efficient way to author tests.


>
> - Alexey
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-11 Thread youenn fablet
Patch just landed.
Location is LayoutTests/http/wpt.
I also forgot to say that, should you want to write http served tests, it
might make sense to use this folder instead of http/tests.
   Y

Le jeu. 11 mai 2017 à 19:05, Sam Weinig <wei...@apple.com> a écrit :

>
> On May 8, 2017, at 9:31 PM, youenn fablet <youe...@gmail.com> wrote:
>
> Hi all,
>
> Discussing with some WebKittens, testharness.js is more and more used in
> WebKit.
> Is it time to make testharness.js the recommended way of writing
> LayoutTests?
>
>
> I am in favor of this. If we simplified the question to some form of, “do
> we really need both testharness.js/testharnessreport.js and 
> js-test-pre.js/js-test-post.js?”
> I am even more in favor, as having two test harnesses seems unnecessary,
> cumbersome and unfriendly to new contributors,
>
> Do I think all tests should use testharness.js? No. Just as currently I
> don’t think all tests should use testharness.js/testharnessreport.js. But
> for many tests of new web platform features, it seems quite reasonable to
> start using this harness, as the benefits, which include a good feature
> set, easier interoperability with other browsers, and a reduced cost to
> upstreaming to web-platform-tests, out weigh the costs, leaning something
> new (there are probably other costs I am forgetting).
>
>
> To continue moving forward, some of us are proposing to serve all tests in
> LayoutTests/wpt through the WPT server [1].
> This would serve some purposes like increasing the use of WPT goodies:
> file-specific headers, templated tests (*.any.js), IDLParser, server-side
> scripts...
> It could also ease test migration from WebKit to W3C WPT.
>
>
> This seems uncontroversial and great to me (which would make sense since I
> asked you if we could do it).  It’s just a new directory, like
> LayoutTests/http where we can put tests that use the WPT server.
>
> - Sam
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-09 Thread youenn fablet
> Another consideration here is "would my test be useful for other browser
> vendors". I don't think the answer is a unanimous "yes", so I think we
> should only use WPT for tests that will think are worth sharing.
>

Agreed that some tests, especially the ones dedicated to WebKit
specificities should be kept in WebKit.
The risk is that these changes might be changed upstreamed in
small/stylistic ways and no longer cover the initial case.

That does not prevent to use WPT infrastructure for these tests, especially
if it eases authoring.
As a temporary measure, Chris mentioned the possibility to have inside the
WPT folder a folder dedicated to "to-be-upstreamed" tests.


> I'm also concerned that with 4 vendors upstreaming their WPT tests, the
> WPT repo will just become a morass of partially overlapping tests that
> takes 4x longer to run than a curated repo.
>

This is an issue in WebKit repository as well.
I saw some clean-up done in WPT though.
Sharing this goal and effort amongst the different communities might end up
with a better result.
Note also that spec editors are usually involved in WPT, which might help
organizing the test suites in better ways.


Simon
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-09 Thread youenn fablet
>
>
> Besides other issues mentioned, testharness tends to result in more
> verbose tests compared to js-test, at least for simple cases.
>

For synchronous tests, I am not sure there is any big difference one way or
the other.
With asynchronous tests, it might be true, but using
testharness.js/promise_test usually improves things there.
 I personally find it easier to not wrap code-to-be-tested into quotes.

Another concern is the lack of verbose output which reduces the ability to
debug failing tests.
This can be partially fixed by authoring tests with that issue in mind.
For instance, having a big promise_test to handle the asynchronous aspect
of a test and nested test() inside it.

The thing I specifically asked Youenn to ask is, whether we should
> place a test inside LayoutTests/wpt like LayoutTests/http/tests when
> we want to write a test using testharness.js which requires some sort
> of network code.
>
> Since people have had some opinions about directory structures in the past.
>
>
> It seems like we need a few different directories, here are my opinions on
> them:
>
> (1) Imported web platform tests that don't need a server
> Currently LayoutTests/imported/w3c/web-platform-tests, which seems
> fine.
>

All WPT tests are expected to run behind the WPT server.
That is the way tests are authored and tested elsewhere.
If we have an issue with that, it is best to bring that and fix that
directly in WPT.
I encountered several times small issues due to file:// based origins which
makes me think defaulting to http is a safe choice.

One concern is efficiency. We should study that and improve on that.
Another concern is the ease of running tests for developers: drag
tests into a browser instead of running a server.
We can partially accommodate this by rewriting
testharness.js/testharnessreport.js urls.
A significant and growing amount of wpt tests will not behave as expected
(other resources loaded, origins, need for specific headers, need for
https...)

(2) Imported web platform tests that do need a server
> Probably should be under LayoutTests/imported/w3c/ somewhere, or maybe
> under http/tests/ per point (4)
>

I don't think this will work, web-platform-tests is organized in terms of
features.
There is no clear separation between file based compatible tests and http
based tests like in WebKit.

(3) Custom testharness.js tests that don't need a server
> Probably these should just go in their normal topic-specific
> directories and should not need a special directory
>

Right.
The only case where it might make sense to put such tests in a specific
WPT-enabled directory is if the plan is to upstream these tests at some
point.
Such tests could be added in imported/w3c/web-platform-tests directly but
this requires coordination with resyncing tests at the moment.
In a not-too-far-future, I hope such tests would directly be authored in
imported/w3c/web-platform-tests.


> (4) Custom testharness.js tests that do need a server
> Can these just be a subdirectory of http/tests/? We have websocket and
> ssl/tls tests in there too. Would be nice to not need a separate directory
> for networking tests that to use a particular test framework.
>

I do not have strong feelings there, http/wpt might make sense if it is
found easier to understand to everybody.
I'll update the patch accordingly and will land it sometimes this week if
there is no additional feedback.

Thanks!
   y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Another WPT bite

2017-05-08 Thread youenn fablet
testharness.js does not need an http server. Some WPT goodies need the WPT
server.

I agree different frameworks offer different benefits. There is no reason
we should mandate one framework in particular.

In case there is no specific needs, it makes sense to me to recommend using
testharness.js, at least for those hacking WebCore. Chances are high that
another browser community might like running (and improving and
maintaining) it.
Chances are also high that one will have to debug/update such tests, so it
is good to learn this framework anyway.
Le lun. 8 mai 2017 à 22:17, Brady Eidson <beid...@apple.com> a écrit :

> On May 8, 2017, at 9:31 PM, youenn fablet <youe...@gmail.com> wrote:
>
> Hi all,
>
> Discussing with some WebKittens, testharness.js is more and more used in
> WebKit.
> Is it time to make testharness.js the recommended way of writing
> LayoutTests?
>
>
> Setting aside the pros or cons of testharness.js itself, I disagree with
> the principle of "1 single way to write all regression tests"
>
> In the past 11 years I've heard from multiple members of the team
> commenting on the benefits of different people writing regression tests in
> their own styles using their own techniques. We're capable of covering more
> edge cases when we don't have enforced uniformity. And I agree
> wholeheartedly.
>
> But now talking about testharness.js directly, I object on the grounds of
> "a file:// regression test is dirt easy to hack on and work with, whereas
> anything that requires me to have an httpd running is a PITA"
>
> Note: I don't intend for any of this to mean I discourage the use of
> testharness.js tests. I don't. By all means, write them.
>
> I just object to making it the "recommended way" of writing tests.
>
> Thanks,
>  Brady
>
>
> To continue moving forward, some of us are proposing to serve all tests in
> LayoutTests/wpt through the WPT server [1].
> This would serve some purposes like increasing the use of WPT goodies:
> file-specific headers, templated tests (*.any.js), IDLParser, server-side
> scripts...
> It could also ease test migration from WebKit to W3C WPT.
>
> Some rules can guide whether adding tests to LayoutTests/wpt or
> LayoutTests/imported/w3c/web-platform-tests:
> - WebKit specific tests (crash tests, tests using internals...) in
> LayoutTests/wpt
> - Spec conformance/interoperability tests in
> LayoutTests/imported/w3c/web-platform-tests
>
>y
>
> [1]: bug 171479 <https://bugs.webkit.org/show_bug.cgi?id=171479>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Another WPT bite

2017-05-08 Thread youenn fablet
Hi all,

Discussing with some WebKittens, testharness.js is more and more used in
WebKit.
Is it time to make testharness.js the recommended way of writing
LayoutTests?

To continue moving forward, some of us are proposing to serve all tests in
LayoutTests/wpt through the WPT server [1].
This would serve some purposes like increasing the use of WPT goodies:
file-specific headers, templated tests (*.any.js), IDLParser, server-side
scripts...
It could also ease test migration from WebKit to W3C WPT.

Some rules can guide whether adding tests to LayoutTests/wpt or
LayoutTests/imported/w3c/web-platform-tests:
- WebKit specific tests (crash tests, tests using internals...) in
LayoutTests/wpt
- Spec conformance/interoperability tests in
LayoutTests/imported/w3c/web-platform-tests

   y

[1]: bug 171479 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ccache on mac

2017-05-07 Thread youenn fablet
I had this setup working a year or so ago. I was using the regular Mac
"make" build.

Le dim. 7 mai 2017 à 19:28, Ben Kelly  a écrit :

> Hi all,
>
> Does anyone have ccache (or an equivalent) working with local webkit
> builds on mac?  I've spent the last couple of days trying to figure out,
> but have not had much luck.
>
> I've installed ccache via homebrew and its in my path.
>

Did the same. I had to ensure clang used by Xcode was the ccache proxy.
Don't remember whether just setting CC/CXX in the command line works.
When running make, you can see which clang is used.
Maybe setting CC/CXX in Source/WebCore/Configurations/Base.xcconfig would
do the trick (for WebCore).


> I *do* see ccache being used if I do a `webkit-build --cmake`, but I can't
> use run-safari or run-webkit-tests with a cmake build.  I get an error like:
>
>   Can't find built framework at
> "/srv/WebKit/WebKitBuild/dev/Debug/JavaScriptCore.framework/Versions/A/JavaScriptCore".
>

I think the CMake build is not complete in terms of executable. It would be
great if we could finalize it.
Alex knows a lot about this.


> If I do a non-cmake build I can successfully use run-safari and
> run-webkit-tests, but it appears ccache is not used.  It looks like its
> going through the xcode CLI tools.  I've searched for how to configure
> xcode to use ccache, but everything suggests I need to hand modify the
> project xcconfig.
>
> Can anyone recommend a good way to get local builds that work with
> run-safari/run-webkit-tests and that use ccache?
>
> (FWIW, the main reason I want ccache is that touching any idl file appears
> to trigger a rebuild of most of WebCore.)
>

Right, this is a known limitation of the current build system and something
that would be good to improve on.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting WPT tests

2017-04-28 Thread youenn fablet
Hi Mike,

Thanks for the information.
It is really great to see Safari be integrated in the bots :)
https://cs.chromium.org/chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/w3c/wpt_github.py
seems
like a really good potential candidate for WPT upstream.
y

Le ven. 28 avr. 2017 à 08:25, Mike Pennisi  a écrit :

> Hi Youenn. My name is Mike, and I've been working with Google for the past
> 4
> months or so to improve various aspects of the Web Platform Tests
> project (more
> on that here [1]).
>
>  > The only constraint I know of is that the test does not give flaky
> tests from
>  > WPT Chrome/Firefox bots.
>
> The full set of validation steps are described in the project's
> `.travis.yml`
> file [2]. That's a bit tough to read even if you're familiar with
> TravisCI (we're
> working on it!), but from WebKit's perspective, the only other relevant
> check
> is for file linting. It's not very opinionated (mostly limited to objective
> concerns) but still something to be aware of.
>
> Also note that we're very close to including both Edge and Safari in the
> set of
> browsers used to identify flaky tests! [3]
>

>  > We do not have yet the tooling to automate the creation of a WPT
> GitHub PR
>  > from a WebKit patch that lands.
>
> I've recently been migrating tests for Service Workers from the Chromium
> project to WPT. The process in place there is pretty slick. (Context for
> other
> folks on the list: it's able to create commits that exclude
> Chromium-specific
> files [4] and then submit GitHub pull requests from those, merging when CI
> passes [5]. The patch Youenn mentioned is based on those files.)
>
> I'm wondering if we can avoid duplicating effort by making a standalone
> tool.
> It might even be the kind of thing we could host in the W3C GitHub
> organization--whose to say that Edge (for example) wouldn't benefit from
> that,
> too? I would love to be involved in that implementation.
>
> But I'm getting ahead of myself :) I've CC'd Jeff Carp and Quinten
> Yearsley of
> the Chromium team since they are currently working with that tooling.
>
> So what do you folks think? Would it be practical to share code like this?
>
> [1] https://bocoup.com/blog/diving-into-the-web-platform-tests
> [2] https://github.com/w3c/web-platform-tests/blob/master/.travis.yml
> [3] https://github.com/w3c/web-platform-tests/pull/5231
> [4]
>
> https://cs.chromium.org/chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/w3c/chromium_commit.py
> [5]
>
> https://cs.chromium.org/chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/w3c/wpt_github.py
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Exporting WPT tests

2017-04-24 Thread youenn fablet
Hi all,

After talking with some WebKittens, I'd like to discuss the process of
upstreaming WPT tests from WebKit. Here is my take of it.

WPT tests need a review before being merged.
This review can be done in WPT GitHub at PR time.
This review can also be done as part of the usual WebKit review flow.

As done by other browser teams, a test that is reviewed in WebKit bugzilla
and landed in WebKit can be readily merged into WPT without additional
review (although additional review is always great!).
The only constraint I know of is that the test does not give flaky tests
from WPT Chrome/Firefox bots.

We do not have yet the tooling to automate the creation of a WPT GitHub PR
from a WebKit patch that lands.
In the meantime, for those of us planning to contribute to WPT, it might
make sense to start using a consistent flow.
How about marking explicitly the PRs as coming from WebKit in the title,
with the related bugzilla URL in the comment?
Patch at https://bugs.webkit.org/show_bug.cgi?id=169462 might be handy for
that.
When done so, how about allowing any WebKitten with WPT repository merge
access to merge those PRs without further review?

It might (and did) happen that a proposed test is conforming to the spec
but the spec is expected to change at some point.
I don't think we should refrain from landing such test in WPT.
A test exercising the currently described behavior is a good thing anyway.
It might actually ease the job of those who will later need to provide a
test that will cover the spec change.

Thanks
y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Cleaning-up WPT tests

2017-04-23 Thread youenn fablet
Hi all,

I am planning to remove tests in
LayoutTests/imported/w3c/web-platform-tests that are no longer in W3C
GitHub repository.
Some of these tests are either added directly in WebKit repository and not
yet upstreamed to the GitHub repository.
Please PM me if you know such tests.

Some of these obsolete tests come from the fact of importing them without
the test importer script.
Please try to stick with Tools/Scripts/import-w3c-tests and let me know if
there is any issue with it.

By the way, there is a new
script Tools/Scripts/update-test-expectations-from-bugzilla which allows
updating test expectations based on EWS bot results posted on bugzilla.
Mac-wk2 is used as the platform for generic expectations. Again, let me
know if there is any issue with it.

Thanks
   y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] First stab at exporting tests to WPT

2017-03-22 Thread youenn fablet
Yes, Mozilla and Chromium are doing two-side synchronization, with
different variants.
The current strategy here is doing export on a per-bug basis.


Le mer. 22 mars 2017 à 08:06, Anne van Kesteren  a écrit :

> On Wed, Mar 22, 2017 at 3:55 PM, Alexandre GOUAILLARD
>  wrote:
> > that s great to have now chrome AND webkit doing it. I hope mozilla and
> the
> > other will follow, as discussed on the side of BlinkOn last year.
>
> FWIW, Mozilla already periodically synchronizes with WPT. Think we
> were first even.
>
>
> --
> https://annevankesteren.nl/
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] First stab at exporting tests to WPT

2017-03-22 Thread youenn fablet
Hi,

I started writing a script to automate PRs to W3C WPT Github repository at
https://bugs.webkit.org/show_bug.cgi?id=169462.
One can author changes directly to
LayoutTests/imported/w3c/web-platform-tests and use the script to create a
branch on your GitHub WPT clone and also the PR from it on W3C WPT
repository.

If you are interested, please have a try and contact me for any feedback or
issue you may have.

I may also be interested in hearing about any change you may have wanted to
do on W3C tests to accommodate WebKit test environment (e.g. use of
internals API, runtime flags...).

Thanks
   y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Importing tests from web-platform-tests

2017-02-15 Thread youenn fablet
Hi Yoav,

For existing preload tests, you may want to use DumpJSConsoleLogInStdErr if
the warnings appear in the console log.
For testing unused preloads warnings, it may be better to use non WPT tests
atm.

   y

Le mer. 15 févr. 2017 à 05:00, Yoav Weiss  a écrit :

> I'm trying to import tests from web-platform-tests/preload
> , but
> having trouble getting them to run without requiring expected results and
> while using wptserve.
>
> I looked at the WPT import tutorial
>  but failed to find a way
> to do what I need.
>
> The reason I don't want to rely on expected tests is that I'm trying to
> add a warning for unused preloads
> , and these warnings can
> make expected results flaky. While I can work around it in most cases (by
> using the preloads in my layout tests), a way to stop relying on
> expected.txt for tests that don't need it would be cleaner.
>
> Thanks,
> Yoav
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-02-07 Thread youenn fablet
I filed https://bugs.webkit.org/show_bug.cgi?id=167938 for the submodules
issue.

Le lun. 6 févr. 2017 à 17:15, Alexey Proskuryakov  a écrit :

>
> 6 февр. 2017 г., в 12:28, Ryosuke Niwa  написал(а):
>
>
> The concern I've heard about is not how run-webkit-tests run the tests.
> It's about how a test is opened inside a browser, DRT, WTR while debugging.
>
>
> +1
>
> I think that making web platform tests more practical for engineers to
> work with should be a pre-requisite for deeper integration.
>
> From tools perspective, cleaning up the way we get supporting scripts for
> web platform tests would be quite beneficial too. It is very hard to reason
> about what happens in a merge that just updates .tar.gz files or a SHA hash.
>
> - Alexey
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-02-07 Thread youenn fablet
Yes, let's continue this discussion on bugzilla.

Le lun. 6 févr. 2017 à 16:32, Ryosuke Niwa <rn...@webkit.org> a écrit :

> On Mon, Feb 6, 2017 at 4:22 PM, youenn fablet <youe...@gmail.com> 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 generate WPT PR requests from a WebKit repo.
>
>
> I think we need to first agree on where to put new tests. If we're placing
> next to existing tests inside LayoutTests/imported/w3c/web-platform-tests/
> then identifying those new tests will be an issue.
>
> Also, there needs to be a mechanism to detect these new tests that have
> been merged into upstream when we're re-importing. It's possible for tests
> newly added in WebKit to be renamed, moved, or otherwise modified before we
> re-import them back.
>
> All these situations need to be carefully thought out first.
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-02-06 Thread youenn fablet
I filed https://bugs.webkit.org/show_bug.cgi?id=167911.

Le lun. 6 févr. 2017 à 16:22, youenn fablet <youe...@gmail.com> a écrit :

> 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 generate WPT PR requests from a WebKit repo.
>
> Le lun. 6 févr. 2017 à 12:28, Ryosuke Niwa <rn...@webkit.org> a écrit :
>
>
> On Monday, February 6, 2017, youenn fablet <youe...@gmail.com> wrote:
>
> The two complaints I heard against testharness.js are:
>
> - They are less easy to debug as test harness.js does not print out
> messages for each assert. There might be room for updating testharness to
> support that
> - Async tests are less easy to write. While this is probably true,
> testharness has support for promise-based tests which are not verbose.
> WPT has also some benefits of its own, like the possibility to run easily
> the same tests in worker/window environments, the flexible python-based
> server...
>
> One complaint I heard against WPT tests is that they require being run
> behind a server.
> This is becoming more and more true.
> There is still a large portion of tests that could be run locally if we
> update the paths to test harness.js/testharnessreport,js.
> I am not a big fan of modify any WPT test but maybe we should consider
> switching back to modifying these paths at import and export time.
>
>
> We should probably do this for the sake of making tests more debuggable.
> Having to run a HTTP/HTTPS server makes testing WebCore against a test
> needlessly harder especially for things like core DOM API which doesn't
> require any network stack.
>
>
> Or we could make our tooling better to also handle LayoutTests/http tests
> more easily.
> In any case, our CI infrastructure should run WPT tests as closely as
> specified by WPT.
>
>
> The concern I've heard about is not how run-webkit-tests run the tests.
> It's about how a test is opened inside a browser, DRT, WTR while debugging.
>
>
> I would tend to do the following:
> - Write/submit WPT tests in WebKit as regular WebKit testharness.js layout
> tests through bugzilla
> - At commit queue time, automatically create a PR to WPT GitHub containing
> the changes of the WebKit patch
>
>
> I think commit queue time is too late. Remember that not everyone uses
> commit queue. Also, if there was any issue with a test, we should be able
> to tell that prior to landing the patch.
>
>
> Ideally, having one EWS bullet/bot capturing/handling PR status would be
> very good.
> Knowing the state of a test from various browsers would be helpful at
> review time.
>
> But this might require some extra work to support PR updates and so on.
> CQ time seems like a reasonable target for step 1.
> Well, step 0 might be to have a script that committers would run
> themselves locally.
>
>
> Again, many people don't use CQ. What do those people do? Manually run a
> script? I don't think that's a workable solution. There are many people
> just land patches from Xcode UI for example.
>
> In general, I don't think it's acceptable to introduce any extra step for
> WebKit contributors. Let it be running a new script, potentially fix an
> issue in GitHub PR, etc...
>
> There should be absolutely no new thing contributor has to run or monitor.
> That should be the minimum bar for this upstreaming system to exist.
>
> Again, we can't even keep up with test failures on our own bots, and
> people frequently land patches with broken tests or tests that fail on some
> bots. There is no way we can succeed by introducing yet another step /
> place humans has to care. That's simply unacceptable.
>
> - Ask committer to fix the WPT PR should there be any issue with it
> (committer being informed of such issues through bugzilla).
>
>
> I think this is too much of an overhead / a burden for WebKit
> contributors. Now patch contributors need to worry about EWS,
> build.webkit.org, and some random PR that gets created on Github failing.
>
>
> Contributors would just need to worry about monitoring bugzilla, like they
> are doing for EWS/CQ.
>
>
> It depends on what kind of "monitoring" is required.
>
>
> The number of conflicts should be fairly small hopefully.
> I am not sure that we can come up with a solution that would handle
> conflicts automatically.
>
>
> In the case of a conflict, the patch should be rejected in EWS & CQ just
> the same way a WebKit patch conflict would.
>
> - R. Niwa
>
>
> --
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-02-06 Thread youenn fablet
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 generate WPT PR requests from a WebKit repo.

Le lun. 6 févr. 2017 à 12:28, Ryosuke Niwa <rn...@webkit.org> a écrit :

>
> On Monday, February 6, 2017, youenn fablet <youe...@gmail.com> wrote:
>
> The two complaints I heard against testharness.js are:
>
> - They are less easy to debug as test harness.js does not print out
> messages for each assert. There might be room for updating testharness to
> support that
> - Async tests are less easy to write. While this is probably true,
> testharness has support for promise-based tests which are not verbose.
> WPT has also some benefits of its own, like the possibility to run easily
> the same tests in worker/window environments, the flexible python-based
> server...
>
> One complaint I heard against WPT tests is that they require being run
> behind a server.
> This is becoming more and more true.
> There is still a large portion of tests that could be run locally if we
> update the paths to test harness.js/testharnessreport,js.
> I am not a big fan of modify any WPT test but maybe we should consider
> switching back to modifying these paths at import and export time.
>
>
> We should probably do this for the sake of making tests more debuggable.
> Having to run a HTTP/HTTPS server makes testing WebCore against a test
> needlessly harder especially for things like core DOM API which doesn't
> require any network stack.
>
>
> Or we could make our tooling better to also handle LayoutTests/http tests
> more easily.
> In any case, our CI infrastructure should run WPT tests as closely as
> specified by WPT.
>
>
> The concern I've heard about is not how run-webkit-tests run the tests.
> It's about how a test is opened inside a browser, DRT, WTR while debugging.
>
>
> I would tend to do the following:
> - Write/submit WPT tests in WebKit as regular WebKit testharness.js layout
> tests through bugzilla
> - At commit queue time, automatically create a PR to WPT GitHub containing
> the changes of the WebKit patch
>
>
> I think commit queue time is too late. Remember that not everyone uses
> commit queue. Also, if there was any issue with a test, we should be able
> to tell that prior to landing the patch.
>
>
> Ideally, having one EWS bullet/bot capturing/handling PR status would be
> very good.
> Knowing the state of a test from various browsers would be helpful at
> review time.
>
> But this might require some extra work to support PR updates and so on.
> CQ time seems like a reasonable target for step 1.
> Well, step 0 might be to have a script that committers would run
> themselves locally.
>
>
> Again, many people don't use CQ. What do those people do? Manually run a
> script? I don't think that's a workable solution. There are many people
> just land patches from Xcode UI for example.
>
> In general, I don't think it's acceptable to introduce any extra step for
> WebKit contributors. Let it be running a new script, potentially fix an
> issue in GitHub PR, etc...
>
> There should be absolutely no new thing contributor has to run or monitor.
> That should be the minimum bar for this upstreaming system to exist.
>
> Again, we can't even keep up with test failures on our own bots, and
> people frequently land patches with broken tests or tests that fail on some
> bots. There is no way we can succeed by introducing yet another step /
> place humans has to care. That's simply unacceptable.
>
> - Ask committer to fix the WPT PR should there be any issue with it
> (committer being informed of such issues through bugzilla).
>
>
> I think this is too much of an overhead / a burden for WebKit
> contributors. Now patch contributors need to worry about EWS,
> build.webkit.org, and some random PR that gets created on Github failing.
>
>
> Contributors would just need to worry about monitoring bugzilla, like they
> are doing for EWS/CQ.
>
>
> It depends on what kind of "monitoring" is required.
>
>
> The number of conflicts should be fairly small hopefully.
> I am not sure that we can come up with a solution that would handle
> conflicts automatically.
>
>
> In the case of a conflict, the patch should be rejected in EWS & CQ just
> the same way a WebKit patch conflict would.
>
> - R. Niwa
>
>
> --
> - R. Niwa
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-02-06 Thread youenn fablet
The two complaints I heard against testharness.js are:

> - They are less easy to debug as test harness.js does not print out
> messages for each assert. There might be room for updating testharness to
> support that
> - Async tests are less easy to write. While this is probably true,
> testharness has support for promise-based tests which are not verbose.
> WPT has also some benefits of its own, like the possibility to run easily
> the same tests in worker/window environments, the flexible python-based
> server...
>
> One complaint I heard against WPT tests is that they require being run
> behind a server.
> This is becoming more and more true.
> There is still a large portion of tests that could be run locally if we
> update the paths to test harness.js/testharnessreport,js.
> I am not a big fan of modify any WPT test but maybe we should consider
> switching back to modifying these paths at import and export time.
>
>
> We should probably do this for the sake of making tests more debuggable.
> Having to run a HTTP/HTTPS server makes testing WebCore against a test
> needlessly harder especially for things like core DOM API which doesn't
> require any network stack.
>

Or we could make our tooling better to also handle LayoutTests/http tests
more easily.
In any case, our CI infrastructure should run WPT tests as closely as
specified by WPT.


> I would tend to do the following:
> - Write/submit WPT tests in WebKit as regular WebKit testharness.js layout
> tests through bugzilla
> - At commit queue time, automatically create a PR to WPT GitHub containing
> the changes of the WebKit patch
>
>
> I think commit queue time is too late. Remember that not everyone uses
> commit queue. Also, if there was any issue with a test, we should be able
> to tell that prior to landing the patch.
>

Ideally, having one EWS bullet/bot capturing/handling PR status would be
very good.
Knowing the state of a test from various browsers would be helpful at
review time.

But this might require some extra work to support PR updates and so on.
CQ time seems like a reasonable target for step 1.
Well, step 0 might be to have a script that committers would run themselves
locally.


> - Ask committer to fix the WPT PR should there be any issue with it
> (committer being informed of such issues through bugzilla).
>
>
> I think this is too much of an overhead / a burden for WebKit
> contributors. Now patch contributors need to worry about EWS,
> build.webkit.org, and some random PR that gets created on Github failing.
>

Contributors would just need to worry about monitoring bugzilla, like they
are doing for EWS/CQ.
The number of conflicts should be fairly small hopefully.
I am not sure that we can come up with a solution that would handle
conflicts automatically.


> The fact people have to worry about EWS & build.webkit.org separately is
> bad enough. We shouldn't be introducing yet another place people have to
> monitor / care about.
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-02-05 Thread youenn fablet
I too am a big proponent of us moving more and more towards WPT.
As part of the streams and fetch API implementation, most of the related
functional tests have been made as WPT.
The benefits of having tests being improved and updated largely outweighs
the testharness.js initial cost.
Somehow, these tests are becoming part of their related specs.

The two complaints I heard against testharness.js are:
- They are less easy to debug as test harness.js does not print out
messages for each assert. There might be room for updating testharness to
support that
- Async tests are less easy to write. While this is probably true,
testharness has support for promise-based tests which are not verbose.
WPT has also some benefits of its own, like the possibility to run easily
the same tests in worker/window environments, the flexible python-based
server...

One complaint I heard against WPT tests is that they require being run
behind a server.
This is becoming more and more true.
There is still a large portion of tests that could be run locally if we
update the paths to test harness.js/testharnessreport,js.
I am not a big fan of modify any WPT test but maybe we should consider
switching back to modifying these paths at import and export time.

I would also like to go in a direction where writing WPT tests is the
default for WebKit layout test.
For that to happen, we need an easy way to upstream tests from WebKit to
WPT GitHub.

I would tend to do the following:
- Write/submit WPT tests in WebKit as regular WebKit testharness.js layout
tests through bugzilla
- At commit queue time, automatically create a PR to WPT GitHub containing
the changes of the WebKit patch
- Ask committer to fix the WPT PR should there be any issue with it
(committer being informed of such issues through bugzilla).

Le dim. 5 févr. 2017 à 15:42, Ryosuke Niwa  a écrit :

> Hi all,
>
> *Background*
>
> Web Platform Tests is a suite of tests written for W3C specifications
> =,
> and Blink, Edge, Gecko, and WebKit all run them as a part of their
> continuous build system.
>
> Historically, each working group had their own repository for tests,
> but with CSS WG's tests  finally
> getting merged into the Web Platform Tests,
> we will have a single repository with all the tests from W3C.
>
> A few of us attended a meeting to discuss the future of this test suite
> 
> last Monday.
> One of the major topic was that Blink and Gecko have adopted the process
> to write the tests
> using testharness.js in their own test suites, and automatically merge
> into Web Platform Tests
> without having to go through another round of code review for Web Platform
> Tests.
>
> Given we do test-driven development in WebKit, I think WebKit should do
> the same.
> This will benefit other browser vendors to catch their bugs with our
> tests, and we will also benefit
> from other browser vendors "reviewing" our tests against their
> implementation and specifications.
>
> In the long term, I believe this will drastically improve the
> interoperability of the Web,
> and dramatically improve the quality of the tests we run against WebKit.
>
> In fact, there was a general consensus that we should even upstream
> pass-if-not-crash tests
> as well as style and layout invalidation tests to web-platform-tests as
> they tend to be undertested
> right now and almost all engines have bugs in this area.
>
> *Problems & Questions*
>
> In order to auto-merge tests from WebKit to Web Platform Tests, there are
> a few problems.
>
> *1. We need to start writing more if not all tests using testharness.js
> instead of our own js-test(-pre).js*
>
> I've heard of many complaints about testharness.js being too verbose and
> cumbersome to use.
> I agree with all those complaints but I don't think we can convince all
> other browser vendors
> to use our own testing script either since both Blink & Gecko are onboard
> with using testharness.js
>
> At this point, I'd argue that the benefit outweighs the cost of adopting
> testharness.js.
> Also, W3C have dropped many styling requirements for tests so we no longer
> need to have
> link/meta elements, etc... You simply include testharness.js and
> testharness-report.js.
>
> See my recent PR
> 
>  for
> example.
>
> Do people still object to using testharness.js? If so, what are your
> reasons?
>
>
> *2. Where should we put upstremable tests?*
>
> We need a mechanism to identify & merge tests back from WebKit into Web
> Platform Tests.
>
> One way to do this is to start adding tests directly into
> LayoutTests/imported/w3c/web-platform-tests
> and then automatically identify those tests and upstream them.
>
> Assuming all upstream merges happen in timely happen, 

Re: [webkit-dev] Settings and Testing (Settings, RuntimeEnabledFeatures, WebPreferences)

2017-01-20 Thread youenn fablet
> • If a test wants to change a RuntimeEnabledFeature:
>
> - No set pattern.
> - Some tests use internals.settings but this seems inappropriate, since
> the page has already loaded
> - Some tests use the special comment syntax parsed by TestRunners; this
> makes sense, but would not be good for imported tests
>
>
LayoutTests/tests_options.json is currently used to pass options for
imported tests, for instance whether they are slow or not.
It could be used for these options as well.

It would be good to have one unique way of setting test parameters that
cannot be set by JavaScript.
Currently we have three ways (TestExpectations, special comment syntax and
tests_options.json).
I don't like using TestExpectations for that purpose.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit build failed

2016-12-14 Thread youenn fablet
I guess you tried something like "./Tools/Scripts/build-webkit --release
--wincairo" or "perl ./Tools/Scripts/build-webkit --release --wincairo"?

If so, can you provide the log?


Le mer. 14 déc. 2016 à 13:01, Plamen Dimitrov  a
écrit :

> OK. How to build webkit-wincairo correctly?
>
> On Wed, Dec 14, 2016 at 11:40 AM, Konstantin Tokarev 
> wrote:
>
>
>
> 14.12.2016, 12:22, "Plamen Dimitrov" :
> > Hi all,
> >
> > if  WinCairo build is OK why I cann't build it?
> >
> > I've still cannot generated a lot of files.
> > It seems that DerivedSources.make has not been invoked.
>
> CMake build does not use DerivedSources.make
>
> > How I can generate the files manually?  perl build-webkit --release
> --wincairo not works for me the error is error C2672: 'std::invoke': no
> matching overloaded function found"
> > It is very important to build it today.
>
>
> --
> Regards,
> Konstantin
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] exposing getUserMedia and RTCPeerConnection in Tech Preview?

2016-12-01 Thread youenn fablet
It is good if we already have these runtime flags.
Then we might just need to make the related IDLs exposed according that
flag through EnabledAtRuntime keyword.
  y



Le jeu. 1 déc. 2016 à 11:55, Alexandre GOUAILLARD <agouaill...@gmail.com> a
écrit :

> Bonjour youenn,
>
> Eric avait fait ca en mars cette année. Tu peux regarder les commits
> ci-dessous. J'ai vérifie hier, les flags de compil sont toujours a OFF, et
> les runtimes sont aussi gardes. Je ne sais pas pourquoi les API sont
> accessibles.
>
> https://bugs.webkit.org/show_bug.cgi?id=158393
>
> https://trac.webkit.org/browser/trunk/Source/WebCore/bindings/generic/RuntimeEnabledFeatures.h?rev=202704
>
> https://trac.webkit.org/changeset/198492
>
> Note that I documented those two flags on the webkit wiki on march 26 this
> year, after eric split the original MEDIA_STREAM into two:
> https://trac.webkit.org/wiki/FeatureFlags
>
> Alex.
>
>
> On Thu, Dec 1, 2016 at 6:48 PM, youenn fablet <youe...@gmail.com> wrote:
>
> Hi Philipp,
>
> Thanks for bringing that up.
> I think we should add runtime flags for getUserMedia and RTCPeerConnection
> and set them to off in Safari Tech Preview until stable enough.
>
> y
>
>
> Le mer. 30 nov. 2016 à 14:40, Philipp Hancke <fi...@appear.in> a écrit :
>
> It has been brought to my attention that apparently Safari Tech Preview
> Release 18 (Safari 10.1, WebKit 12603.1.12) is exposing RTCPeerConnection
> and navigator.mediaDevices.getUserMedia.
>
> Since a check for
>navigator.mediaDevices.getUserMedia && window.RTCPeerConnection
> and redirecting browsers that support neither is pretty common this is
> rather unfortunate.
>
> The getUserMedia implementation does not seems to work on one of the most
> basic GUM samples at
> https://webrtc.github.io/samples/src/content/getusermedia/gum/
> I am actually not seeing GUM resolve or reject the promise at all.
>
> And RTCPeerConnection did not work either in
> https://webrtc.github.io/samples/src/content/peerconnection/pc1/
>
> What is the plan here?
>
> Philipp
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
> --
> Alex. Gouaillard, PhD, PhD, MBA
>
> 
> President - CoSMo Software Consulting, Singapore
>
> 
> sg.linkedin.com/agouaillard
>
>-
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] exposing getUserMedia and RTCPeerConnection in Tech Preview?

2016-12-01 Thread youenn fablet
Hi Philipp,

Thanks for bringing that up.
I think we should add runtime flags for getUserMedia and RTCPeerConnection
and set them to off in Safari Tech Preview until stable enough.

y


Le mer. 30 nov. 2016 à 14:40, Philipp Hancke  a écrit :

> It has been brought to my attention that apparently Safari Tech Preview
> Release 18 (Safari 10.1, WebKit 12603.1.12) is exposing RTCPeerConnection
> and navigator.mediaDevices.getUserMedia.
>
> Since a check for
>navigator.mediaDevices.getUserMedia && window.RTCPeerConnection
> and redirecting browsers that support neither is pretty common this is
> rather unfortunate.
>
> The getUserMedia implementation does not seems to work on one of the most
> basic GUM samples at
> https://webrtc.github.io/samples/src/content/getusermedia/gum/
> I am actually not seeing GUM resolve or reject the promise at all.
>
> And RTCPeerConnection did not work either in
> https://webrtc.github.io/samples/src/content/peerconnection/pc1/
>
> What is the plan here?
>
> Philipp
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] https://webkit-queues.webkit.org down?

2016-09-23 Thread youenn fablet
Hi all,

It seems https://webkit-queues.webkit.org is down (I got 503 responses).
Can somebody check this?

Thanks
   y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Importing W3C tests

2016-09-07 Thread youenn fablet
Hi,

I improved a bit W3C test importer lately.

First, I'd like to remind people importing tests (great) without the
importer (copy/paste a directory e.g.) to update
LayoutTests/imported/w3c/resources/ImportExpectations.
That allows me to refresh those tests when doing a full resync more quickly.
Otherwise, I need to know why some tests were needlessly removed when doing
a full resync,
Note that, as part of the full resync, I am removing tests that are removed
in WPT repository.

I also made two improvements to W3C test importer.

Resource files in WPT repository are not always in 'resources' folder.
Test importer is generating a list of resource files in
LayoutTests/imported/w3c/resources/resource-files.json
All listed files there will be skipped.
If you import tests without the importer, it might be better to update that
file than adding Skip TestExpectations.

Slow tests in WPT repository are identified with a meta element.
Test importer is generating a list of slow tests in
LayoutTests/tests-options.json
If you import tests without the importer, it might be better to update that
file than adding Slow TestExpectations.

If you encounter any issue there, please let me know.

Thanks
y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Launching web-platform-tests server from WebKit

2016-07-04 Thread youenn fablet
Hi,

I added support for running the web-platform-tests server from
Tools/Scripts/run-webkit-httpd.
This server is useful for tests found in
LayoutTests/imported/w3c/web-platform-tests.

I do not really like the run-webkit-httpd script name since this script can
run http, web-platform-tests and web socket servers.
Also, there are some other scripts (new-run-webkit-httpd,
run-webkit-websocketserver, new-run-webkit-websocketserver). Are they all
useful?

Maybe we can do some clean-up,
https://bugs.webkit.org/show_bug.cgi?id=159395 if you are interested.

  y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

2016-04-01 Thread youenn fablet
I filed https://bugs.webkit.org/show_bug.cgi?id=156113.
Maciej, would you be able to add details about the polyfill, in particular
how it detects whether fetch API is there or not?

Thanks,
   y


Le jeu. 31 mars 2016 à 20:32, Maciej Stachowiak <m...@apple.com> a écrit :

>
> On Mar 31, 2016, at 11:14 AM, youenn fablet <youe...@gmail.com> wrote:
>
> Hi,
>
> I like the idea of a runtime flag.
> I would wait to enable fetch use until it passes sufficient numbers of
> web-platform-test tests.
> This can be tested in http://w3c-test.org/tools/runner/index.html (folder
> fetch/api).
> I think th
>
> Also, are you suggesting that it would be in addition to the compile flag
> or as a replacement?
>
>
> As long as everything is hidden and there are no bad side effects when the
> runtime flag is off, it could substitute entirely for a compile-time flag.
> I'd like to see us using runtime flags more and compile-time flags less.
>
> Regards,
> Maciej
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

2016-03-31 Thread youenn fablet
Woups, the mail went out too fast.
Fetch API is not yet supporting some options like CORS at the moment.
I think we should expose fetch once it is using properly all existing
ThreadableLoader options.
   y


Le jeu. 31 mars 2016 à 20:14, youenn fablet <youe...@gmail.com> a écrit :

> Hi,
>
> I like the idea of a runtime flag.
> I would wait to enable fetch use until it passes sufficient numbers of
> web-platform-test tests.
> This can be tested in http://w3c-test.org/tools/runner/index.html (folder
> fetch/api).
> I think th
>
> Also, are you suggesting that it would be in addition to the compile flag
> or as a replacement?
>
>
>
> Le jeu. 31 mars 2016 à 20:06, Timothy Hatcher <timo...@apple.com> a
> écrit :
>
>> On Mar 31, 2016, at 10:02 AM, Maciej Stachowiak <m...@apple.com> wrote:
>>
>> The recently released Safari Technology Preview has gotten more people
>> living on builds close to trunk, which is cool. Some people pointing out
>> that the current state of Fetch API causes problems - it's not quite
>> complete enough for real web apps that want to use it, but its presence
>> breaks the detection that would substitute a polypill.
>>
>> I'd like to suggest that it should be disabled until it's complete enough
>> to work. I would propose a runtime flag instead of compile-time so it can
>> continue to be tested by our regression tests while it's getting finished
>> up.
>>
>>
>> It is is way better shape in trunk. It really just missed the Safari
>> Technology Preview build by a couple days. A fetch example I have now works
>> in a trunk Safari build for example.
>>
>> I think we can keep it enabled and have it be in the next Safari
>> Technology Preview release. We do need to be careful with things like this
>> in the future though.
>>
>> — Timothy Hatcher
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

2016-03-31 Thread youenn fablet
Hi,

I like the idea of a runtime flag.
I would wait to enable fetch use until it passes sufficient numbers of
web-platform-test tests.
This can be tested in http://w3c-test.org/tools/runner/index.html (folder
fetch/api).
I think th

Also, are you suggesting that it would be in addition to the compile flag
or as a replacement?



Le jeu. 31 mars 2016 à 20:06, Timothy Hatcher  a écrit :

> On Mar 31, 2016, at 10:02 AM, Maciej Stachowiak  wrote:
>
> The recently released Safari Technology Preview has gotten more people
> living on builds close to trunk, which is cool. Some people pointing out
> that the current state of Fetch API causes problems - it's not quite
> complete enough for real web apps that want to use it, but its presence
> breaks the detection that would substitute a polypill.
>
> I'd like to suggest that it should be disabled until it's complete enough
> to work. I would propose a runtime flag instead of compile-time so it can
> continue to be tested by our regression tests while it's getting finished
> up.
>
>
> It is is way better shape in trunk. It really just missed the Safari
> Technology Preview build by a couple days. A fetch example I have now works
> in a trunk Safari build for example.
>
> I think we can keep it enabled and have it be in the next Safari
> Technology Preview release. We do need to be careful with things like this
> in the future though.
>
> — Timothy Hatcher
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WebIDL change

2016-03-30 Thread youenn fablet
Hi,

The WebIDL binding generator was recently updated to pass non nullable DOM
object parameters as references to DOM constructors/methods (
https://trac.webkit.org/changeset/198833).

To disable that binding generator modification, the keyword
UsePointersEvenForNonNullableObjectArguments was introduced and used in
upstreamed IDL files. This allows updating these files progressively.

This keyword may also be used for private IDL files although it might be
better to update the DOM classes directly.

Thanks,
   y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Use the 'EasyFix' and 'GoodFirstBug' Bugzilla keywords to mentor WebKit newcomers!

2015-12-15 Thread youenn fablet
That sounds like a really cool idea, I just filed one such bug :)

So, what is the difference between EasyFix and GoodFirstBug?
Should we use both?

Below some additional points.
Thanks,
y

The initial entry point for some people is WebKit github mirror.
Would it make sense to express a few contribution information there?
Something like:
- Contributors are most welcome :) List of good first bugs can be found at
XXX. Expected review time for those bugs should be fairly quick (1 or 2
days?)
- Contribution system is bugzilla, pull requests not accepted through github
- Build instructions can be found at XXX for Mac, YYY for Linux and ZZZ for
Windows

As a newcomer, it is difficult to know whether a patch review should be
expected by the day, the week or the month. Knowing that is useful to react
properly.

In my experience, it is also not only about quickly reviewing newcomers
patches but also about the harder task of being responsive to initial
comments they may make on new/existing bugs.Having such responses may
convince them to actually write their first patches.

The tools used to prepare patches are handy but still require some practice
and may be frustrating, like ChangeLog generation for instance.
I wonder whether it is worth/difficult to translate a github pull
request/github issue as a new bugzilla entry w/o patch. That may be handy
for newcomers as well.

Le lun. 14 déc. 2015 à 18:53, Brian Burg  a écrit :

> Hello WebKittens,
>
> At the WebKit contributors meeting, we held a session to brainstorm ways
> to increase the size of the WebKit community.
> (You can see our notes on the wiki:
> http://trac.webkit.org/wiki/November%202015%20Meeting)
>
> One thing that we really liked about some other projects, particularly
> Mozilla projects such as Servo, Rust, and Firefox,
> is that there are bugs explicitly marked as being “Easy” or a “Good First
> Bug” in Bugzilla. I think we should try this.
>
> Here are some reasons why this works well (and what we should try to
> emulate):
>
> - *Bugs are flagged by experienced contributors who are familiar with the
> feature or component in question*. Identifying
> a good place to start is a big deal: in practice, most Bugzilla instances
> are chockfull of stale, misleading, or outright wrong
> bug reports and tasks, and WebKit’s Bugzilla is no exception. Even if
> components and bugs were always current, there
> are simply thousands of real, actionable tasks which are hard for new
> contributors to judge without domain expertise.
> In WebKit’s Bugzilla instance, we are going to use the *GoodFirstBug and
> EasyFix keywords* to track such bugs.
>
> Once some mentored bugs exist, we may want to think about setting up a
> gateway like Bugs Ahoy! to make searching easier.
>
> - *Every bug marked GoodFirstBug or EasyFix has a designated “bug mentor”*
> who can help a new contributor get up to speed.
> There is a lot of process to be learned to fix even a trivial bug: getting
> the code, building, making changes, writing tests,
> creating and uploading a patch, going through review, and getting changes
> in the tree. In my experience, new folks are happy
> to read and write code, but are easily discouraged from finishing a patch
> because of these barriers. A mentor helps coach
> and encourage a new contributor through these parts of the process. Some
> Bugzilla instances have a field for this; for
> now*, *just* ensure a mentor (you or someone else) is CC’d and responsive
> to questions from the contributor on Bugzilla.*
>
> - *A potential fix for a good first bug should be straightforward,
> described in Bugzilla, and be covered by new or existing tests.*
> This allows a new contributor to achieve a development feedback loop as to
> whether their changes have correct behavior without
> requiring extra effort on the part of mentors. It also educates and
> instills good habits, like writing tests alongside (or even before!) making
> changes.
>
> - *Patches from new contributors are reviewed quickly and regularly.*
> Getting quick feedback is essential to retaining interest
> and momentum, especially for contributors without an economic motivation
> (i.e, a job) or long-term history with the project.
> Feedback should be actionable and constructive. It’s much better to mark a
> patch as review- unless it’s ready to land, than to
> let a patch linger with open questions and the review? flag set. This
> discourages new contributors since the next step is unclear.
>
> Remember, good first bugs serve primarily as an introduction to the
> process of contributing code changes, so they may not
> be particularly interesting to an experienced contributor. Ramping up new
> contributors takes time and effort, but it’s worth it.
>
>
> Have any questions? Feel free to respond, find us on #webkit IRC, or
> contact myself or Jon Davis.
>
> -Brian
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> 

Re: [webkit-dev] Thought about Nix JavaScriptCore port

2015-12-07 Thread youenn fablet
On a side note, there used to be https://www.*webkit*
.org/projects/javascript/ 

It seems to be gone after the (nice) revamping of the web site.
Is there (or should there be) some efforts to promote JSC engine there or
somewhere else?

Le mar. 17 nov. 2015 à 00:35, Martin Robinson  a
écrit :

> On Fri, Nov 13, 2015 at 10:15 AM, Osztrogonác Csaba
>  wrote:
> > I like the idea to have a platform free, standalone JSC.
> > It would make easier to maintain various ARM backends.
> >
> > We don't need update-webkit*-libs at all for the
> > standalone JSC, it really depends only on ICU and LLVM.
>
> I think the idea of a standalone JSC is not really incompatible with
> our current setup. javascriptcoregtk doesn't seem to include any GTK+
> specific code, except interaction with the Glib runloop in
> inspector/EventLoop.cpp. Perhaps that could move out of JSC entirely
> or be part of small wrapper library.
>
> --Martin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Fetch API

2015-12-07 Thread youenn fablet
Hi all,

I am interested in adding support for the fetch API (
https://fetch.spec.whatwg.org/#fetch-api).
It is a more convenient way of doing programmatic network calls than XHR.
It also covers some more ground.
The fetch API is currently implemented in Chromium and Firefox.
I filed https://bugs.webkit.org/show_bug.cgi?id=151937 for that purpose.

On a separate topic, I wonder whether it would be valuable to do some
refactoring on the loading code so as to better align it with the fetch
algorithm.

Thoughts, advices... most welcome.
Thanks,
   y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Youenn Fablet is now a WebKit reviewer

2015-10-27 Thread youenn fablet
Thanks everybody!
Diving into WebKit is a great experience :)
   y

Le mar. 27 oct. 2015 à 13:03, SaamBarati1 <saambara...@gmail.com> a écrit :

> Congrats!
>
>
> Saam
>
>
>
> > On Oct 26, 2015, at 7:15 PM, Mark Lam <mark@apple.com> wrote:
> >
> > Hello everyone,
> >
> > I would like to announce that Youenn Fablet is now a WebKit reviewer.
> Please send him your congratulations, and some requests for patch reviews
> too. :-)
> >
> > Youenn, congratulations.
> >
> > Mark
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Importing web-platform-tests

2015-10-23 Thread youenn fablet
I beefed up http://trac.webkit.org/wiki/WebKitW3CTesting.
There is also a laundry list, if anyone is interested to contribute.



Le mer. 21 oct. 2015 à 23:07, Darin Adler  a écrit :

> There’s enough here that I think we should probably make a webpage or wiki
> page covering this.
>
> — Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Importing web-platform-tests

2015-10-21 Thread youenn fablet
Hi all,

I saw that the number of imported WPT tests is growing :)
Here is some information that might be useful if you are planning to import
some tests.

For importing new tests, one can:
- Update LayoutTests/imported/w3c/resources/ImportExpectations to activate
the import of selected tests
- Run "Tools/Scripts/import-w3c-tests" as is, or
"Tools/Scripts/import-w3c-tests -t web-platform-tests/XXselected-testsXX"
to have a faster import
- Run rwt to generate the new expectations on
LayoutTests/imported/w3c/web-platform-tests/XXselected-testsXX

Tools/Scripts/import-w3c-tests might display in the console a list of files
that should be added as [ Skip ] in LayoutTests/TestExpectations. Reason is
that these files are not tests but are used by tests and are not in any
"resources" folder.

Tools/Scripts/import-w3c-tests is importing tests directly from W3C github
repo. It uses a specific revision, defined in
LayoutTests/imported/w3c/resources/TestRepositories.
>From time to time, this revision should be changed to the latest WPT
revision.
The tooling to do the resynchronization is not totally ready yet.

The number of manual edits done when importing the tests should be as
limited as possible. Ideally there should be no manual edit.
If possible, it would be good to document them in some ways (directly in
the tests e.g.) so that resynchronizing the tests later on is made as easy
as possible.

I resynchronized all WPT tests today.
Please let me know if this creates any issue.
If you encounter an issue with Tools/Scripts/import-w3c-tests, please let
me know as well.

Thanks,
Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] JS Builtins invading WebCore

2015-10-09 Thread youenn fablet
Hi,

A quick note that JS builtins are now available in WebCore for WebIDL
defined methods, attributes and constructors.

WebIDL keywords (JSBuiltin and JSBuiltinConstructor) are added for that
purpose.

This may be handy for those functions that are wrappers over other
functions for instance.

Some examples can be found in the streams API implementation
(Source/WebCore/Modules/streams/*)

Thanks,
   Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CMake on Windows

2015-09-29 Thread youenn fablet
Awesome !

Quick question: is CMake used from cygwin?
Also, is there a current/future Windows build efficiency benefit?
   y

Le mar. 29 sept. 2015 à 06:34, Mital Vora  a écrit :

> Great job guys !
> On Sep 29, 2015 4:31 AM, "Brent Fulgham"  wrote:
>
> Yes — this is great work!
>
> We’re still working through a few rough edges, but very soon we can get
> rid of the whole Windows-specific build cruft, which will be a happy day.
>
> Thanks,
>
> -Brent
>
> > On Sep 28, 2015, at 3:03 PM, Michael Catanzaro 
> wrote:
> >
> > On Mon, 2015-09-28 at 13:28 -0700, Alex Christensen wrote:
> >> All the Windows buildbots are now using Windows.  We are planning to
> >> leave all the Visual Studio projects in the tree for a couple weeks,
> >
> > Thanks Alex! It sounds like you're planning to remove the Visual Studio
> > projects in a couple weeks, and it's great news that we'll soon be rid
> > of another build system.
> >
> > Michael
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Removing XHR_TIMEOUT compilation guard

2015-09-17 Thread youenn fablet
Hi all,

I am planning to remove XHR_TIMEOUT compilation guard at
https://bugs.webkit.org/show_bug.cgi?id=149260
Any concern about going forward?

Thanks
Y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WTF and STL

2015-06-23 Thread youenn fablet
Hi all,

STL classes such as std::function, std::unique_ptr are being used nowadays
in WebKit. The STL has some advantages, such as better documentation, being
familiar to non-WebKit developers...

I am wondering whether we should and could use more of the STL.
For instance, constructs that I know of such as Vector, Deque, Optional
have close counterparts in the STL.

Is there a way to keep all benefits brought by WTF constructs but using
their STL counterparts? Are there WTF constructs that can be replaced
directly by STL ones? Should we try it?

Also any thoughts on current WTF benefit compared to STL?

Thanks
y
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] *.webkit.org network issues

2015-05-18 Thread youenn fablet
Same for me, from Europe as well.
Y
Le 18 mai 2015 18:04, Osztrogonác Csaba o...@inf.u-szeged.hu a écrit :

 Hi,

 *.webkit.org sites (trac,bugs,build) are extremely slow
 from here (Europe/Hungary) and I didn't get any bugzilla
 mail 2 days ago, but I should have got many.

 Is it a known issue and/or is anybody working on the fix?

 br,
 Ossy
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Please be careful with webkitpy changes!

2015-04-02 Thread youenn fablet
Hi,

Do you have any additional information on why the first patch failed?
Can the problem be reproduced?

Thanks
   Y
Le 1 avr. 2015 21:43, Brent Fulgham bfulg...@apple.com a écrit :

 Hi Everyone,

 We lost Windows EWS coverage for the past 36 hours due to a very
 benign-appearing change to some webkitpy code. I haven’t yet figured out
 why this particular set of changes caused the Windows bots to start
 failing, but it has to do with various differences between the Cygwin
 Python 2.7.8 build and the versions used on our other EWS bots.

 This does not seem like something developers SHOULD have to worry about,
 but it’s an unfortunately reality that they really do need to.

 To make matters worse, the patch that introduced the problem passed EWS.
 This is because the EWS bots only really begin using changes to webkitpy
 when they restart processing (about once every 10-13 build iterations).

 To help combat this problem, I’d like to request that when making changes
 to webkitpy, please keep an eye on the various EWS bots to make sure they
 continue processing. If they do start failing, please roll the patch back
 out and we can work together to resolve the issue.

 I apologize for how manual and inconvenient this needs to be (at least for
 now), but keeping the EWS up and running is critical to the smooth function
 of this project.

 If you have any questions, please don’t hesitate to e-mail me or look for
 me on IRC.

 Thanks!

 -Brent
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Running new/modified tests on EWS bots

2015-03-19 Thread youenn fablet
Hi,

Related to the webkit contributor meeting discussion related to ports,
I would find it useful if EWS bots (gtk, efl, win, ios) were running
the tests that are modified/created by a patch.

The idea would be to turn yellow the port bubble whenever one of these
tests do not pass. Results would be uploaded to bugzilla.

This would give an incentive for patch developers to try fixing the
tests on these ports.
That may reduce (slightly? noticeably?) port maintainers gardening effort.
That would also be valuable when importing test suites.

Any potential issue? objection to move that forward?
Anyone willing to help? Thoughts?

Thanks,
   Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Running W3C tests using wptserve

2015-02-01 Thread youenn fablet
2015-02-01 3:08 GMT+01:00 Benjamin Poulain benja...@webkit.org:
 Hi Youenn,

 Thanks for working on this.

 How do we run the imported tests? Do we just use run-webkit-test passing
 'imported/w3c'?

Yes.

 Is there a way to get the percentage of W3C tests that succeed? It would be
 useful to have a report per directory so that we improve it over time until
 we reach 100%.

That is part of another tool: https://bugs.webkit.org/show_bug.cgi?id=134766
It basically uses run-webkit-test on the whole W3C test suite (or a subset).
It checks conformance by searching for PASS/FAIL assertions.
You can find an old version of the report here:
http://youennf.github.io/w3c-reports/12092014/w3c_conformance_results.html

That tool would also be used to discriminate which tests to import.
https://bugs.webkit.org/show_bug.cgi?id=134767 would then be used to
refresh LayoutTests/imported/w3c (new tests, -expected.txt
creation/refresh)

I plan to write a page on the wiki when these things will start to
appear on the trunk.

Any suggestion/help most welcome.


 Benjamin


 On 1/31/15 11:57 AM, youenn fablet wrote:

 Hi all,

 W3C wptserve server is now used to serve all tests under
 LayoutTests/imported/w3c/web-platform-tests.

 Currently, only two tests are run within that folder:
 - web-platform-tests/domparsing/DOMParser-parseFromString-html.html
 - web-platform-tests/domparsing/insert-adjacent.html

 Should there be any issus with those tests, the problem may be related
 to running wptserve.
 The wptserve server log is dumped in the the layout-test-results folder.
 Please let me know if you see any such issue, particularly on WebKit bots.

 Next planned steps in that area are:
 1. Update Tools/Scripts/import-w3c-tests according this new set-up
 2. Migrate already imported W3C WPT tests within
 LayoutTests/imported/w3c/web-platform-tests
 3. Further improve the tools to make import of new tests and re-import
 existing tests as easy as possible

 Any suggestion welcome.

 Thanks,
 youenn
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Running W3C tests using wptserve

2015-02-01 Thread youenn fablet
Looking at the log, the dependencies seem to be installed correctly.
Is it possible to get access to the corresponding
WebKitBuild/Release/layout-test-results, in particular
wptwk_process_log.out.txt?

Also, does it happen on all bots or only windows bot?


2015-02-01 4:41 GMT+01:00 Alexey Proskuryakov a...@webkit.org:

 31 янв. 2015 г., в 11:57, youenn fablet youe...@gmail.com написал(а):

 Currently, only two tests are run within that folder:
 - web-platform-tests/domparsing/DOMParser-parseFromString-html.html
 - web-platform-tests/domparsing/insert-adjacent.html

 Should there be any issus with those tests, the problem may be related
 to running wptserve.

 I see that these tests fail on EWS, any suggestions for how to debug the 
 issue? The EWS setup is not much different from regular bots - the biggest 
 difference is that EWS machines have more cores.

 https://webkit-queues.appspot.com/results/6309998137180160

 - Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Running W3C tests using wptserve

2015-02-01 Thread youenn fablet
Humm, the missing folder should have been created by AutoInstaller.
Can it be removed by some clean-up between the runs?
I will shortly write a fix for that particular issue but this will
probably not solve the problem if the whole module is missing.

   y

2015-02-01 20:10 GMT+01:00 Alexey Proskuryakov a...@webkit.org:

 This issue occurs on Mac bots. Windows EWS does not run regression tests, so 
 it would not be affected.

 Here is the log output:

 WARNING:web-platform-test-launcher:/Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test/__init__.py
  is not present, creating it as empty file
 Traceback (most recent call last):
   File 
 /Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/servers/web_platform_test_launcher.py,
  line 21, in module
 create_wpt_empty_file_if_needed(['tools', 'pywebsocket', 'src', 'test', 
 '__init__.py'])
   File 
 /Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/servers/web_platform_test_launcher.py,
  line 17, in create_wpt_empty_file_if_needed
 open(file_path, 'a').close()
 IOError: [Errno 2] No such file or directory: 
 '/Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test/__init__.py'

 Looks like the directory 
 /Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test
  does not exist.

 - Alexey

 1 февр. 2015 г., в 0:27, youenn fablet youe...@gmail.com написал(а):

 Looking at the log, the dependencies seem to be installed correctly.
 Is it possible to get access to the corresponding
 WebKitBuild/Release/layout-test-results, in particular
 wptwk_process_log.out.txt?

 Also, does it happen on all bots or only windows bot?


 2015-02-01 4:41 GMT+01:00 Alexey Proskuryakov a...@webkit.org:

 31 янв. 2015 г., в 11:57, youenn fablet youe...@gmail.com написал(а):

 Currently, only two tests are run within that folder:
 - web-platform-tests/domparsing/DOMParser-parseFromString-html.html
 - web-platform-tests/domparsing/insert-adjacent.html

 Should there be any issus with those tests, the problem may be related
 to running wptserve.

 I see that these tests fail on EWS, any suggestions for how to debug the 
 issue? The EWS setup is not much different from regular bots - the biggest 
 difference is that EWS machines have more cores.

 https://webkit-queues.appspot.com/results/6309998137180160

 - Alexey



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Running W3C tests using wptserve

2015-01-31 Thread youenn fablet
Hi all,

W3C wptserve server is now used to serve all tests under
LayoutTests/imported/w3c/web-platform-tests.

Currently, only two tests are run within that folder:
- web-platform-tests/domparsing/DOMParser-parseFromString-html.html
- web-platform-tests/domparsing/insert-adjacent.html

Should there be any issus with those tests, the problem may be related
to running wptserve.
The wptserve server log is dumped in the the layout-test-results folder.
Please let me know if you see any such issue, particularly on WebKit bots.

Next planned steps in that area are:
1. Update Tools/Scripts/import-w3c-tests according this new set-up
2. Migrate already imported W3C WPT tests within
LayoutTests/imported/w3c/web-platform-tests
3. Further improve the tools to make import of new tests and re-import
existing tests as easy as possible

Any suggestion welcome.

Thanks,
   youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Problem with a crash using JSC code

2015-01-26 Thread youenn fablet
The latest patch at https://bugs.webkit.org/show_bug.cgi?id=138967
resolves the crash (some JSC::Strong were missing).

I fear that the patch may be a bit too big to get a thorough review though.
The patch could be split into meaningful but not testable sub-patches
(module stuff, JS integration stuff and then tests and more tests).
Would that make sense?
What is a reasonable patch size limit?

Any advice well appreciated.

Thanks,
   Youenn


2015-01-21 19:40 GMT+01:00 Xabier Rodríguez Calvar calva...@igalia.com:
 Hi!

 I am now implementing with Youenn the Streams API standard [1] in
 WebKit. You can find the first patch at [2] (it's r? now). While we get
 that patch reviewed and landed we are adding more tests and working out
 the problems. One of them is one crash that I cannot hunt, with the
 following backtrace:

 http://fpaste.org/172619/60635142/

 You can find the code under the lines to make it easier. What is going
 on is:

  1. There's a call to the ReadableStream object, delegated to the
 JSReadableStreamSource as a result of the object creation.
  2. There's a call to the JSReadableStream::read method, delegating
 in the ReadableStream that ends up pulling again and that second
 call crashes.

 It is probably something stupid I am not taking into account, but I have
 already been fighting this for a couple of days and cannot make it work
 properly.

 Any help? Thanks a lot in advance!

 [1] https://streams.spec.whatwg.org/
 [2] https://bugs.webkit.org/show_bug.cgi?id=138967


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Streams API

2014-11-10 Thread youenn fablet
I opened a meta-bug at https://bugs.webkit.org/show_bug.cgi?id=138561
I also plan to close bugs related to the previous stream API
proposal (https://bugs.webkit.org/show_bug.cgi?id=110194 and
https://bugs.webkit.org/show_bug.cgi?id=110558).

2014-11-03 7:57 GMT+01:00 Benjamin Poulain benja...@webkit.org:
 It looks like nobody has raised any concern against Streams API. We even got
 positive feedback from Anne. :)

 I have two concerns:
 1) You have many patches waiting for review. I think you need to get better
 communication channels with reviewers in order to iterate over your patches
 faster. It is unfortunate but getting complex patches reviewed in WebKit
 requires poking reviewers directly. Since you work on the network stack, I
 suggest asking Alexey (ap) and Pratik (psolanki) on IRC, they can help with
 reviews or suggest other reviewers.
 2) Streams is a large spec and it touches platform code. Please be careful
 with stability, make more tests than reasonable and #ifdef everything.

 I suggest the flag name ENABLE_STREAMS_API, I find ENABLE_STREAMS a bit
 too generic.

 If you open a meta bug, please send the bug number to the mailing list for
 reference.

 Good luck :)
 Benjamin


 On 10/30/14, 4:02 PM, youenn fablet wrote:

 Hi all,

 I would like to add support for the streams API ([1], [2]), starting
 with readable streams and their integration with XHR and loaders.
 This work is expected to happen behind a flag.

 Regards,
 Youenn

 [1] https://github.com/whatwg/streams
 [2] http://www.w3.org/TR/streams-api/
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Networking process scope

2014-11-10 Thread youenn fablet
Hi,

I looked at the Networking process recently and am wondering what is
in scope/out of scope of this process.

Currently, the networking process is used to load resources from:
- URLs resolved using platform specific libraries (CF, libsoup...),
including data URLs
- Blob URLs
The networking process is not used for (at least):
- appcache resources URLs
- archive resources URLs

Two options come to mind:
1. Use networking process for all URLs that require actual networking.
That would mean moving data  blob URL handling within WebProcess,
probably unifying this loading with appcache/archive resource loading.
2. Use networking process for all URLs. That would mean moving
appcache/archive resource loading into Networking process at some
point.

Any thoughts?

Regards,
   Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Streams API

2014-11-03 Thread youenn fablet
Hi Benjamin,

 I have two concerns:
 1) You have many patches waiting for review. I think you need to get better
 communication channels with reviewers in order to iterate over your patches
 faster. It is unfortunate but getting complex patches reviewed in WebKit
 requires poking reviewers directly. Since you work on the network stack, I
 suggest asking Alexey (ap) and Pratik (psolanki) on IRC, they can help with
 reviews or suggest other reviewers.

Thanks for the suggestion, I will try to do so for my pending patches.
For the particular streams API work, I am teaming up with some Igalia fellows.
I hope that we can make good progress that way.

 2) Streams is a large spec and it touches platform code. Please be careful
 with stability, make more tests than reasonable and #ifdef everything.

 I suggest the flag name ENABLE_STREAMS_API, I find ENABLE_STREAMS a bit
 too generic.

Ah, I was thinking of using ENABLE_STREAMS.
ENABLE_STREAMS_API is fine by me.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Streams API

2014-11-02 Thread youenn fablet
Meaning that only the fetch API would at some point support streams?
If so, I wonder why we should postpone a small but useful feature to a
nice but future API.

2014-10-31 8:48 GMT+01:00 Anne van Kesteren ann...@annevk.nl:
 On Fri, Oct 31, 2014 at 12:02 AM, youenn fablet youe...@gmail.com wrote:
 I would like to add support for the streams API, starting
 with readable streams and their integration with XHR and loaders.
 This work is expected to happen behind a flag.

 There's no planned integration with XMLHttpRequest.


 --
 https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Streams API

2014-10-30 Thread youenn fablet
Hi all,

I would like to add support for the streams API ([1], [2]), starting
with readable streams and their integration with XHR and loaders.
This work is expected to happen behind a flag.

Regards,
   Youenn

[1] https://github.com/whatwg/streams
[2] http://www.w3.org/TR/streams-api/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Compiling WebKit Windows targets

2014-10-03 Thread youenn fablet
Hi all,

I tried compiling WebKit on Windows.
I successfully built the Release_WinCairo target :)
But not the Release target...

The build log says that some libs are missing in my current setup
(Windows 7 SP1, VS 2013): LibGLESv2 did not find LIBCMT.lib and WTF
did not find libcpmt.lib.

Any idea on how to fix this?

Regards,
   Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Going forward on automating W3C test suite import

2014-09-18 Thread youenn fablet
Hi all,

I continued the implementation of some scripts to help importing
regularly the whole W3C test suite as layout tests
(http://wkb.ug/134767).

The process is currently as follows:
- Import the whole test suite as a WebKitBuild sub-folder
- Run rwt on this sub-folder
- Compute conformance for each test (for example
http://youennf.github.io/w3c-reports/12092014/w3c_conformance_results.html)
- Generate TestExpectations based on conformance results (skip all
tests except the ones with at least one successful assertion)
- Update LayoutTests folder (test files, expected.txt and TestExpectations)

Using that approach, from 3000 tests, about 2000 could be run.
Running these tests takes about 10 minutes to run on my machine. The
remaining skipped tests take much more time to run.

To move on with this, I have some questions:
1. Is it fine to run rwt within a WebKitBuild sub-folder, tests
provided as absolute paths?
2. Is it ok to have a separate TestExpectationsW3C for W3C tests, one
for each port typically?
3. Is it ok to run all tests through wpt http server, thus using a
single test runner?
4. How to best ease bumping of the W3C test suite version? Should the
version be the same version for all ports, requiring some coordination
between ports when bumping? Should there be one version for each port?

Any suggestion?

Regards,
 youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Using W3C test suite as LayoutTests

2014-07-16 Thread youenn fablet
Hi all,

I made some progress to enable the use of W3C test suite within WebKit.
Some patches are uploaded for that purpose: 222087 233360 233362
233047 235009 235011 235012 235013.
https://github.com/canonresearchfrance/webkit/wiki/Running-W3C-Tests
is updated wth all details.

After some discussions, the idea is to import tests as regular webkit
tests with their expected.txt and test expectations. To automate this
process, two tools are introduced by these patches:
- a first tool (run-w3c-conformance) checks W3C conformance from
generated expected.txt files and generates a report.
- a second tool (generate-w3c-baseline) based on the first one
generates expected.txt files and related TestExpectations fie

The second tool currently puts expected.txt and test expectation files
in LayoutTests platform-specific folders, to cope with port result
discrepancies (console message...).
Import of html files could also be done at runtime so that html files
never appear in WebKit repo. This would allow each port to bump W3C
test suite revision independently.

Some additional points:
- by default, test import uses a W3C test suite revision specified in
a WPTTestsVersion file. The goal would be to always check in tests
from a single revision.
- The testharness.js file used for W3C tests is the one from W3C
repository, The testharnessreport.js file is coming from WebKit
LayoutTests/resources folder.
- The only modification to the test runtime infrastructure is the use
of the WPT server (patch 233360). This is at least needed for HTTP and
WS tests, probably not to most other tests.
- Some tests are flaky due to failed assertions with dynamically
generated values. The tool runs the tests twice to identify and skip
them. These test assertions should probably be fixed.

I plan to start experimenting with this approach by uploading some
tests for the GTK port.
Any feedback or help would be well appreciated.

Regards,
  Youenn

2014-06-19 22:59 GMT+02:00 youenn fablet youe...@gmail.com:
 Hi all,

 I drafted in
 https://github.com/canonresearchfrance/webkit/wiki/Running-W3C-Tests some
 thoughts about how to run W3C tests within WebKit, the goal being to improve
 regression checks and monitor overall W3C conformance..

 It contains how to run the W3C tests using the WPT test server through
 run-webkit-tests (patches available in bugs.webkit.org).

 It also describes how to assess results in the absence of any test baseline
 checked in WebKit trunk (the W3C test suite is continuously moving
 anyway...).

 Any feedback well appreciated.

 Regards,
Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Using W3C test suite as LayoutTests

2014-06-19 Thread youenn fablet
Hi all,

I drafted in
https://github.com/canonresearchfrance/webkit/wiki/Running-W3C-Tests some
thoughts about how to run W3C tests within WebKit, the goal being to
improve regression checks and monitor overall W3C conformance..

It contains how to run the W3C tests using the WPT test server through
run-webkit-tests (patches available in bugs.webkit.org).

It also describes how to assess results in the absence of any test baseline
checked in WebKit trunk (the W3C test suite is continuously moving
anyway...).

Any feedback well appreciated.

Regards,
   Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] W3C NSD Implementation

2014-03-31 Thread youenn fablet
Hi,

We recently outsourced a prototype of the W3C NSD API (
http://www.w3.org/TR/discovery-api/), implemented  as a WebKit module.
It is mostly feature complete and works for GTK/EFL ports.
The WebKit fork can be found here:
https://github.com/canonresearchfrance/webkit (branch webkit-nsd).

Demo, screencasts... are available at:
https://github.com/canonresearchfrance/webkit-nsd-demo

Writing a WebKit module from scratch (with support for WK1  WK2, EFL  GTK
ports), was a lot of fun. At some point, we needed to make some design
decisions, hopefully sensible but who knows...

Any feedback would therefore be greatly appreciated.

Once the spec becomes stable, we hope that this module can be contributed
to WebKit users.

Regards,
Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] EWS doesn't lie!

2014-02-10 Thread youenn fablet
Is it by design that only mac bots run regression tests? Technical issue?
Lack of resources?


2014-01-30 9:05 GMT+01:00 Alexey Proskuryakov a...@webkit.org:

 Hi WebKit hackers,

 It sometimes happens that people land patches despite EWS detecting layout
 test regressions, especially when these seem too unlikely to believe.

 In my experience, EWS has been very stable recently, and if tester bubbles
 are red, it almost certainly means that the patch is faulty. Even if they
 don't turn red, but remain yellow for a long time, there is a good chance
 that the patch introduces flaky failures, so EWS can't make up its mind
 about exactly which tests regressed.

 If you click on a yellow bubble, that takes you to a page with additional
 details, where you can see which tests are failing. I'd like to look into
 improving how this information is presented at some point in the future,
 yet even now, it shouldn't be too time consuming to check what's going on.

 For reference, we currently have mac and mac-wk2 EWS bots running
 regression tests in release mode. Other bots only verify that the patch
 builds, and don't run tests. No bots use debug mode as far as I know, so
 debug-only build failures and assertions will not be detected. Please run
 tests locally to catch as many of those as possible.

 - WBR, Alexey Proskuryakov

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] EWS doesn't lie!

2014-02-10 Thread youenn fablet
All of this makes sense, but the downsides is that it does not ensure
convergence between the ports.
If this situation is expected to stay for some time, I wonder whether some
middle ground may be found for ports that are build-stable.

For instance, having status information on new/modified tests for all ports
would be useful and not that expensive.
When tests do not pass on some ports, updating the test expectations (and
creating bug entries) would be an improvement over the current situation.


2014-02-10 10:25 GMT+01:00 Osztrogonác Csaba o...@inf.u-szeged.hu:

 On 02/10/2014 09:51 AM, youenn fablet wrote:

 Is it by design that only mac bots run regression tests? Technical
 issue? Lack of resources?


 Technically, it's so easy to make an EWS to run layout tests
 too with adding a runTests: true to the ews.json file:
 https://trac.webkit.org/browser/trunk/Tools/Scripts/
 webkitpy/common/config/ews.json

 But in my opinion it wouldn't be a good idea to enable layout tests
 on Windows, GTK, EFL EWS bots, because it would make them absolutely
 useless and we would lost the information if a patch builds or not.

 To have a quite stable and working tester EWS, the buildbot for the
 given platform must be green _almost all the time_. If there is at
 least one failing test, the testing is at least twice slower, because
 the EWS runs the test with the patch and then without the patch to
 check if the list of the failing tests are same. Additionally the
 given port must be very stable. If there are any small flakiness,
 the EWS wouldn't pass ever and would stuck in an infinite loop.

 The rough true is that now only the Mac platform is stable and green
 enough to have tester EWS bots. (There are ~210 +/-5 failures on the
 Windows bots from the cstack merge, ~205 +/-10 failures on EFL-WK1 long
 time ago, ~80 +/- 2 failures on GTK-WK1 lone time ago, ~ 60 +/- 5
 failures on GTK-WK2, ...)

 Additionally to have tester EWS, port maintainers should have to setup
 many new hardware (min. 4-8 machines with 4/8 cores per port to have
 acceptable runtime) and EWS runtime would be much more slower than
 the runtime of build only EWS bots, because bulding + running tests
 take ~ an hour everywhere.

 Ossy


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Importing W3C tests for editing

2014-02-05 Thread youenn fablet
We are still far from importing into WebKit the whole test set from
web-platform-tests repo.
Improving the situation here would already be a great step forward.

It would also be good to regularly run the whole web-platform-tests repo
test set so as to get statistics in terms of feature alignment and test
import completeness/synchronization. See
https://bugs.webkit.org/show_bug.cgi?id=127095#c9 for rough notes on that.
I hope to work on that once the web platform test server will be integrated
into WebKit.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Importing W3C tests for HTML template elements

2014-01-16 Thread youenn fablet
I created a bug to track this (serve imported w3c tests using wptserve:
https://bugs.webkit.org/show_bug.cgi?id=127094).
I also plan to work on merging Blink patches to allow checking
testharness-based tests without the use of any -expected file:
https://bugs.webkit.org/show_bug.cgi?id=127095.



2014/1/6 Dirk Pranke dpra...@chromium.org

 Ryosuke and I discussed this a bit over IRC. Ryosuke's main concern was
 that supporting multiple document roots adds a fair amount of complexity to
 NRWT. Conceptually, it's probably easier to add support to run the W3C's
 new server (known as wptserve) and then maybe use it for *all* imported
 tests from the W3C.

 If it turns out that wptserve is too slow, and you would prefer to run
 only some of the directories over http (i.e., the 10k+ CSS tests don't need
 http), you'll probably need to modify how wptserve is run (and NRWT) as
 well, anyway, so the patch would be different.

 Ryosuke, please let me know if I've misstated your thinking at all.

 -- Dirk

 On Mon, Jan 6, 2014 at 11:23 AM, Ryosuke Niwa rn...@webkit.org wrote:

 I don't think we should do this given that the python server has been
 added to W3C testing harness, and they're gonna convert all existing tests
 to use that instead:
 http://lists.w3.org/Archives/Public/public-test-infra/2014JanMar/.html

 We should simply wait for that effort to take place and add a support for
 the python server instead.

 - R. Niwa


 On Fri, Dec 6, 2013 at 12:25 AM, youenn fablet youe...@gmail.com wrote:

 As long as the newly imported tests use relative URLs, alias may be used
 as a workaround. I will give it a try.
 Bug entry is at https://bugs.webkit.org/show_bug.cgi?id=125339
 Any further help appreciated,
   Youenn



 2013/12/6 Darin Adler da...@apple.com

 If that's really ends up being super hard we can always put yet another
 third-party or imported directory inside the http directory as previously
 suggested. it's annoying to have three different places for imported tests
 and code, but not something I want to hold us up for a long time.

 -- Darin

 Sent from my iPhone

 On Dec 5, 2013, at 5:51 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Dec 4, 2013 at 11:19 AM, Darin Adler da...@apple.com wrote:

 On Dec 4, 2013, at 6:48 AM, youenn fablet youe...@gmail.com wrote:

 I am planning to add some XHR tests from
 https://github.com/w3c/web-platform-tests.
 My initial plan was to add them in a subdirectory of
 LayoutTests/http/tests/w3c.
 If adding them into LayoutTests/imported/w3c, that would probably
 require updating the test scripts to start/stop the HTTP test server
 for that particular sub-folder.

 Any preference?


 I’d prefer LayoutTests/imported/w3c. Although I’m not so happy about
 the different terminology we are using for “imported” vs. “ThirdParty”,
 which seems like the same concept at the top level of the directory
 structure.


 One trickiness to it is that we don't currently run any HTTP test in
 parallel and the document root of the HTTP server is set to
 LayoutTests/http/tests so we might need to modify that or restart the HTTP
 server whenever we're running HTTP tests outside of LayoutTests/http.

 - R. Niwa




 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Importing W3C tests for HTML template elements

2013-12-06 Thread youenn fablet
As long as the newly imported tests use relative URLs, alias may be used as
a workaround. I will give it a try.
Bug entry is at https://bugs.webkit.org/show_bug.cgi?id=125339
Any further help appreciated,
  Youenn



2013/12/6 Darin Adler da...@apple.com

 If that's really ends up being super hard we can always put yet another
 third-party or imported directory inside the http directory as previously
 suggested. it's annoying to have three different places for imported tests
 and code, but not something I want to hold us up for a long time.

 -- Darin

 Sent from my iPhone

 On Dec 5, 2013, at 5:51 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Dec 4, 2013 at 11:19 AM, Darin Adler da...@apple.com wrote:

 On Dec 4, 2013, at 6:48 AM, youenn fablet youe...@gmail.com wrote:

 I am planning to add some XHR tests from
 https://github.com/w3c/web-platform-tests.
 My initial plan was to add them in a subdirectory of
 LayoutTests/http/tests/w3c.
 If adding them into LayoutTests/imported/w3c, that would probably
 require updating the test scripts to start/stop the HTTP test server for
 that particular sub-folder.

 Any preference?


 I’d prefer LayoutTests/imported/w3c. Although I’m not so happy about the
 different terminology we are using for “imported” vs. “ThirdParty”, which
 seems like the same concept at the top level of the directory structure.


 One trickiness to it is that we don't currently run any HTTP test in
 parallel and the document root of the HTTP server is set to
 LayoutTests/http/tests so we might need to modify that or restart the HTTP
 server whenever we're running HTTP tests outside of LayoutTests/http.

 - R. Niwa


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


  1   2   >