Re: [webkit-dev] Request for position: MediaTrackSupportedConstraints.backgroundBlur

[youenn fablet via webkit-dev]

Hi Riju,

This seems reasonable to me.

Le mer. 22 juin 2022 à 23:19, Bhaumik, Rijubrata via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> This is a request for WebKit's position on adding support for Background
> Blur API on MediaStreamTrack.
>
> The PR that introduced this behavior to the medicapture-extensions spec
> and the explainer was co-authored by Apple engineer Youenn Fablet and
> approved by Jan-Ivar Bruaroey (Mozilla).
>
>
>
> Explainer
>
> https://github.com/riju/backgroundBlur/blob/main/explainer.md
>
> Specification
>
>
> https://w3c.github.io/mediacapture-extensions/#exposing-mediastreamtrack-source-background-blur-support
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5077577782263808
>
> WebRTC  meeting minutes:
> https://www.w3.org/2022/05/17-webrtc-minutes.html#t07
> Thanks, Riju.
>
>
> ___
> 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: Response.json() static method

[youenn fablet via webkit-dev]

This looks like a reasonable API to me.

Le mer. 25 mai 2022 à 11:01, Adam Rice via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> The Response.json() static method permits constructing a Response object
> with the body populated with a JavaScript object serialized as JSON.
>
> Links:
>
>- Explainer:
>
> https://docs.google.com/document/d/1dTycWmyxLZNGTBW93fvtf1IQahx-vNwgu94yT1x9K50/edit
>- Spec: https://fetch.spec.whatwg.org/#ref-for-dom-response-json
>- ChromeStatus entry: https://chromestatus.com/feature/5197912798658560
>
> ___
> 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: Capture Handle Identity

[youenn fablet via webkit-dev]

Hi Elad,

For those following, the new link to the spec is
https://w3c.github.io/mediacapture-handle/identity/index.html.

A few thoughts:
1. The use cases are fine, although the proposal is currently restricted to
tabs having a tight coordination (same origin typically). Reducing a lot
the level of required coordination between capturee and capturer seems like
an important requirement.
3. The current API allows to share a single string for all capturers no
matter the capturer origin (as long as origin is in the allowed list). It
seems that identity could be different depending on the capturer origin.
For instance, a capturee could expose its context ID (
https://w3c.github.io/ServiceWorker/#client-id)) if capturer is same origin
but just its origin for all other capturers. Replacing the allowed list
mechanism by a map-like API would be more flexible without adding much
complexity.
4. The idea is to share identity from captured page to capturer page. On
the web, the foundation of page identity is origin. The current API allows
exposing a partial identity, i.e. an application-provided string without
the origin. The scenarios in the document do not motivate AFAICS this
'partial' identity. It seems origin should be the first thing a captured
page might want to share if it desires so. The fact that, by default, the
origin is not exposed is not encouraging either.
5. Some of the usecases would be better suited with their own specific
solution (use case 3 and 4 for instance, a property that directly tells
whether capturee === capturer). I think they should be pursued on their own
and removed from the document.
6. Capture handle creates a one way broadcast/postMessage-limited-to-string
mechanism if capturee repeatedly calls the capture handle API as events
will be fired on capturer for each API call. If introducing a messaging API
as use case #1 mentions, this mechanism might become redundant with this
future messaging API. It would be good to consolidate the current proposal
based on use case #1 next steps.
7. Capture Handle Identity is really about screenshare, not about
camera/microphones, it would be good to make that clear in the links/spec
short names.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Basuke Suzuki is now a WebKit reviewer!

[youenn fablet via webkit-dev]

Congrats Basuke!

Le lun. 7 mars 2022 à 20:41, Kirsling, Ross via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> Hi everybody,
>
>
>
> I’m happy to announce that Basuke Suzuki is WebKit’s newest reviewer!
>
>
>
> Basuke has done significant work on the PlayStation and WinCairo ports,
> Curl, the socket-based remote web inspector, and bmalloc, so keep him in
> mind next time you need a review.
>
>
>
> Please join me in congratulating Basuke!
>
>
>
> Ross
> ___
> 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: Fetch Metadata

[youenn fablet via webkit-dev]

I also think this is worth prototyping.
Destination and mode are valuable and are hopefully not controversial, I
would start with those two.
I would also hope WPT coverage is good in that area and would cover both
regular network loads as well as cache loads. Not sure how this would play
with memory cache.

Le lun. 21 févr. 2022 à 22:07, Alex Christensen via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> I’m interested in this work, and would be happy to review patches.  I
> noticed that Chrome and Firefox both implement it and we don’t.  Some of
> the implementation might be a little involved, so I’m happy to answer
> questions and point in the right direction when I can.
>
> I’m not thrilled that it adds more bytes to each request, especially when
> using HTTP 1.1 where headers are not compressed.  The day may also come
> when we need to either omit the metadata or send incorrect metadata for
> privacy or security reasons, but I haven’t thought it through well enough
> yet and I’m not aware of cases where that would be necessary right now.
>
> > On Feb 16, 2022, at 12:43 PM, Patrick Griffis via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
> >
> > On 2022-02-11 16:15, Patrick Griffis via webkit-dev wrote:
> >> However Sec-Fetch-User I believe will require more
> >> significant changes that will have to be exposed to each port. It
> >> requires knowing if a request was initiated by a user, exact details are
> >> specified here[2], which I think will require integration at the
> >> Safari/WebKitGTK/etc layers.
> >
> > Looking more into this Firefox takes a more heuristic approach to
> > figuring this out (was there a referrer and what is the request type)
> > and if that approach works out for WebKit it wouldn't require any
> > port-specific changes. Chromium itself does just ask the `ui` layer what
> > type of "transition" caused the request which is more in-line with the
> > spec.
> > ___
> > 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] Request for position on AudioContext.outputLatency

