February 2021 - webkit-dev - lists.webkit.org

Re: [webkit-dev] Position on emerging standard: WebCodecs
by Chris Cunningham 10 Feb '21

10 Feb '21

On Tue, Feb 9, 2021 at 4:20 PM Chris Cunningham <chcunningham(a)chromium.org> wrote: > +mmaxfield(a)apple.com, who mentioned similar privacy concerns in a WebGPU > meeting back in October. > +jer.noble(a)apple.com, since we're recently talking about this spec in > Media WG meetings. > > Hi Group, > > Sorry to revive an old thread! I want to give a few updates. > > One request: please offer replies in the form of github issues. This helps > us track/scope the feedback. > https://github.com/WICG/web-codecs/issues > > > (let me know if there is a more detailed proposal). > > The specification is now quite detailed. > https://wicg.github.io/web-codecs/ > > > - Any media pipeline should be off the JS main thread, by default. > > This does not seem guaranteed by the proposal. > > The spec now mandates that the media pipeline work be offloaded to a > "codec thread". This may in fact be a fan out of many threads, but is not > allowed to be the main ("control") thread. > > > Capabilities is indeed an issue. The more you need to understand the > > codec, the wider is the API and the potential fingerprinting surface. > > The spec has an outstanding PR > <https://github.com/WICG/web-codecs/pull/120> to add a capabilities API > like so: > let supportInfo = await VideoDecoder.isConfigSupported({ codec: 'vp8', ... > }); > > We agree that this adds to the fingerprinting surface. I've added a Privacy > Considerations section > <https://wicg.github.io/web-codecs/#privacy-considerations> to describe > this in more detail and suggest possible mitigations. Happy to discuss this > more on the github. > > > 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? > > Possibly. Implementers might mitigate by adding artificial delay to emit > codec outputs. > > Best, > Chris > Apologies, I'm re-sending because my first attempt bounced for not having subscribed to this list.

1 0

Request for Position on Storage Foundation API
by Emanuel Krivoy 05 Feb '21

05 Feb '21

(Resending with correct subject for findability and to add further context. Sorry for the spam.) Hello webkit-dev, We would like to get an official position from WebKit on the Storage Foundation API (https://github.com/fivedots/storage-foundation-api-explainer) a storage API that resembles a very basic filesystem, with direct access to stored data through buffers and offsets. Our goal is to give developers flexibility by providing generic, simple, and performant primitives upon which they can build higher-level components. It's particularly well suited for Wasm-based libraries and applications that want to use custom storage algorithms to fine-tune execution speed and memory usage. The API is currently available behind a flag in Google Chrome. We've received feedback before in #4 ( https://github.com/fivedots/storage-foundation-api-explainer/issues/4) asking to clarify our relationship to other storage APIs. We are still working on gathering all the required data to resolve the issues raised there, we intend to update it as soon as we can. Thank you, Emanuel Krivoy

2 1

Request for Position on Foundation Storage API
by Emanuel Krivoy 05 Feb '21

05 Feb '21

Hello webkit-dev, We would like to get an official position from WebKit on the Storage Foundation API (https://github.com/fivedots/storage-foundation-api-explainer) a storage API that resembles a very basic filesystem, with direct access to stored data through buffers and offsets. Our goal is to give developers flexibility by providing generic, simple, and performant primitives upon which they can build higher-level components. It's particularly well suited for Wasm-based libraries and applications that want to use custom storage algorithms to fine-tune execution speed and memory usage. The API is currently available behind a flag in Google Chrome. Thank you, Emanuel Krivoy

1 0

Scripts default to Python 3
by Jonathan Bedard 04 Feb '21

04 Feb '21

Hello contributors, Now that trunk no longer supports Mojave, it’s time to change our Python shebangs to Python 3 in our scripts. https://bugs.webkit.org/show_bug.cgi?id=221411 <https://bugs.webkit.org/show_bug.cgi?id=221411> is the umbrella bug that covers this change. We aren’t ready to drop Python 2 support quite yet, among other reasons, there is still some work to be done for run-webkit-tests and run-api-tests to support Python 3.8, but this is one step closer to that goal. Jonathan WebKit Continuous Integration

1 0

Re: [webkit-dev] Replacing PHP with Python in Layout Tests
by Jonathan Bedard 03 Feb '21

03 Feb '21

>> Hello Contributors, >> >> To help reduce the number of dependencies WebKit?s tools have, I would >> like to replace our PHP tests (and resources used by tests) with Python 3 >> CGI scripts. I?ve already attempted to convert a few dozen PHP tests and >> resources to demonstrate that this is both possible and that the resulting >> Python is comparable to the existing PHP. Additionally, as advertised in >> Big Sur, PHP is only included for compatibility with legacy software and is >> not recommended. >> >> There are still a few issues to resolve (namely, an issue with Python 3 on >> some of our Windows machines), in the mean time, I want to determine if >> other platforms have any issues with replacing our PHP tests with Python 3. > > > BTW, after you finish the task, can we remove Python 2 supports from all > Python scripts? Or, should we keep Python 2&3 support until Mojave support > ends? The biggest blocker for that right now is <https://bugs.webkit.org/show_bug.cgi?id=217680 <https://bugs.webkit.org/show_bug.cgi?id=217680>>, which I’m actively working on. I’ll send out a message early next week soliciting a larger discussion about removing Python 2 support. Jonathan

1 0

Replacing PHP with Python in Layout Tests
by Jonathan Bedard 02 Feb '21

02 Feb '21

Hello Contributors, To help reduce the number of dependencies WebKit’s tools have, I would like to replace our PHP tests (and resources used by tests) with Python 3 CGI scripts. I’ve already attempted to convert a few dozen PHP tests and resources to demonstrate that this is both possible and that the resulting Python is comparable to the existing PHP. Additionally, as advertised in Big Sur, PHP is only included for compatibility with legacy software and is not recommended. There are still a few issues to resolve (namely, an issue with Python 3 on some of our Windows machines), in the mean time, I want to determine if other platforms have any issues with replacing our PHP tests with Python 3. Jonathan WebKit Continuous Integration

2 1

Webkit MediaRecorder Timeslice functionality on Safari 14.0.2 Mojave
by Gallery 01 Feb '21

01 Feb '21

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 <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/ <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: 1500000} - 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 !

2 1