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

uced 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 >

Re: [webkit-dev] Request for position: Response.json() static method

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: > >

Re: [webkit-dev] Request for position: Capture Handle Identity

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

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

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, >

Re: [webkit-dev] Request for Position: Fetch Metadata

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

Re: [webkit-dev] Request for position on AudioContext.outputLatency

erated 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, 20

Re: [webkit-dev] Request for position on AudioContext.outputLatency

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

Re: [webkit-dev] Request for position: WEBRTC-SVC

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

Re: [webkit-dev] Request for position: preferCurrentTab

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

Re: [webkit-dev] Request for opinion: Private Network Access secure context restriction

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

Re: [webkit-dev] Request for position: Media Session video conferencing actions

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 <

Re: [webkit-dev] Request for Position on RTCRtpEncodingParameters.adaptivePtime

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

Re: [webkit-dev] Alicia Boya as new reviewer

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

Re: [webkit-dev] Webkit MediaRecorder Timeslice functionality on Safari 14.0.2 Mojave

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

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

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

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

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

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

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. > > - >

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

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

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

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

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

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

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

> 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

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

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

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

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

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

> 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

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

> 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

Re: [webkit-dev] Standard process for exporting new WPT 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. >> > > Oh, that is surprising. > >

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

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

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

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

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

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

Re: [webkit-dev] OWNERS policy

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

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

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

[webkit-dev] Exporting WPT tests

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

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

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.

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

. 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

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

>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

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

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

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

3c/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 fable

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

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

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

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 <

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

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

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

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 upd

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

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

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

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

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

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

Re: [webkit-dev] Another WPT bite

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.

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

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

> 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

Re: [webkit-dev] Another WPT bite

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.

Re: [webkit-dev] Another WPT bite

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: > >>

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

, 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

Re: [webkit-dev] Another WPT bite

> 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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

eid...@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 &

[webkit-dev] Another WPT bite

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

Re: [webkit-dev] ccache on mac

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

Re: [webkit-dev] Exporting WPT tests

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,

[webkit-dev] Exporting WPT tests

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

[webkit-dev] Cleaning-up WPT tests

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

uary 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 &g

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

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, >

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

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,

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

> • 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

Re: [webkit-dev] WebKit build failed

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

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

to 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 RTCPeerConne

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

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

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

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

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.

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

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

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

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.

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

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 : >

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

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

[webkit-dev] WebIDL change

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

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

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

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

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

[webkit-dev] Fetch API

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

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

> > > 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 > > > > __

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

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

[webkit-dev] Importing web-platform-tests

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 -

[webkit-dev] JS Builtins invading WebCore

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.

Re: [webkit-dev] CMake on Windows

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: > >

[webkit-dev] Removing XHR_TIMEOUT compilation guard

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

[webkit-dev] WTF and STL

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

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

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

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

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

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

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

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

, -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

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

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

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

/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

[webkit-dev] Running W3C tests using wptserve

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

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

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

Re: [webkit-dev] Streams API

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

[webkit-dev] Networking process scope

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

  1   2   >