[youenn fablet via webkit-dev]

Thanks Hongchan,

It is good to hear that these discussions are happening.
A first good step would be to add the corresponding fingerprinting markup
to the web audio spec.

A few additional thoughts:

https://w3c.github.io/mediacapture-output/ allows listing devices that a
user granted.
In case devices are exposed to JS, exposing latency for those devices seems
fine.
I also wonder whether output latency might be useful outside of
AudioContext and whether it would make sense to expose this information on
MediaDevices as well. Could that be a device selection choice?

The main issue is with the default system audio output. Passive filtering
should not be allowed in that case. For instance, if the AudioContext is
not producing audio, exposing latency does not make sense.

I am a bit unclear about when latency can change, for instance say audio
context is running and the default system speaker is changed. If it can
change, should there be some form of events to let the application know. Or
should it be left to things like MediaDevices.ondevicechange?


Le lun. 13 déc. 2021 à 20:00, Hongchan Choi  a
écrit :

> Hi Youenn,
>
> Thanks for your response.
>
> Say I switch from builtin speakers to Bluetooth headset using MacOS system
>> menu.
>>
>
> If changing a device doesn't reflect the current status correctly, the
> feature is not useful. That said, the accuracy/precision of a value being
> served is up to the user agent's discretion.
>
> If so, the spec should identify this as potential fingerprinting and
>> should provide mitigations.
>> And we should evaluate fingerprinting-free alternatives.
>
>
> We are aware of the issue and it is being discussed in the blink-dev I2S
> thread.
>
> What does PING WG think about this?
>
>
> Please note that Web Audio API is currently a W3C Recommendation.
> - The WG went through several PING reviews in 2020, for example:
> https://github.com/WebAudio/web-audio-api/issues/2061
> - One of device-related PING threads:
> https://github.com/w3cping/tracking-issues/issues/50
>
> As a result of the privacy discussion, the spec has a dedicated section on
> security and privacy:
> https://webaudio.github.io/web-audio-api/#priv-sec
>
> The relevant excerpt:
> "Fingerprinting via latency is also possible; it might be possible to
> deduce this from baseLatency and outputLatency. Mitigation strategies
> include adding jitter (dithering) and quantization so that the exact skew
> is incorrectly reported. Note however that most audio systems aim for low
> latency, to synchronise the audio generated by WebAudio to other audio or
> video sources or to visual cues (for example in a game, or an audio
> recording or music making environment). Excessive latency decreases
> usability and may be an accessibility issue."
>
> Cheers,
> Hongchan
>
>
> On Mon, Dec 13, 2021 at 1:15 AM youenn fablet  wrote:
>
>> Looking at https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency,
>> it states that:
>> > If the audio output device is changed the outputLatency
>> <https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency> attribute
>> value will be updated accordingly.
>>
>> The use case seems ok, but I worry about fingerprinting if it means this
>> allows a web page to passively identify user speakers.
>> Say I switch from builtin speakers to Bluetooth headset using MacOS
>> system menu.
>>
>> If so, the spec should identify this as potential fingerprinting and
>> should provide mitigations.
>> And we should evaluate fingerprinting-free alternatives.
>> What does PING WG think about this?
>>
>> Le lun. 13 déc. 2021 à 09:39, Yoav Weiss via webkit-dev <
>> webkit-dev@lists.webkit.org> a écrit :
>>
>>> (Sent on behalf of Hongchan Choi, who failed to subscribe to this
>>> mailing list)
>>>
>>> Hey folks!
>>>
>>> AudioContext.outputLatency is to inform the time at which the first
>>> sample in the buffer is actually processed by the audio output device. This
>>> is useful when synchronizing the audio generated by Web Audio to other
>>> audio or video sources or to visual cues [1].
>>>
>>> This is already implemented in FireFox and we're looking to ship it in
>>> Chrome soon [2][3]. Would you all be interested in this feature?
>>>
>>> Thanks,
>>> Hongchan
>>>
>>> [1] https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency
>>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1324552
>>> [3]
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dTQniJNVVMY/m/hPFwY1fbBQAJ
>>>
>>> ___
>>> 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 AudioContext.outputLatency

[youenn fablet via webkit-dev]

Looking at https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency,
it states that:
> If the audio output device is changed the outputLatency
 attribute
value will be updated accordingly.

The use case seems ok, but I worry about fingerprinting if it means this
allows a web page to passively identify user speakers.
Say I switch from builtin speakers to Bluetooth headset using MacOS system
menu.

If so, the spec should identify this as potential fingerprinting and should
provide mitigations.
And we should evaluate fingerprinting-free alternatives.
What does PING WG think about this?

Le lun. 13 déc. 2021 à 09:39, Yoav Weiss via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> (Sent on behalf of Hongchan Choi, who failed to subscribe to this mailing
> list)
>
> Hey folks!
>
> AudioContext.outputLatency is to inform the time at which the first sample
> in the buffer is actually processed by the audio output device. This is
> useful when synchronizing the audio generated by Web Audio to other audio
> or video sources or to visual cues [1].
>
> This is already implemented in FireFox and we're looking to ship it in
> Chrome soon [2][3]. Would you all be interested in this feature?
>
> Thanks,
> Hongchan
>
> [1] https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1324552
> [3]
> https://groups.google.com/a/chromium.org/g/blink-dev/c/dTQniJNVVMY/m/hPFwY1fbBQAJ
>
> ___
> 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: WEBRTC-SVC

[youenn fablet via webkit-dev]

Le mar. 19 oct. 2021 à 00:24, Harald Alvestrand via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> Chrome is considering releasing an implementation of the WEBRTC-SVC API.
> API documentation: https://w3c.github.io/webrtc-svc/
>
> This has been available in Chrome behind a flag for some time, and we
> believe it is ready for wider availability.
>
> As part of the process of evaluating whether or not to release this, we
> would like to have input from the WebKit community.
>

Being able to set the SVC mode using
https://w3c.github.io/webrtc-svc/#rtcrtpencodingparameters is a very
welcome addition.

Being able to query the SVC modes should ideally be done using Media
Capabilities.
Media Capabilities already has support at
https://w3c.github.io/media-capabilities/#dom-videoconfiguration-scalabilitymode
.
I would tend to remove
https://w3c.github.io/webrtc-svc/#rtcrtpcodeccapability* from the spec and
filed https://github.com/w3c/webrtc-svc/issues/49 to follow-up on this.
I hope Chrome can delay its decision to expose
RTCRtpCodecCapability.scalabilityModes to allow the W3C WebRTC WG to form a
decision on https://github.com/w3c/webrtc-svc/issues/49.


> Thank you!
>
> Harald Alvestrand
> ___
> 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: preferCurrentTab

[youenn fablet via webkit-dev]

Hi Elad,

At the time of getDisplayMedia design, people advocated against the ability
for a web page to influence or restrict user choice, for security reasons.
Doesn't this property go against that conscious design decision? What is
your security analysis here?

Also, getCurrentViewPort is trying to solve the same problem, in a safer
way (site-isolation), without a device picker. Isn't this a better solution
than preferCurrentTab?
Or are you restricting preferCurrentTab to some specific tabs? Or do you
see that as a short-term solution that would become irrelevant when
getCurrentViewPort is available?

Finally, User Agents are free to remember past user choices so that prompts
can be updated in case a web page is often self-captured by a user.
Has Chrome tried such approaches that do not require a new API?


Le mer. 9 juin 2021 à 13:20, Elad Alon via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> This is a request for WebKit's position on adding a dictionary member in
> MediaStreamConstraints called preferCurrentTab. If preferCurrentTab is set
> to true, the user agent will display the current tab as the most prominent
> option in the media-picker which getDisplayMedia invokes.
>
> Links:
>
>- Explainer
>
> 
>- Spec 
>- ChromeStatus
>
>
> ___
> 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 opinion: Private Network Access secure context restriction

[youenn fablet via webkit-dev]

Le lun. 3 mai 2021 à 14:58, Titouan Rigoudy via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> Hi there friendly WebKittens,
>
> I am gearing up to ship a small first step of Private Network Access [1]
> in Chromium. Roughly:
>
> Websites served over HTTP from public IP addresses will no longer be
> allowed to make subresource fetches to private IP addresses (RFC1918 and/or
> localhost). Specifically, this restriction applies to non-secure contexts.
> Secure contexts are unaffected by this change.
>

This seems like a good move to me.
To be sure to understand, private IP address servers will not be able to
opt-in to be accessed by any HTTP origin.
But they will be able to opt-in for specific HTTPS origins.
Is it correct?

We have metrics in place telling us that ~0.1% of page visits at most make
> use of this feature.
>

Do you know whether these 0.1% happens more often in corporate networks?


>
> I am interested in WebKit's opinion on this matter.
>
> For more details, see the chromestatus entry [2] and the Intent to Ship
> thread on blink-...@chromium.org [3].
>
> Cheers,
> Titouan
>
> [1] https://wicg.github.io/private-network-access/
> [2] https://chromestatus.com/feature/5436853517811712
> [3]
> https://groups.google.com/a/chromium.org/g/blink-dev/c/cPiRNjFoCag/m/DxEEN9-6BQAJ
> ___
> 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: Media Session video conferencing actions

[youenn fablet via webkit-dev]

These new actions make sense to me as well.
Looking at the explainer, it seems there is a plan to add mute/unmute APIs.
I am wondering how this interacts with MediaStreamTrack enabled/muted
attributes and mute/unmute events.

Le dim. 28 mars 2021 à 22:24, Eric Carlson via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

>
>
> On Mar 24, 2021, at 4:01 PM, Tommy Steimel via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
> This is a request for WebKit's position on adding video conferencing
> actions to the Media Session API spec. Note that this is the proposal that
> was discussed on the March 9th 2021 Media WG meeting.
>
> Spec change explainer:
> https://gist.github.com/steimelchrome/d52f0fb9a0a13c63a3cf2d4134b71682
>
> Discussion (first comment is a copy of the explainer above):
> https://github.com/w3c/mediasession/issues/264
>
> Summary:
>
> To make the Media Session API more useful for video conferencing websites,
> we'd like to add "togglemicrophone", "togglecamera", and "hangup" actions
> to the list of supported Media Session Actions.
>
>
>   We are generally supportive of this proposal.
>
>   Thanks for updating the proposal after on our discussions in the recent
> Media WG meeting!
>
> eric
>
> ___
> 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 RTCRtpEncodingParameters.adaptivePtime

[youenn fablet via webkit-dev]

Hi Jakob,

This looks ok to me.
I think it was discussed within WebRTC WG and reached consensus there as
well.


Le jeu. 25 mars 2021 à 11:18, Jakob Ivarsson via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> Hi webkit-dev,
>
> We would like to get an official position on the addition of adaptivePtime
> flag in RTCRtpEncodingParameters. Enabling the flag allows a sender to
> dynamically adjust the audio packet rate to better utilize the network link.
>
> Explainer:
> https://w3c.github.io/webrtc-extensions/explainer#a-new-flag-in-rtcrtpencodingparameters-for-adaptive-packet-rate
> Spec:
> https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-adaptiveptime
>
> The flag is currently available through an origin trial in Chrome (
> https://chromestatus.com/feature/5752004691361792).
>
> // Jakob
> ___
> 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] Alicia Boya as new reviewer

[youenn fablet via webkit-dev]

Congrats as well Alicia!

Le jeu. 11 mars 2021 à 21:35, BJ Burg via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> Congrats Alicia!
>
> On Mar 11, 2021, at 8:00 AM, Xabier Rodríguez Calvar via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
> Hi,
>
> It's my pleasure to announce that my colleague Alicia Boya has earned
> the reviewer status. I'm sure she will be a wonderful reviewer.
>
> Well done Alicia! ️
>
> Best regards.
> ___
> 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] Webkit MediaRecorder Timeslice functionality on Safari 14.0.2 Mojave

[youenn fablet via webkit-dev]

Hi Mark,

Thanks for reaching out.

For timeslice specific questions, it might be best to continue discussions
in https://bugs.webkit.org/show_bug.cgi?id=202233.

Timeslice support in older versions of MacOS and iOS is tricky.
On those OSes, including MacOS Mojave, MediaRecorder is not enabled by
default.

On the most recent BigSur and iOS versions, MediaRecorder should be enabled
by default and timeslice should be supported.

Hope this helps,
Y

Le lun. 1 févr. 2021 à 17:29, Gallery via webkit-dev <
webkit-dev@lists.webkit.org> a écrit :

> Hi Folks
>
> We are developing a streaming system which uses MediaRecorder with
> timeslice.
>
> It's clear that Safari only has MediaRecorder as developer experiment, and
> that older versions of Safari dont support timeslice anyway.
> However, a recent WebKit thread
> https://bugs.webkit.org/show_bug.cgi?id=202233
> Suggests that timeslice *is* implemented in Safari 14.0.2 and the author
> provided an example jsfiddle:  https://jsfiddle.net/hdwc2xzL/
>
> Our experience suggests all is not as expected:
>
> *On Big Sur (on Apple DTK)*
> *- Safari 14.02 * (with mediarecorder enabled in experimental features)
> does appear to work as expected.  MediaRecorder and timeslice all correct.
>
>
> *On macOS Mojave (on MacBook Pro intel)*
> -* Safari 13* - (with mediarecorder enabled in experimental features).
> MediaRecorder initialises OK and works as expected (but without timeslice
> callbacks)
> - *Safari 14.0.2* (with mediarecorder enabled in experimental features)
>  Throws an error when initialising MediaRecorder *"NotSupportedError: The
> MediaRecorder is unsupported on this platform”*
>
> Both our own mechanism. and the jsfiddle referenced above shows the same
> error;
> try
> {
> mediaRecorder = new MediaRecorder(window.stream, options);  *//
> options is just  {videoBitsPerSecond: 150} - hence allowing default
> mimetype, window.stream successful from getUserMedia*
> }
> catch (e)
> {
> console.error('navigator.getUserMedia error:', e);
> errorMsgElement.innerHTML = `navigator.getUserMedia error:${e.toString()}`;
>
> // fails: *"NotSupportedError: The MediaRecorder is unsupported on this
> platform”*
>
>  }
>
> so we dont even get as far as calling mediaRecorder.start(timeslice_ms)
> any more (as we did with Safari 13)
>
>
> *Could anyone explain this behaviour in Mojave ?   *
> *Should MediaRecorder work on the official shipping 14.02 downloaded on
> Mojave ?*
> *On a related note - what should we expect from mobile Safari with respect
> to timeslice MediaRecorder ?*
>
> *When might we see MediaRecorder enabled by default so we can use it for
> customer applications ???*
>
> *Many Thanks !*
>
>
>
> ___
> 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 WebRTC Insertable Streams

[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

[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?

[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

[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

[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

[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

[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

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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)

[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

[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?

[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?

[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?

[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

[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

[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

[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

[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

[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

[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!

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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!

[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

[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

[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

[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

[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

[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

[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

[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

[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