Re: [webkit-dev] Running the GTK port on macOS with Docker

2021-10-15 Thread Philippe Normand via webkit-dev
On Fri, 2021-10-15 at 10:04 +1100, Jean-Yves Avenard wrote:
> Hi.
> 
> Personally, I would love a way to quickly build for GTK on my Mac, as
> for now I had to rely on pushing to the EWS, wait for compilation
> errors and fix them as I went.
> 
> So something running in docker using my local tree would be ideal.
> 

Alright, thanks for answering Jean-Yves :) I'll clean-up the experiment
a bit, document it and ping you for testing when it's ready.

Philippe

> Jean-Yves
> 
> > On 15 Oct 2021, at 1:21 am, Philippe Normand via webkit-dev
> >  wrote:
> > 
> > Hi,
> > 
> > The WPE/GTK ports nowadays rely on a SDK that provides all the
> > tools
> > needed for development, it's used on the bots as well. Currently we
> > run
> > it with Flatpak, but technically, Docker can also be used.
> > 
> > I've actually checked that a GTK MiniBrowser build downloaded from
> > the
> > bots can run on macOS with Docker, that involves setting up
> > XQuartz,
> > it's not great, but for quick testing, I wonder if that could be
> > useful
> > for the Apple folks?
> > 
> > The GTK port could also be built on macOS using this docker setup,
> > the
> > SDK includes the GCC and clang versions used on the bots.
> > 
> > You can already do this with a VM, but then if you want to use the
> > SDK
> > it adds another lever of virtualization, which is not great. So
> > directly using the SDK through Docker seems more appealing, to me
> > at
> > least :)
> > 
> > WPE can't run, I haven't managed to start Weston with its X11
> > backend
> > in XQuartz... Ideally I'd prefer a native Wayland compositor for
> > macOS
> > but that doesn't seem to exist yet.
> > 
> > Anyway, please let me know if some folks are interested.
> > 
> > Philippe
> > ___
> > 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 the GTK port on macOS with Docker

2021-10-14 Thread Jean-Yves Avenard via webkit-dev
Hi.

Personally, I would love a way to quickly build for GTK on my Mac, as for now I 
had to rely on pushing to the EWS, wait for compilation errors and fix them as 
I went.

So something running in docker using my local tree would be ideal.

Jean-Yves

> On 15 Oct 2021, at 1:21 am, Philippe Normand via webkit-dev 
>  wrote:
>
> Hi,
>
> The WPE/GTK ports nowadays rely on a SDK that provides all the tools
> needed for development, it's used on the bots as well. Currently we run
> it with Flatpak, but technically, Docker can also be used.
>
> I've actually checked that a GTK MiniBrowser build downloaded from the
> bots can run on macOS with Docker, that involves setting up XQuartz,
> it's not great, but for quick testing, I wonder if that could be useful
> for the Apple folks?
>
> The GTK port could also be built on macOS using this docker setup, the
> SDK includes the GCC and clang versions used on the bots.
>
> You can already do this with a VM, but then if you want to use the SDK
> it adds another lever of virtualization, which is not great. So
> directly using the SDK through Docker seems more appealing, to me at
> least :)
>
> WPE can't run, I haven't managed to start Weston with its X11 backend
> in XQuartz... Ideally I'd prefer a native Wayland compositor for macOS
> but that doesn't seem to exist yet.
>
> Anyway, please let me know if some folks are interested.
>
> Philippe
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Running the GTK port on macOS with Docker

2021-10-14 Thread Philippe Normand via webkit-dev
Hi,

The WPE/GTK ports nowadays rely on a SDK that provides all the tools
needed for development, it's used on the bots as well. Currently we run
it with Flatpak, but technically, Docker can also be used.

I've actually checked that a GTK MiniBrowser build downloaded from the
bots can run on macOS with Docker, that involves setting up XQuartz,
it's not great, but for quick testing, I wonder if that could be useful
for the Apple folks?

The GTK port could also be built on macOS using this docker setup, the
SDK includes the GCC and clang versions used on the bots.

You can already do this with a VM, but then if you want to use the SDK
it adds another lever of virtualization, which is not great. So
directly using the SDK through Docker seems more appealing, to me at
least :)

WPE can't run, I haven't managed to start Weston with its X11 backend
in XQuartz... Ideally I'd prefer a native Wayland compositor for macOS
but that doesn't seem to exist yet.

Anyway, please let me know if some folks are interested.

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


[webkit-dev] Andres Gonzales is now a WebKit Reviewer

2021-10-13 Thread Chris Fleizach via webkit-dev
I'm happy to announce that Andres Gonzales is now a WebKit Reviewer! 
Congratulations Andres!

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


[webkit-dev] GitHub Usernames in contributors.json

2021-10-08 Thread Jonathan Bedard via webkit-dev
Hello WebKittens,

As I continue to bring up GitHub infrastructure, it’s coming time to start 
representing various permissions of the WebKit project in GitHub. In order to 
represent these permissions, we need a record of active contributor’s GitHub 
usernames. We’re doing this in contributors.json, which has now been moved to 
metadata/contributors.json.

Adding GitHub users is supported as of 242713@main 
<https://commits.webkit.org/242713@main> (r283833 
<https://trac.webkit.org/changeset/283833/webkit>).

The expectation is that active contributors are adding their usernames to 
contributors.json over the next 4-6 weeks. A GitHub username in 
contributors.json will be necessary to retain committer and reviewer privileges 
as we transition to GitHub.

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


[webkit-dev] Request for position: Digital Goods API

2021-10-07 Thread Glen Robertson via webkit-dev
Hi,

I am requesting a standards position signal on the Digital Goods API.

This is an API for querying and managing digital products to facilitate
in-app purchases from web applications, in conjunction with the Payment
Request API (which is used to make the actual purchases). The API would be
linked to a digital distribution service connected to via the user agent.

Explainer: https://github.com/WICG/digital-goods/blob/main/explainer.md
Chromestatus: https://chromestatus.com/feature/5339955595313152
TAG review: https://github.com/w3ctag/design-reviews/issues/571

Let me know if you have any questions.

Thanks
-Glen Robertson (Chrome OS web apps platform team)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position on Canvas 2D API extensions

2021-10-06 Thread Fernando Serboncini via webkit-dev
Specification Title: New Canvas 2D API
Specification or proposal URL: explainers
<https://github.com/fserb/canvas2d>, meta WhatWG bug
<https://github.com/whatwg/html/issues/5613>

WhatWG issues with PRs:

   - Canvas context loss <https://github.com/whatwg/html/issues/4809>
   - Conic gradient <https://github.com/whatwg/html/issues/5431>
   - willReadFrequently <https://github.com/whatwg/html/issues/5614>
   - Text modifiers <https://github.com/whatwg/html/issues/5617>
   - Reset function <https://github.com/whatwg/html/issues/5618>
   - RoundRect <https://github.com/whatwg/html/issues/5619>
   - Modern filters <https://github.com/whatwg/html/issues/5621>

All the issues above have had some positive signal from WebKit prior to the
PR submission.
_______________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position on Content Security Policy for dedicated workers

2021-10-01 Thread Antonio Sartori via webkit-dev
Hello Webkit-dev,

I would like to ask for Webkit's official position on how Content Security
Policy [1] for dedicated workers should be delivered. We have had to
possibilities in the past:

(a) Dedicated workers inherit the Content Security Policy from their owner
context.
(b) Dedicated workers use the policy delivered in their resource Content
Security Policy HTTP response headers.

The specced behaviour in CSP3 has initially been to do (a). However,
Mozilla officially requested [2] to switch to (b) quite some time ago.

The spec since then was refactored (inheritance and CSP initialization
moved from CSP to html), and the specified behaviour is now (b) [3].

Chrome currently implements (a) while Firefox implements (b). We would like
[4] to change chrome's behaviour to also adhere to the specified behaviour
and implement (b).

While from the few Web Platform Tests [5] we have in place I am guessing
WebKit also implements (b), I would like to ask for an official position
here.

Thanks,
Antonio

[1] https://w3c.github.io/webappsec-csp/
[2] https://github.com/w3c/webappsec-csp/issues/336#issuecomment-423165240
[3] https://html.spec.whatwg.org/#initialize-worker-policy-container
[4] https://chromestatus.com/feature/5715844005888000
[5]
https://wpt.fyi/results/content-security-policy/inside-worker?label=experimental=master
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position: MSE-for-WebCodecs

2021-10-01 Thread Matt Wolenetz via webkit-dev
Hi webkit-dev,

This is a request for WebKit's position on the MSE-for-WebCodecs featgure:

Explainer:
https://github.com/wolenetz/mse-for-webcodecs/blob/main/explainer.md

MSE spec issue tracking this feature:
https://github.com/w3c/media-source/issues/184

ChromeStatus entry:
https://www.chromestatus.com/feature/5649291471224832

Draft specification:
https://github.com/w3c/media-source/pull/302

TAG review:
https://github.com/w3ctag/design-reviews/issues/576

Please let us know if you have any feedback!

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


[webkit-dev] In-browser annotations

2021-09-30 Thread David Bokan via webkit-dev
Hi webkit-dev!

A few of us over in Chromium are thinking of how we can enable annotation,
directly in the browser, without need for extensions. In a sentence: to
enable shared commentary over web content. We're very early in the stages
of thinking about this, there's no prototype or code written yet but we did
gather some thoughts and ideas in an explainer
<https://github.com/bokand/web-annotations/>.

This isn't a new idea - it's something that's been kicking around
since the early
days of the web
<http://1997.webhistory.org/www.lists/www-talk.1993q2/0416.html>. Is there
anyone at Apple or in the WebKit community that's interested in this space
and would like to help in this effort? Or even just provide some feedback
along the way? Long term this is something that would need to work across
browsers to be successful so we'd really appreciate early involvement from
the WebKit side of the room.

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


Re: [webkit-dev] Request for Position: Unprefix -webkit-text-emphasis* properties

2021-09-29 Thread TAMURA, Kent via webkit-dev
Oh, I found WebKit already unprexed them. Please ignore this RFP.


On Thu, Sep 30, 2021 at 10:31 AM TAMURA, Kent  wrote:

> I'd like to request an official WebKit position on unprefixing
> -webkit-text-emphasis, -webkit-text-emphasis-color,
> -webkit-text-emphasis-position, and -webkit-text-emphasis-style properties.
>
> Firefox already supports unprefixed properties, and doesn't support the
> prefixed properties.
>
> [1]  https://drafts.csswg.org/css-text-decor-4/
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
>

-- 
TAMURA Kent
Software Engineer, Google
___________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for Position: CSS Text Decoration Module for SVG

2021-09-29 Thread Cameron McCormack via webkit-dev
Hi Kent,

> I'd like to request an official WebKit position on expanding support of "CSS 
> Text Decoration Module" [1] for SVG .  Currently WebKit and Blink 
> support only a few features for SVG , and we'd like to add support of 
> features which are currently supported for HTML.
> 
> Firefox already supports various properties for SVG , including 
> text-emphasis-style.

We are in support of this. In general, CSS text properties should all apply to 
SVG text too, unless there is a specific reason/conflict. Please note that CSS 
properties that newly apply to SVG text should not gain presentation 
attributes, per the note below the table in 
https://svgwg.org/svg2-draft/styling.html#PresentationAttributes 
<https://svgwg.org/svg2-draft/styling.html#PresentationAttributes>.

Cameron

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


[webkit-dev] Request for Position: Add 'xml' special handling to Node.lookupNamespaceURI()

2021-09-29 Thread TAMURA, Kent via webkit-dev
I'd like to request an official WebKit position on updating
Node.lookupNamespaceURI() [1] so that it returns the XML namespace URI for
"xml" prefix by default.  It would simplify the implementation
of XPathEvaluator.createNSResolver() significantly, and Firefox already
supports this behavior. [2]

This is a RFP to change the DOM specification.

[1] https://dom.spec.whatwg.org/#dom-node-lookupnamespaceuri
[2] https://github.com/whatwg/dom/issues/857

-- 
TAMURA Kent
Software Engineer, Google
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position: Unprefix -webkit-text-emphasis* properties

2021-09-29 Thread TAMURA, Kent via webkit-dev
I'd like to request an official WebKit position on unprefixing
-webkit-text-emphasis, -webkit-text-emphasis-color,
-webkit-text-emphasis-position, and -webkit-text-emphasis-style properties.

Firefox already supports unprefixed properties, and doesn't support the
prefixed properties.

[1]  https://drafts.csswg.org/css-text-decor-4/

-- 
TAMURA Kent
Software Engineer, Google
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position: CSS Text Decoration Module for SVG

2021-09-29 Thread TAMURA, Kent via webkit-dev
I'd like to request an official WebKit position on expanding support of
"CSS Text Decoration Module" [1] for SVG .  Currently WebKit and
Blink support only a few features for SVG , and we'd like to add
support of features which are currently supported for HTML.

Firefox already supports various properties for SVG , including
text-emphasis-style.

[1]  https://drafts.csswg.org/css-text-decor-4/

-- 
TAMURA Kent
Software Engineer, Google
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position on DNS-based HTTP->HTTPS redirect

2021-09-28 Thread Eric Orth via webkit-dev
Specifically the HSTS-like behavior outlined by Section 8.5 of
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07

We understand that Webkit (or perhaps DNS infrastructure more generally in
Apple OS's) implements general support for HTTPS records and has been
querying them since 2020, but we are unfamiliar with and request a position
on Webkit's support for the specific HTTP->HTTPS redirect behavior.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Kimmo Kinnunen is a WebKit Reviewer

2021-09-27 Thread Ken Russell via webkit-dev
Congratulations and great work Kimmo!

-Ken



On Mon, Sep 27, 2021 at 11:07 AM Dean Jackson via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> I'm happy to announce that Kimmo Kinnunen is now a WebKit Reviewer.
> Congratulations Kimmo!
>
> Dean
>
> ___________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>


-- 
I support flexible work schedules, and I’m sending this email now because
it is within the hours I’m working today.  Please do not feel obliged to
reply straight away - I understand that you will reply during the hours you
work, which may not match mine. (credit: jparent@)
_______________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Kimmo Kinnunen is a WebKit Reviewer

2021-09-27 Thread Dean Jackson via webkit-dev
I'm happy to announce that Kimmo Kinnunen is now a WebKit Reviewer. 
Congratulations Kimmo!

Dean



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position: block navigation toward external protocol from sandboxed iframe.

2021-09-27 Thread Arthur Sonzogni via webkit-dev
Hi webkit-dev,
This is a request for Webkit's position about blocking navigation toward
external protocols from sandboxed iframe.

*Summary:*
Gates sandboxed iframe navigation toward external protocol behind any of:

   - allow-popups
   - allow-top-navigation
   - allow-top-navigation-with-user-gesture (+ user gesture)


*Motivation:*
Developers are surprised that a sandboxed iframe can navigate and/or
redirect the user toward an external application.
General iframe navigation in sandboxed iframe are not blocked normally,
because they stay within the iframe. However they can be seen as a popup or
a top-level navigation when it leads to opening an external application. In
this case, it makes sense to extend the scope of sandbox flags, to block
malvertising.


*Issue:*https://github.com/whatwg/html/issues/2191


*Specification:*https://github.com/whatwg/html/pull/7124


*Mozilla position*https://github.com/mozilla/standards-positions/issues/581

I would love to hear your feedback.

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


[webkit-dev] Request for position on app history API

2021-09-24 Thread Domenic Denicola via webkit-dev
Hi webkit-dev,

The Chrome team, with some help from Mozilla folks, have been working on a 
proposal for a new history/navigation API aimed specifically at the needs of 
single-page apps. The current name is the "app history API". You can see the 
explainer at [1] (and the name bikeshedding thread at [2] ).

So far the API has a lot of web developer enthusiasm and engagement on the 
issue tracker, including a polyfill [3]. We've been prototyping behind a flag 
in Chromium and are planning to go to origin trial soon, as we have some large 
sites that want to try conditionally switching out their current router code 
for code based on app history to see if this brings about the desired 
simplifications or shakes out any bugs. We also have a lot of web platform 
tests [4] and a mostly-complete but definitely still WIP spec [5].

We'd love to get your thoughts, whether they're a general appraisal or a more 
in-depth dive into the API choices and spec. I'm hopeful we can together make 
developers really happy with a new API for this historically-tricky problem 
space.

Other links you may enjoy are the Mozilla standards positions issue [6] and the 
initial W3C TAG design review [7].

Thanks so much for your time,
-Domenic

[1]: https://github.com/WICG/app-history
[2]: https://github.com/WICG/app-history/issues/83
[3]: https://github.com/frehner/appHistory
[4]: https://github.com/web-platform-tests/wpt/tree/master/app-history
[5]: https://wicg.github.io/app-history/
[6]: https://github.com/mozilla/standards-positions/issues/543
[7]: https://github.com/w3ctag/design-reviews/issues/605
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Removal of makeRef() / makeRefPtr()

2021-09-22 Thread Chris Dumez via webkit-dev
Hi,

With WebKit adopting C++17 a while back, there are no longer any benefits to 
using makeRef() / makeRefPtr() as far as I can tell.

Code that was written like so:
auto protectedThis = makeRef(*this);
auto protectedPage = makeRefPtr(page);
auto result = makeRef(foo->bar());
auto lambda = [protectedThis = makeRef(*this)] { };
m_node = makeRef(node); // m_node being a Ref
m_node = makeRefPtr(node); // m_node being a RefPtr

Can now be written in a more concise way:
Ref protectedThis { *this };
RefPtr protectedPage { page };
Ref result = foo->bar();
auto lambda = [protectedThis = Ref { *this }] { };
m_node = node;
`m_node = node;` or `m_node =  // depending if node is a reference or 
pointer.

I am currently in the process on transitioning our code from one style to the 
other and removing makeRef() / makeRefPtr() altogether.
I am sending this email so people are not confused when they try to use 
makeRef() / makeRefPtr() in new code.

--
 Chris Dumez




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


[webkit-dev] Request for Position on Gamepad input events

2021-09-21 Thread Matt Reynolds via webkit-dev
Hello webkit-dev,

I would like to request Webkit's official position on adding events for
button and axis inputs to the Gamepad API.

This feature would add events that fire when gamepad button or axis inputs
change, enabling applications to respond to input changes as they occur
instead of relying on the current polling-only interface. The goal is to
enable applications to respond to gamepad inputs with minimum latency.

Chrome Platform Status: https://chromestatus.com/feature/5989275208253440
Explainer:
https://docs.google.com/document/d/1GUeLs5RXdTlaiLgyBf6FUdJXu71dzCpsiLkawkCLAXA
Design doc:
https://docs.google.com/document/d/1rnQ1gU0iwPXbO7OvKS6KO9gyfpSdSQvKhK9_OkzUuKE
Spec change pull request: https://github.com/w3c/gamepad/pull/152
TAG design review: https://github.com/w3ctag/design-reviews/issues/662

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


[webkit-dev] Intent to Remove: XSS Auditor

2021-09-20 Thread Brent Fulgham via webkit-dev
Hi Folks,

We have continued to ship the XSS Auditor for a number of years after Blink and 
other engines have abandoned this approach in favor of modern XSS defenses like 
CSP.

The XSS Auditor was a great idea in its day, but now poses a maintenance burden 
that far outweighs the small (perhaps nonexistent) benefit it provides.

We intend to remove the XSS Auditor in the coming weeks to better align with 
the behavior of other browsers.

Please let me know as soon as possible if you have reasons why this would be a 
significant issue for your port.

Best regards,

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


[webkit-dev] Request for Position: Auto-expanding details elements

2021-09-16 Thread Joey Arhar via webkit-dev
Hello WebKit devs,

I am implementing the auto-expanding details elements feature in Chromium,
and I would like to hear WebKit's position on the feature.
Chromestatus entry: https://chromestatus.com/feature/5032469667512320
Spec:
- https://github.com/whatwg/html/pull/6466
-
https://html.spec.whatwg.org/multipage/interaction.html#interaction-with-details
Explainer:
https://github.com/WICG/display-locking/blob/main/explainers/auto-expanding-details-explainer.md
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=228843

Today, users can’t search for content inside details elements when they are
closed. If the user wants to search the page for content inside details
elements with find-in-page, then they have to manually expand every details
element in the page before they use find-in-page.

This feature makes the hidden contents of closed details elements
searchable by find-in-page and makes the browser automatically open them
when trying to scroll to their hidden contents so that users can always
search inside them.

In addition to find-in-page, this feature should also work for Element
fragments (navigating to a hash with an element id) and
ScrollToTextFragment in order to make content hidden inside 
elements more findable, searchable, and shareable.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for Position on contained body to viewport propagation

2021-09-14 Thread Simon Fraser via webkit-dev
No objection.

Simon

> On Sep 14, 2021, at 1:00 PM, Rune Lillesveen via webkit-dev 
>  wrote:
> 
> Hi,
> 
> Blink plans to ship the spec change resolved in [1] to not propagate body 
> styles to the viewport when the body or root elements are contained. Also, 
> see the bug report for WebKit[2].
> 
> [1] https://github.com/w3c/csswg-drafts/issues/5913 
> <https://github.com/w3c/csswg-drafts/issues/5913>[2] 
> https://bugs.webkit.org/show_bug.cgi?id=230274 
> <https://bugs.webkit.org/show_bug.cgi?id=230274>
> 
> -- 
> Rune Lillesveen
> 
> ___________
> 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] Request for Position on contained body to viewport propagation

2021-09-14 Thread Rune Lillesveen via webkit-dev
Hi,

Blink plans to ship the spec change resolved in [1] to not propagate body
styles to the viewport when the body or root elements are contained. Also,
see the bug report for WebKit[2].

[1] https://github.com/w3c/csswg-drafts/issues/5913
[2] https://bugs.webkit.org/show_bug.cgi?id=230274

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


[webkit-dev] Request for Position on WebTransport

2021-09-06 Thread Yutaka Hirano via webkit-dev
Hi webkit-dev,

I would like to ask for WebKit's official position for WebTransport[1]. The
API allows web developers to send and receive datagrams as well as stream
data to/from a server.

WebTransport is designed to be working with multiple protocols, including
WebTransport over HTTP/3[2] and WebTransport over HTTP/2[3]. The current
specification is focusing on WebTransport over HTTP/3.

TAG review: https://github.com/w3ctag/design-reviews/issues/669.

1: https://w3c.github.io/webtransport/
2: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2/

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


[webkit-dev] Request for Position on HTMLScriptElement.supports(type) method

2021-09-05 Thread Tsuyoshi Horo via webkit-dev
Hello webkit-dev.

We would like to get an official position from WebKit
on HTMLScriptElement.supports(type) method (
https://html.spec.whatwg.org/multipage/scripting.html#dom-script-supports).

This method was introduced by the recent spec change (
https://github.com/whatwg/html/pull/7008).

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


Re: [webkit-dev] Request for position on Reporting API (now with structured headers!)

2021-09-02 Thread Ian Clelland via webkit-dev
Hi WebKit -- I sent this request out some time ago, but we're getting
closer to shipping, and I'm wondering if there's a position I can refer to
on the updated Reporting API?

Thanks!

On Mon, Dec 14, 2020 at 10:09 AM Ian Clelland 
wrote:

> Hi WebKit!
>
> In Chrome-land, we've been working on updating our implementation of the
> Reporting API to align with the spec changes made over the last year or so,
> which resolve a number of privacy issues, separating reports generated
> within the context of a single document from those which relate to overall
> network conditions, and isolating reports from unrelated documents. This
> also includes a new header, Reporting-Endpoints, whose value is not
> persisted between document loads.
>
> We're hoping to ship these updates sometime early in the new year, and
> would love to get the thoughts / opinions / feedback from WebKit developers.
>
> Thanks!
> Ian
>
> Some relevant links:
> * Explainer: https://github.com/w3c/reporting
> * Spec: https://w3c.github.io/reporting
> * Recently-opened TAG review:
> https://github.com/w3ctag/design-reviews/issues/585
>
>
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position on WritableStream controller's AbortSignal

2021-09-01 Thread Nidhi Jaju via webkit-dev
Hello Webkit-dev,

I would like to ask for Webkit's official position on WritableStream
controller's AbortSignal API <
https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal and
https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-abortreason>
specification.

This feature permits an underlying sink to rapidly abort an ongoing write
or close when requested by the writer. An underlying sink which doesn't
observe the controller.signal will continue to have the existing behavior.
In addition to being exposed to streams authored in JavaScript, this
facility will also be used by platform-provided streams such as
WebTransport.

See spec change pull request: https://github.com/whatwg/streams/pull/1132

TAG Review: https://github.com/w3ctag/design-reviews/issues/672
Chrome Platform Status Entry:
https://chromestatus.com/feature/5698931422920704

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


Re: [webkit-dev] Request for Position on URLPattern

2021-08-31 Thread Ben Kelly via webkit-dev
FYI, there is now an intent-to-ship [0] for this feature in chromium.

[0]:
https://groups.google.com/a/chromium.org/g/blink-dev/c/-T5pJtBO8h4/m/cAkpQec1AwAJ

On Fri, Aug 13, 2021 at 4:19 PM Ben Kelly  wrote:

> Hello,
>
> I would like to request an official WebKit position on URLPattern [0].
> This is a web API for matching against URLs which is often done in
> javascript routing systems.  We also intend to use this same matching
> primitive in future changes to service worker scopes.  This larger set of
> use cases is described in the explainer. [1]  This particular request,
> however, is just for the URLPattern API and does not yet touch service
> workers.
>
> URLPattern was discussed in a couple of past TPAC meetings:
>
> * TPAC 2019 [2]
> * TPAC 2020 Video Call [3]
>
> In case it's helpful, we also have a summary of web developer feedback
> we've received so far. [4]
>
> Thank you.
>
> Ben
>
> [0]: https://wicg.github.io/urlpattern
> [1]: https://github.com/WICG/urlpattern/blob/main/explainer.md
> [2]:
> https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.d6e4ecicreet
> [3]: https://github.com/w3c/ServiceWorker/issues/1535
> [4]: https://github.com/WICG/urlpattern/blob/main/dev-trials-feedack.md
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-31 Thread Thomas Steiner via webkit-dev
>
> I'm going to stop replying to this thread going forward since I have other
> things to do but please note that my lack of future response does not, in
> any way, constitute a lack of signal or acceptance of an argument, idea, or
> amendment to the proposal.
>

> Apple's WebKit team is against this proposal like we were with the old
> API, and that's not going to change unless a substantial amendment is made
> to address all of the concerns we've raised thus far (as well as any new
> concerns we may raise in the future) for this proposal and the old API.
>

Thanks for the discussion and for taking a clear stance. I know you were
going to stop replying, but so far you have only argued about the `metered`
part of the proposal. Any word on the proposed `sustainedSpeed` attribute?
One way a vendor could implement this API would be to always report `false`
for `metered` (despite the actual value potentially being another) and
still report connection speed data via `sustainedSpeed`.

Cheers,
Tom
_______________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Content Security Policy for WebAssembly

2021-08-30 Thread Francis McCabe via webkit-dev
Hello Webkit devs
  We would like to get an official position on this proposal.
  The proposal is to extend the coverage of W3C Content Security Policy (
https://www.w3.org/TR/CSP3/) to include WebAssembly modules.
  Currently, CSP has an option to manage policy for WebAssembly execution
through the 'unsafe-eval' source directive. However, the primary role of
that directive is to allow eval in JavaScript.
 This change adds a specific source directive 'wasm-unsafe-eval' to CSP
that permits an engine to compile and instantiate a wasm module. In
addition, the proposal is to extend the coverage of existing script-src
directives to include wasm modules downloaded using the fetch API. This
would affect instantiateStreaming and compileStreaming.

The link to the proposed changes to CSP is
https://github.com/w3c/webappsec-csp/pull/293.
The link to the proposed change in WebAssembly's web API is
https://github.com/WebAssembly/content-security-policy/tree/fgm-patch-4

Thank you
Francis McCabe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for Position on Exception Handling in WebAssembly

2021-08-30 Thread Saam Barati via webkit-dev
Hi Andreas,

We're in favor of this proposal.

Tracking work for this proposal in: 
https://bugs.webkit.org/show_bug.cgi?id=229681

Cheers,

- Saam

> On Aug 27, 2021, at 3:26 AM, Andreas Haas via webkit-dev 
>  wrote:
> 
> Hello webkit-dev,
> 
> We would like to get an official position from WebKit on the Exception 
> Handling in WebAssembly proposal 
> (https://github.com/WebAssembly/exception-handling 
> <https://github.com/WebAssembly/exception-handling>). We experimented with 
> WebAssembly Exception Handling successfully in an Origin Trial and plan to 
> ship our implementation soon.
> 
> Cheers, Andreas Haas
> _______________
> 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] Network Information API reboot: request for early feedback

2021-08-30 Thread Ryosuke Niwa via webkit-dev
On Mon, Aug 30, 2021 at 2:58 AM Thomas Steiner  wrote:

> On Mon, Aug 30, 2021 at 11:06 AM Ryosuke Niwa  wrote:
>
>> On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner  wrote:
>>
>>> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  wrote:
>>>
>>>> I don't think exposing the information about whether the connection is
>>>> metered or not is acceptable from the privacy standpoint. Based on the IP
>>>> address of a user & this metered status, a website may even be able to tell
>>>> what kind of carrier plan a given user is in.
>>>>
>>>
>>> Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute
>>> would be a manual user setting, not a browser heuristic. This means you
>>> could easily mark your all-data included WiFi at home as metered if you
>>> wanted to, or, on the opposite end, mark your roaming data plan you
>>> purchased for a ton of money at the airport as unmetered. None of this
>>> happens without the user voluntarily revealing the information.
>>>
>>
>> I don't think it's fair to characterize any given user telling the OS to
>> reduce the data usage as a consent to be profiled by random websites. I
>> would certainly not expect such information to be exposed to ad trackers
>> and alike.
>>
>
> Apple seems to see no issue in exposing this information to iOS/iPadOS
> apps: https://developer.apple.com/videos/play/wwdc2019/712/?time=959.
>
>
>> You could make the same argument for turning on low power mode but
>> battery level being low or having low power mode turned on may reveal the
>> user's socioeconomic status or user's immediate need to take
>> certain actions. It can lead to egregious consequences like this:
>> https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery.
>> I definitely would not want to be seeing ads promoting new SIM cards or ads
>> for a cafe with free WiFi service nearby just because I requested my phone
>> to reduce data usage.
>>
>
> Yes, bad things like that can happen, and the fact that companies like
> Uber make "evil" use of available information is no secret. At the same
> time, companies that make "good" use of information, like Algolia's example
> (
> https://www.algolia.com/blog/engineering/netinfo-api-algolia-javascript-client/),
> hopefully outweigh the disadvantages. We don't prohibit hammers because
> they can be abused as a weapon.
>

Please refer to https://www.w3.org/TR/design-principles/#safe-to-browse.
It's not okay to add a new API which makes the web less safe & private for
users just because the API can be used for good purposes.

And again, the information is exposed to random native apps that can
> likewise profile you. I agree there is a difference between a random native
> app and a random website, but at the same time we have mitigations like
> third-party blocking (and ITP on Apple devices) that make such profiling
> harder and harder.
>

The web and native apps have fundamentally different security &
privacy models. We don't let websites access random files in your system
without an explicit user consent.

On Mon, Aug 30, 2021 at 6:54 AM Thomas Steiner  wrote:

> > None of this happens without the user voluntarily  revealing the
>> > information.
>>
>> How would that possibly work? A new type of permission prompt? It's
>> easy for users to decide whether a website should have geolocation or
>> microphone access, but the risk here is just extra entropy, which is
>> going to be real hard to explain to users.
>>
>
> The current thinking is that there would be no additional permission
> needed. Note that the proposal reduces the overall entropy compared to the
> current API, which exposes more information:
> https://wicg.github.io/netinfo/#networkinformation-interface (compared to
> https://raw.githack.com/tomayac/netinfo/relaunch/index.html#the-networkinformation-interface
> ).
>

That's an API WebKit has never supported and never will for various privacy
& security reasons. Also, I don't think the notion that this old API
exposed more information is necessarily true. The user actively choosing to
use low data mode is very much new information that websites couldn't
necessarily infer from the old API.

Overall, I don't think there is much left to discuss here. What you're
proposing will introduce a serious privacy concern, and it's not acceptable.

I'm going to stop replying to this thread going forward since I have other
things to do but please note that my lack of future response does not, in
any way, constitute a lack of signal or acceptance of an argument, idea, or
amendment to the proposal.

Apple's 

Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Thomas Steiner via webkit-dev
>
> OK, so you are using the existing OS-level network interface settings.
> At least on Linux, that is a heuristic-based per-interface setting with
> a manual override.
>

That's great. It's an entirely manual setting on Android and Windows, but I
imagine certain rules like "SSID is 'Android AP'" already would go a long
way. The way this signal is obtained is not part of the proposal, the
proposal barely focuses on reflecting what the OS provides. This does not
mean browsers couldn't add an override, but it definitely does mean that
the browser is in no way involved with guessing if the current network is
metered or not.


> > None of this happens without the user voluntarily  revealing the
> > information.
>
> How would that possibly work? A new type of permission prompt? It's
> easy for users to decide whether a website should have geolocation or
> microphone access, but the risk here is just extra entropy, which is
> going to be real hard to explain to users.
>

The current thinking is that there would be no additional permission
needed. Note that the proposal reduces the overall entropy compared to the
current API, which exposes more information:
https://wicg.github.io/netinfo/#networkinformation-interface (compared to
https://raw.githack.com/tomayac/netinfo/relaunch/index.html#the-networkinformation-interface
).

Cheers,
Tom
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Michael Catanzaro via webkit-dev



OK, so you are using the existing OS-level network interface settings. 
At least on Linux, that is a heuristic-based per-interface setting with 
a manual override.


None of this happens without the user voluntarily revealing the 
information.


How would that possibly work? A new type of permission prompt? It's 
easy for users to decide whether a website should have geolocation or 
microphone access, but the risk here is just extra entropy, which is 
going to be real hard to explain to users.


Michael


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


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Thomas Steiner via webkit-dev
> Why would it be implemented as a manual setting in the browser, rather
> than a per-connection setting controlled by the OS?


It’s exactly this, a per-connection setting controlled by the OS and
reflected as is by the browser:
https://github.com/tomayac/netinfo/blob/relaunch/README.md#metered-connections
.

Cheers,
Tom
-- 
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
hTtPs://xKcd.cOm/1181/
-END PGP SIGNATURE-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Michael Catanzaro via webkit-dev



On Mon, Aug 30 2021 at 10:16:54 AM +0200, Thomas Steiner via webkit-dev 
 wrote:
Thanks for the reply, Ryosuke! Just to clarify, the `metered` 
attribute would be a manual user setting, not a browser heuristic. 
This means you could easily mark your all-data included WiFi at home 
as metered if you wanted to, or, on the opposite end, mark your 
roaming data plan you purchased for a ton of money at the airport as 
unmetered. None of this happens without the user voluntarily 
revealing the information.


Why would it be implemented as a manual setting in the browser, rather 
than a per-connection setting controlled by the OS?


On Linux, NetworkManager already knows whether each network interface 
is metered or not. Users can override the choice in the unlikely event 
it guesses wrong. Why should a web browser offer a second level of 
override in addition to existing system settings? Are you planning to 
offer a browser-level override for every network interface separately, 
or just one single toggle that doesn't consider which network interface 
is in use?


Michael


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


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Thomas Steiner via webkit-dev
On Mon, Aug 30, 2021 at 11:06 AM Ryosuke Niwa  wrote:

> On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner  wrote:
>
>> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  wrote:
>>
>>> I don't think exposing the information about whether the connection is
>>> metered or not is acceptable from the privacy standpoint. Based on the IP
>>> address of a user & this metered status, a website may even be able to tell
>>> what kind of carrier plan a given user is in.
>>>
>>
>> Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute
>> would be a manual user setting, not a browser heuristic. This means you
>> could easily mark your all-data included WiFi at home as metered if you
>> wanted to, or, on the opposite end, mark your roaming data plan you
>> purchased for a ton of money at the airport as unmetered. None of this
>> happens without the user voluntarily revealing the information.
>>
>
> I don't think it's fair to characterize any given user telling the OS to
> reduce the data usage as a consent to be profiled by random websites. I
> would certainly not expect such information to be exposed to ad trackers
> and alike.
>

Apple seems to see no issue in exposing this information to iOS/iPadOS
apps: https://developer.apple.com/videos/play/wwdc2019/712/?time=959.


> You could make the same argument for turning on low power mode but battery
> level being low or having low power mode turned on may reveal the user's
> socioeconomic status or user's immediate need to take certain actions. It
> can lead to egregious consequences like this:
> https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery.
> I definitely would not want to be seeing ads promoting new SIM cards or ads
> for a cafe with free WiFi service nearby just because I requested my phone
> to reduce data usage.
>

Yes, bad things like that can happen, and the fact that companies like Uber
make "evil" use of available information is no secret. At the same time,
companies that make "good" use of information, like Algolia's example (
https://www.algolia.com/blog/engineering/netinfo-api-algolia-javascript-client/),
hopefully outweigh the disadvantages. We don't prohibit hammers because
they can be abused as a weapon. And again, the information is exposed to
random native apps that can likewise profile you. I agree there is a
difference between a random native app and a random website, but at the
same time we have mitigations like third-party blocking (and ITP on Apple
devices) that make such profiling harder and harder.

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


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Thomas Steiner via webkit-dev
(I noticed the spec preview link had gone stale. Please use
https://raw.githack.com/tomayac/netinfo/relaunch/index.html instead.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Ryosuke Niwa via webkit-dev
On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner  wrote:

> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  wrote:
>
>> I don't think exposing the information about whether the connection is
>> metered or not is acceptable from the privacy standpoint. Based on the IP
>> address of a user & this metered status, a website may even be able to tell
>> what kind of carrier plan a given user is in.
>>
>
> Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute
> would be a manual user setting, not a browser heuristic. This means you
> could easily mark your all-data included WiFi at home as metered if you
> wanted to, or, on the opposite end, mark your roaming data plan you
> purchased for a ton of money at the airport as unmetered. None of this
> happens without the user voluntarily revealing the information.
>

I don't think it's fair to characterize any given user telling the OS to
reduce the data usage as a consent to be profiled by random websites. I
would certainly not expect such information to be exposed to ad trackers
and alike. You could make the same argument for turning on low power mode
but battery level being low or having low power mode turned on may reveal
the user's socioeconomic status or user's immediate need to take
certain actions. It can lead to egregious consequences like this:
https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery.
I definitely would not want to be seeing ads promoting new SIM cards or ads
for a cafe with free WiFi service nearby just because I requested my phone
to reduce data usage.

- R. Niwa
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Thomas Steiner via webkit-dev
On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  wrote:

> I don't think exposing the information about whether the connection is
> metered or not is acceptable from the privacy standpoint. Based on the IP
> address of a user & this metered status, a website may even be able to tell
> what kind of carrier plan a given user is in.
>

Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute
would be a manual user setting, not a browser heuristic. This means you
could easily mark your all-data included WiFi at home as metered if you
wanted to, or, on the opposite end, mark your roaming data plan you
purchased for a ton of money at the airport as unmetered. None of this
happens without the user voluntarily revealing the information.
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-28 Thread Ryosuke Niwa via webkit-dev
I don't think exposing the information about whether the connection is
metered or not is acceptable from the privacy standpoint. Based on the IP
address of a user & this metered status, a website may even be able to tell
what kind of carrier plan a given user is in.

- R. Niwa

On Fri, Aug 20, 2021 at 7:51 AM Thomas Steiner via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hey WebKit folks,
>
> I have rebooted the Network Information API recently. This is all in a
> relatively early stage, but I thought now would be a good time to get your
> feedback on the proposal:
>
> - Motivational doc:
> https://docs.google.com/document/d/1RDA23zSNdDuIcxZTX9Xo3zlD2fxf8dZg9-e0YaJQv0g/edit?usp=sharing
> - Explainer: https://github.com/tomayac/netinfo/blob/relaunch/README.md
> - Spec draft: https://ghcdn.rawgit.org/tomayac/netinfo/relaunch/index.html
>
> Here is the short version:
>
> ```js
> // Is the current network a metered network according to the OS-level
> setting
> // in, e.g., Android or Windows, i.e., _without_ the UA guesstimating it.
> The UA
> // may provide its own (override) setting, though:
> navigator.connection.metered;
> // false
>
> // What is the sustained connection speed, as measured on the OS-level (à
> la
> // `nettop`) for a sliding window and bucketed in buckets of exponentially
> // growing size in bit per second, e.g., 25,000,000 (25 Mbit/s), 50,000,000
> // (50 Mbit/s). It's fine to report `Infinity` if the user agent doesn't
> want to
> // reveal more, or if the sustained speed isn't known yet.
> navigator.connection.metered;
> // 5000
>
> // Changes to either of the attributes are exposed via an event:
> navigator.connection.addEventListener("change", (event) => {
>   console.log(event);
> });
> ```
>
> Each of the attributes is accompanied by a client hint header that
> reflects the attribute:
>
> ```bash
> Sec-CH-Metered-Connection: 1
> Sec-CH-Sustained-Speed: 5000
> ```
>
> Thanks in advance for your thoughts, here, or in the motivational document.
>
> Cheers,
> Tom
> _______
> 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: Cryptographically secure random UUIDs

2021-08-27 Thread Chris Dumez via webkit-dev
I forgot to follow-up on this email, sorry.

Support for this landed via https://bugs.webkit.org/show_bug.cgi?id=229240 
<https://bugs.webkit.org/show_bug.cgi?id=229240>.

--
 Chris Dumez




> On Apr 10, 2021, at 7:00 PM, Benjamin Coe via webkit-dev 
>  wrote:
> 
> Hello WebKit folks,
> 
> This is a request for WebKit's position on introducing the JavaScript method 
> randomUUID(), for generating RFC 4122 version 4 identifiers, to the crypto 
> interface.
> 
> - Explainer: https://github.com/WICG/uuid/blob/gh-pages/explainer.md 
> <https://github.com/WICG/uuid/blob/gh-pages/explainer.md>
> - Specification: https://wicg.github.io/uuid/ <https://wicg.github.io/uuid/>
> - ChromeStatus: https://www.chromestatus.com/feature/5689159362543616 
> <https://www.chromestatus.com/feature/5689159362543616>
> 
> Look forward to feedback,
> 
> -- Ben.
> 
> ___
> 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 self.reportError()

2021-08-27 Thread Chris Dumez via webkit-dev
It doesn’t seem like a controversial feature to me and it is indeed a fairly 
small amount of work to support.

I am working on it via Bug 228316 
<https://bugs.webkit.org/show_bug.cgi?id=228316>.

--
 Chris Dumez




> On Aug 27, 2021, at 1:58 PM, Domenic Denicola via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> We recently added a small utility function, self.reportError(), to the HTML 
> Standard [1]. It is pretty simple and just lets developers appropriately send 
> errors to the "error" event handler and the console, like what happens when 
> the browser reports uncaught exceptions.
> 
> This is already implemented in Firefox and we're looking to ship it in Chrome 
> soon. Would you all be interested this feature as well? It should be pretty 
> simple to implement; it was for us at least. [2]
> 
> Thanks,
> -Domenic
> 
> [1]: https://github.com/whatwg/html/pull/1196
> 
> [2]: https://chromium-review.googlesource.com/c/chromium/src/+/3125854
> _______
> 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] Request for position on self.reportError()

2021-08-27 Thread Domenic Denicola via webkit-dev
Hi webkit-dev,

We recently added a small utility function, self.reportError(), to the HTML 
Standard [1]. It is pretty simple and just lets developers appropriately send 
errors to the "error" event handler and the console, like what happens when the 
browser reports uncaught exceptions.

This is already implemented in Firefox and we're looking to ship it in Chrome 
soon. Would you all be interested this feature as well? It should be pretty 
simple to implement; it was for us at least. [2]

Thanks,
-Domenic

[1]: https://github.com/whatwg/html/pull/1196

[2]: https://chromium-review.googlesource.com/c/chromium/src/+/3125854
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for Position on AccessHandles for the Origin Private File System

2021-08-27 Thread Emanuel Krivoy via webkit-dev
Hello webkit-dev,

Has there been any news on this request?

Thank you,
Emanuel Krivoy

On Mon, Aug 9, 2021 at 4:16 PM Emanuel Krivoy  wrote:

> Hello webkit-dev,
>
> We would like to get an official position on AccessHandles (
> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md), an
> extension to the Origin Private File System that brings very performant
> access to data. This new surface differs from existing ones by offering
> in-place and exclusive write access to a file’s content. This change, along
> with the ability to consistently read unflushed modifications and the
> availability of a synchronous variant on dedicated workers, significantly
> improves performance and unblocks new use cases for the File System Access
> API.
>
> We had requested a position on a previous iteration of this API:
> https://lists.webkit.org/pipermail/webkit-dev/2021-February/031689.html.
> This new proposal is a response to feedback that Storage Foundation seemed
> to duplicate existing functionality and should be integrated into the File
> System Access API.
>
> Thank you,
> Emanuel Krivoy
>
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position on Exception Handling in WebAssembly

2021-08-27 Thread Andreas Haas via webkit-dev
Hello webkit-dev,

We would like to get an official position from WebKit on the Exception
Handling in WebAssembly proposal (
https://github.com/WebAssembly/exception-handling). We experimented with
WebAssembly Exception Handling successfully in an Origin Trial and plan to
ship our implementation soon.

Cheers, Andreas Haas

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


[webkit-dev] License for files under Sources/WebCore/Resources

2021-08-24 Thread Yousuke.Kimoto--- via webkit-dev
Hi all,

I have a question about files under Source/WebCore/Resources. WebKit is 
licensed under LGPL so the files under Source/WebCore/Resources are also 
licensed under LGPL. Is my understanding correct?

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


[webkit-dev] Request for Position: Secure Payment Confirmation

2021-08-24 Thread Stephen Mcgruer via webkit-dev
Hi WebKit,

I am seeking WebKit's position on the Secure Payment Confirmation Web API
currently under development in the Web Payments Working Group.

Secure Payment Confirmation (SPC) is a proposed Web API to support
streamlined authentication during a payment transaction. It is designed to
scale authentication across merchants, to be used within a wide range of
authentication protocols, and to produce cryptographic evidence that the
user has confirmed transaction details.

SPC adds payment-specific capabilities atop WebAuthn and is designed with
stronger privacy protections than current risk analysis approaches that
rely on data collection.

Specification Title: Secure Payment Confirmation
Specification or proposal URL:
https://w3c.github.io/secure-payment-confirmation/
Explainer URL:
https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md
TAG review:
https://github.com/w3ctag/design-reviews/issues/544#issuecomment-904606925
Mozilla Standards Position:
https://github.com/mozilla/standards-positions/issues/570

Thanks!

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


Re: [webkit-dev] Request for Position: User Preference Media Features Client Hints Headers

2021-08-23 Thread Thomas Steiner via webkit-dev
This is a friendly ping for a position. Thanks!

On Tue, Jul 20, 2021 at 09:52 Thomas Steiner  wrote:

> Updated links post migration to the WICG:
>
> * Specification or proposal URL:
> https://wicg.github.io/user-preference-media-features-headers/
> * Explainer URL:
> https://github.com/WICG/user-preference-media-features-headers/blob/main/README.md
>
-- 
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
hTtPs://xKcd.cOm/1181/
-END PGP SIGNATURE-
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Help] WebProcess CRASHED

2021-08-20 Thread Michael Catanzaro via webkit-dev
On Fri, Aug 20 2021 at 06:30:16 PM -0600, Alemar 
 wrote:

Okay that makes sense. How do I install debuginfo for webkit though?
Looking into apt, all I can find is this:


Hi, there are distro-specific instructions here:

https://wiki.gnome.org/GettingInTouch/Bugzilla/GettingTraces/DistroSpecificInstructions

debuginfod is not going to help you because no distros use it yet. 
Fedora 35 will be the first to ship with debuginfod enabled, which will 
eliminate the need for debuginfo packages for Fedora users. It's pretty 
cool.


Michael


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


Re: [webkit-dev] [Help] WebProcess CRASHED

2021-08-20 Thread Alemar via webkit-dev
Hello Michael!

Thanks for your prompt reply :)

Okay that makes sense. How do I install debuginfo for webkit though?
Looking into apt, all I can find is this:

apt-cache search debuginfo
debugedit - tools for handling build-ids and paths rewriting in DWARF data
libdebuginfod-common - configuration to enable the Debian debug info server
libdebuginfod-dev - libdebuginfod development libraries and header files
libdebuginfod1 - library to interact with debuginfod (development files)
debuginfod - debuginfo-related http file-server daemon

And webkit:

apt-cache search debug | grep -i webkit
python3-pyqt5.qtwebkit-dbg - Python 3 bindings for Qt5's WebKit module
(debug extensions)

Looking around in google sends me a lot of python/QT-related links to
some (old?) packages that I don't think are related:

https://www.google.com/search?q=webkit+debuginfo

Maybe I should install libdebuginfod1, libdebuginfod1-dev and
debuginfod, then try again?

Thanks again!
-Alemar

El vie, 20 ago 2021 a las 18:24, Michael Catanzaro
() escribió:
>
> On Fri, Aug 20 2021 at 11:27:17 AM -0600, Alemar
>  wrote:
> > #2  0x7fcfd172ff2b in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #3  0x7fcfd37e0622 in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #4  0x7fcfd37efef6 in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #5  0x7fcfd31529a6 in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #6  0x7fcfd315321a in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #7  0x7fcfd2c5b9fd in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #8  0x7fcfd2c5cf0f in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #9  0x7fcfd3095412 in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #10 0x7fcfd30954e6 in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #11 0x7fcfd30c00b4 in  () at
> > /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> > #12 0x7fcfd073d025 in  () at
> > /lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
> > #13 0x7fcfd073d2a3 in  () at
> > /lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
>
> Hi, it looks like you're missing debuginfo for WebKit. When you install
> debuginfo and take the backtrace again, then you'll see function names,
> variables, and even line numbers that will point to exactly what's
> wrong. All we know from that is it crashes somewhere in WebKit, which
> could be anywhere. :)
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Help] WebProcess CRASHED

2021-08-20 Thread Michael Catanzaro via webkit-dev
On Fri, Aug 20 2021 at 11:27:17 AM -0600, Alemar 
 wrote:
#2  0x7fcfd172ff2b in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#3  0x7fcfd37e0622 in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#4  0x7fcfd37efef6 in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#5  0x7fcfd31529a6 in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#6  0x7fcfd315321a in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#7  0x7fcfd2c5b9fd in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#8  0x7fcfd2c5cf0f in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#9  0x7fcfd3095412 in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#10 0x7fcfd30954e6 in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#11 0x7fcfd30c00b4 in  () at 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37

#12 0x7fcfd073d025 in  () at
/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#13 0x7fcfd073d2a3 in  () at
/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18


Hi, it looks like you're missing debuginfo for WebKit. When you install 
debuginfo and take the backtrace again, then you'll see function names, 
variables, and even line numbers that will point to exactly what's 
wrong. All we know from that is it crashes somewhere in WebKit, which 
could be anywhere. :)



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


Re: [webkit-dev] [Help] WebProcess CRASHED

2021-08-20 Thread Alemar via webkit-dev
86_64-linux-gnu/libthread_db.so.1".
Core was generated by
`/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 12 24'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7fcfca6e6fc0 (LWP 15209))]
(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
set = {__val = {0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0}}
pid = 
tid = 
#1  0x7fcfd0f28864 in __GI_abort () at abort.c:79
save_stage = 1
act =
  {__sigaction_handler = {sa_handler = 0x7fff7c1aa140,
sa_sigaction = 0x7fff7c1aa140}, sa_mask = {__val = {140530492189629,
140530586214526, 140528712709552, 140530586214526, 140530492189813,
140528502893856, 94776858736832, 140530492848296, 140530491958562,
140528493772640, 140530586214526, 0, 140530491961100, 140735275508032,
140529317815104, 140528502893856}}, sa_flags = 0, sa_restorer =
0x7fcf56f3bf60}
sigs = {__val = {32, 0, 4097, 0, 0, 0, 0, 140530536140784,
94776857124944, 140530586214526, 140735275508032, 140528712709552,
140528712709576, 140530586214526, 94776858736832, 140735275507840}}
#2  0x7fcfd172ff2b in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#3  0x7fcfd37e0622 in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#4  0x7fcfd37efef6 in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#5  0x7fcfd31529a6 in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#6  0x7fcfd315321a in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#7  0x7fcfd2c5b9fd in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#8  0x7fcfd2c5cf0f in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#9  0x7fcfd3095412 in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#10 0x7fcfd30954e6 in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#11 0x7fcfd30c00b4 in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#12 0x7fcfd073d025 in  () at
/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#13 0x7fcfd073d2a3 in  () at
/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#14 0x7fcfd0b197ef in g_main_context_dispatch () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7fcfd0b6cd28 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x7fcfd0b18e53 in g_main_loop_run () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x7fcfd073d400 in WTF::RunLoop::run() () at
/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#18 0x7fcfd1e03269 in  () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#19 0x7fcfd0f2a565 in __libc_start_main (main=0x5632f41d66d0,
argc=3, argv=0x7fff7c1aa7d8, init=, fini=, rtld_fini=, stack_end=0x7fff7c1aa7c8) at
../csu/libc-start.c:332
self = 
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {94776843921376,
5123207724183545890, 94776843921120, 0, 0, 0, -5122929845401065438,
-5150170039809513438}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0,
0x3, 0x7fff7c1aa7d8}, data = {prev = 0x0, cleanup = 0x0, canceltype =
3}}}
not_first_call = 
#20 0x5632f41d670e in  ()
(gdb) Quit
(gdb) Quit
(gdb) Quit
(gdb) Quit
(gdb) q

El sáb, 14 ago 2021 a las 15:50, Michael Catanzaro
() escribió:
>
>
> Hi, you need to get a backtrace with gdb. There are some instructions
> here:
>
> https://wiki.gnome.org/GettingInTouch/Bugzilla/GettingTraces
>
> Michael
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Network Information API reboot: request for early feedback

2021-08-20 Thread Thomas Steiner via webkit-dev
Hey WebKit folks,

I have rebooted the Network Information API recently. This is all in a
relatively early stage, but I thought now would be a good time to get your
feedback on the proposal:

- Motivational doc:
https://docs.google.com/document/d/1RDA23zSNdDuIcxZTX9Xo3zlD2fxf8dZg9-e0YaJQv0g/edit?usp=sharing
- Explainer: https://github.com/tomayac/netinfo/blob/relaunch/README.md
- Spec draft: https://ghcdn.rawgit.org/tomayac/netinfo/relaunch/index.html

Here is the short version:

```js
// Is the current network a metered network according to the OS-level
setting
// in, e.g., Android or Windows, i.e., _without_ the UA guesstimating it.
The UA
// may provide its own (override) setting, though:
navigator.connection.metered;
// false

// What is the sustained connection speed, as measured on the OS-level (à la
// `nettop`) for a sliding window and bucketed in buckets of exponentially
// growing size in bit per second, e.g., 25,000,000 (25 Mbit/s), 50,000,000
// (50 Mbit/s). It's fine to report `Infinity` if the user agent doesn't
want to
// reveal more, or if the sustained speed isn't known yet.
navigator.connection.metered;
// 5000

// Changes to either of the attributes are exposed via an event:
navigator.connection.addEventListener("change", (event) => {
  console.log(event);
});
```

Each of the attributes is accompanied by a client hint header that reflects
the attribute:

```bash
Sec-CH-Metered-Connection: 1
Sec-CH-Sustained-Speed: 5000
```

Thanks in advance for your thoughts, here, or in the motivational document.

Cheers,
Tom
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position: Add id member to Web Application Manifest

2021-08-18 Thread Phillis Tang via webkit-dev
Hi Webkit,
I am seeking WebKit's position on the proposal to add an "id" member to the
web application manifest(https://www.w3.org/TR/appmanifest/).

The proposal explicitly defines what uniquely identifies a web application
and allows developers to specify the identifier in the manifest.

See spec change pull request https://github.com/w3c/manifest/pull/988

Please let us know if you have any feedback!

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


Re: [webkit-dev] Identifiers in Log and Blame

2021-08-17 Thread Jonathan Bedard via webkit-dev
GitHub has a native blame viewer, 
https://github.com/WebKit/WebKit/blame/main/Makefile 
<https://github.com/WebKit/WebKit/blame/main/Makefile>, which doesn’t display 
any commit string, but seems to display significantly more useful information 
than what the equivalent trac view is 
https://trac.webkit.org/browser/webkit/trunk/Makefile?annotate=blame=281147 
<https://trac.webkit.org/browser/webkit/trunk/Makefile?annotate=blame=281147>.
 Given that Trac’s view makes it difficult to copy revision numbers and would 
instead tend to route a user towards following a link to the blamed commit, 
just like GitHub, I don’t think trying to integrate this solution to GitHub’s 
blame UI makes sense.  Also, the technical challenges of doing so are likely to 
be considerable.

Jonathan

> On Aug 17, 2021, at 11:18 AM, Ryosuke Niwa  wrote:
> 
> Seems like a good improvement but I really don't use command line tools to 
> see my blame. What I need is this getting applied to a online tools like trac 
> and GitHub.
> 
> On Tue, Aug 17, 2021 at 10:57 AM Jonathan Bedard via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
> Hi folks,
> 
> As we move towards using Git as our version control system, more services and 
> scripts will be using identifiers instead of revisions or hashes.  Already, 
> build.webkit.org <http://build.webkit.org/>, results.webkit.org 
> <http://results.webkit.org/> and ews-build.webkit.org 
> <http://results.webkit.org/> all display identifiers alongside revisions.  
> Early in the transition process, we added the git-webkit find command, which 
> converts between hashes, revisions and identifiers.  Recently, we added the 
> git-webkit log and git-webkit blame commands to better support identifiers 
> and native Git checkouts.
> 
> git-webkit log is a wrapper around git log or svn log (depending on your 
> checkout) and annotates the output of those commands with identifiers and 
> revisions. git-webkit log passes the arguments you provide it to your native 
> source code management system, it’s output looks something like this:
> 
> commit 240602@main (fe5476762fc34d2a5547b7d2d8116faa7275acd7, r281148)
> Author: Eric Hutchison mailto:ehutchi...@apple.com>>
> Date:   Tue Aug 17 17:46:39 2021 +
> 
> [Monterey wk2 Release] 
> performance-api/paint-timing/paint-timing-with-worker.html is a flaky crash.
> rdar://82036119 <>.
> ...
> 
> git-webkit blame is a wrapper around git blame or svn blame (again, depending 
> on your checkout) and also annotates the output of these commands with 
> identifiers:
> 
> 230258@main (Keith Rollin2020-10-08 19:10:32 +  1) MODULES = Source 
> Tools
> 184786@main (Jonathan Bedard 2017-02-02 18:42:02 +  2) 
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  3) define 
> build_target_for_each_module
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  4)  for dir in 
> $(MODULES); do \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  5)  
> ${MAKE} $@ -C $$dir PATH_FROM_ROOT=$(PATH_FROM_ROOT)/$${dir}; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  6)  
> exit_status=$$?; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  7)  [ 
> $$exit_status -ne 0 ] && exit $$exit_status; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  8)  done; true
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  9) endef
> ...
> 
> Both commands can switch the commit representation they display with the 
> --identifier, --hash and --revision options.
> 
> Additionally, for those using Git checkouts, the conversion from Subversion 
> revisions to Git hashes no longer requires your checkout to be configured 
> with git-svn. Contributors may find that something like git checkout r281146 
> satisfies whatever need they have to interact with Subversion from Git.
> 
> All of this has been landed on trunk/main as of r280864/240404@main.
> 
> Jonathan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <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] Identifiers in Log and Blame

2021-08-17 Thread Ryosuke Niwa via webkit-dev
Seems like a good improvement but I really don't use command line tools to
see my blame. What I need is this getting applied to online tools like trac
and GitHub.

- R. Niwa

On Tue, Aug 17, 2021 at 10:57 AM Jonathan Bedard via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hi folks,
>
> As we move towards using Git as our version control system, more services
> and scripts will be using identifiers instead of revisions or hashes.
> Already, build.webkit.org, results.webkit.org and ews-build.webkit.org
> <http://results.webkit.org> all display identifiers alongside revisions.
> Early in the transition process, we added the git-webkit find command,
> which converts between hashes, revisions and identifiers.  Recently, we
> added the git-webkit log and git-webkit blame commands to better support
> identifiers and native Git checkouts.
>
> git-webkit log is a wrapper around git log or svn log (depending on your
> checkout) and annotates the output of those commands with identifiers and
> revisions. git-webkit log passes the arguments you provide it to your
> native source code management system, it’s output looks something like this:
>
> commit 240602@main (fe5476762fc34d2a5547b7d2d8116faa7275acd7, r281148)
> Author: Eric Hutchison 
> Date:   Tue Aug 17 17:46:39 2021 +
>
> [Monterey wk2 Release]
> performance-api/paint-timing/paint-timing-with-worker.html is a flaky crash.
> rdar://82036119.
> ...
>
> git-webkit blame is a wrapper around git blame or svn blame (again,
> depending on your checkout) and also annotates the output of these commands
> with identifiers:
>
> 230258@main (Keith Rollin2020-10-08 19:10:32 +  1) MODULES =
> Source Tools
> 184786@main (Jonathan Bedard 2017-02-02 18:42:02 +  2)
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  3) define
> build_target_for_each_module
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  4)  for dir
> in $(MODULES); do \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  5)
> ${MAKE} $@ -C $$dir PATH_FROM_ROOT=$(PATH_FROM_ROOT)/$${dir}; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  6)
> exit_status=$$?; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  7)  [
> $$exit_status -ne 0 ] && exit $$exit_status; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  8)  done; true
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  9) endef
> ...
>
> Both commands can switch the commit representation they display with the
> --identifier, --hash and --revision options.
>
> Additionally, for those using Git checkouts, the conversion from
> Subversion revisions to Git hashes no longer requires your checkout to be
> configured with git-svn. Contributors may find that something like git
> checkout r281146 satisfies whatever need they have to interact with
> Subversion from Git.
>
> All of this has been landed on trunk/main as of r280864/240404@main.
>
> Jonathan
> _______________
> 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] Identifiers in Log and Blame

2021-08-17 Thread Jonathan Bedard via webkit-dev
Hi folks,

As we move towards using Git as our version control system, more services and 
scripts will be using identifiers instead of revisions or hashes.  Already, 
build.webkit.org <http://build.webkit.org/>, results.webkit.org 
<http://results.webkit.org/> and ews-build.webkit.org 
<http://results.webkit.org/> all display identifiers alongside revisions.  
Early in the transition process, we added the git-webkit find command, which 
converts between hashes, revisions and identifiers.  Recently, we added the 
git-webkit log and git-webkit blame commands to better support identifiers and 
native Git checkouts.

git-webkit log is a wrapper around git log or svn log (depending on your 
checkout) and annotates the output of those commands with identifiers and 
revisions. git-webkit log passes the arguments you provide it to your native 
source code management system, it’s output looks something like this:

commit 240602@main (fe5476762fc34d2a5547b7d2d8116faa7275acd7, r281148)
Author: Eric Hutchison 
Date:   Tue Aug 17 17:46:39 2021 +

[Monterey wk2 Release] 
performance-api/paint-timing/paint-timing-with-worker.html is a flaky crash.
rdar://82036119.
...

git-webkit blame is a wrapper around git blame or svn blame (again, depending 
on your checkout) and also annotates the output of these commands with 
identifiers:

230258@main (Keith Rollin2020-10-08 19:10:32 +  1) MODULES = Source 
Tools
184786@main (Jonathan Bedard 2017-02-02 18:42:02 +  2) 
229628@main (Keith Rollin2020-09-22 18:37:51 +  3) define 
build_target_for_each_module
229628@main (Keith Rollin2020-09-22 18:37:51 +  4)  for dir in 
$(MODULES); do \
229628@main (Keith Rollin2020-09-22 18:37:51 +  5)  ${MAKE} 
$@ -C $$dir PATH_FROM_ROOT=$(PATH_FROM_ROOT)/$${dir}; \
229628@main (Keith Rollin2020-09-22 18:37:51 +  6)  
exit_status=$$?; \
229628@main (Keith Rollin2020-09-22 18:37:51 +  7)  [ 
$$exit_status -ne 0 ] && exit $$exit_status; \
229628@main (Keith Rollin2020-09-22 18:37:51 +  8)  done; true
229628@main (Keith Rollin2020-09-22 18:37:51 +  9) endef
...

Both commands can switch the commit representation they display with the 
--identifier, --hash and --revision options.

Additionally, for those using Git checkouts, the conversion from Subversion 
revisions to Git hashes no longer requires your checkout to be configured with 
git-svn. Contributors may find that something like git checkout r281146 
satisfies whatever need they have to interact with Subversion from Git.

All of this has been landed on trunk/main as of r280864/240404@main.

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


Re: [webkit-dev] Request for position: supports() extended syntax for @font-face

2021-08-16 Thread Dominik Röttsches via webkit-dev
Hi Myles,

On Mon, Aug 9, 2021 at 8:09 PM Myles Maxfield  wrote:

>
> Is this something you're considering developing / shipping in WebKit? As
> Myles has been an active contributor in the proposal in issue #633, I am
> hoping we have your support on this matter.
>
>
> Positive signal.
>

Thanks, good to hear.

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


Re: [webkit-dev] [Help] WebProcess CRASHED

2021-08-14 Thread Michael Catanzaro via webkit-dev



Hi, you need to get a backtrace with gdb. There are some instructions 
here:


https://wiki.gnome.org/GettingInTouch/Bugzilla/GettingTraces

Michael


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


[webkit-dev] [Help] WebProcess CRASHED

2021-08-14 Thread Alemar via webkit-dev
Hello list!

Currently I'm having a problem with the library when going to
www.bing.com (it seems to happen only on that site though), where the
browser process crashes. I thought it was my app, but when running it
against the MiniBrowser, it also crashes!

>From the developer tools, I'm suspecting it could be related to trying
to load (and play?) an mp3 file (start.mp3).

The current PC it's running on is a brand-new installed Ubuntu 21.04
up-to-date which seems to use the libwebkit2gtk-4.0-37 library. Such a
PC does not have any audio drivers installed, I'm basically running
off Ubuntu Server with X11, Openbox and NVIDIA drivers, nothing more,
nothing less.

I suspect it could be because it's trying to play the audio file but
it can't. However, the log does not show much:

(MiniBrowser:72279): dbind-WARNING **: 18:07:43.671: AT-SPI: Error
retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was
not provided by any .service files
(WebKitWebProcess:72294): dbind-WARNING **: 18:07:43.752: AT-SPI:
Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was
not provided by any .service files
(WebKitWebProcess:72393): dbind-WARNING **: 18:08:25.851: AT-SPI:
Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was
not provided by any .service files
(WebKitWebProcess:72420): dbind-WARNING **: 18:08:27.415: AT-SPI:
Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was
not provided by any .service files
** (MiniBrowser:72279): WARNING **: 18:08:27.499: WebProcess CRASHED

Is there any way I can try to get more debugging info for you guys to
see if I can fix the problem on my own, but also without building the
full webkit library as it's really heavy and time-consuming?

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


[webkit-dev] Request for Position on URLPattern

2021-08-13 Thread Ben Kelly via webkit-dev
Hello,

I would like to request an official WebKit position on URLPattern [0].
This is a web API for matching against URLs which is often done in
javascript routing systems.  We also intend to use this same matching
primitive in future changes to service worker scopes.  This larger set of
use cases is described in the explainer. [1]  This particular request,
however, is just for the URLPattern API and does not yet touch service
workers.

URLPattern was discussed in a couple of past TPAC meetings:

* TPAC 2019 [2]
* TPAC 2020 Video Call [3]

In case it's helpful, we also have a summary of web developer feedback
we've received so far. [4]

Thank you.

Ben

[0]: https://wicg.github.io/urlpattern
[1]: https://github.com/WICG/urlpattern/blob/main/explainer.md
[2]:
https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.d6e4ecicreet
[3]: https://github.com/w3c/ServiceWorker/issues/1535
[4]: https://github.com/WICG/urlpattern/blob/main/dev-trials-feedack.md
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Position on font-family: emoji (and -webkit-pictograph)

2021-08-13 Thread Michael Catanzaro via webkit-dev
On Fri, Aug 13 2021 at 01:54:39 PM +0200, Frédéric Wang via 
webkit-dev  wrote:
I understand there is backward compat concerns about removing 
features but do we agree to add "emoji" as an alias for 
"-webkit-pictograph", similar to what we did in [3] for "system-ui"?


This sounds pretty uncontroversial. ;)


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


[webkit-dev] Request for position: Clipboard API SVG support

2021-08-13 Thread Wenson Hsieh via webkit-dev
Hi Darwin!

Adding the SVG MIME type ("image/svg+xml") to the list of web-safe clipboard 
types (currently plain text, URLs, and HTML) seems reasonable, provided that 
the UA is able to sanitize the SVG payload (similar to what we do for HTML, 
currently). On Cocoa platforms, this would probably be bridged to and from the 
OS in the form of (sanitized) data corresponding to the UTTypeSVG universal 
type identifier on the platform pasteboard.

As an aside — since SVG documents are parsed using the XML parser as opposed to 
the HTML parser, supporting SVG as a web-safe clipboard type will be a bit more 
involved than simply adding "image/svg+xml" to the list of known UA clipboard 
types and using the current HTML sanitization algorithm.

— Wenson
> Looking for a position on adding svg support for the async clipboard API
> (ex. `navigator.clipboard.write`), in a similar manner to the HTML support
> <https://webkit.org/blog/10855/async-clipboard-api/ 
> <https://webkit.org/blog/10855/async-clipboard-api/>> already added. Thank
> you!
> 
> * Base Specification Title: Clipboard API and events
> <https://www.w3.org/TR/clipboard-apis/ 
> <https://www.w3.org/TR/clipboard-apis/>>
> * Specification or proposal URL: Explainer here
> <https://docs.google.com/document/d/1Rx7gi01avpRRNYKSpp3U4WQdjery0H0IkX2XxDtfZ8I/edit
>  
> <https://docs.google.com/document/d/1Rx7gi01avpRRNYKSpp3U4WQdjery0H0IkX2XxDtfZ8I/edit>>
> Other information:
> * https://www.chromestatus.com/feature/5125790490427392 
> <https://www.chromestatus.com/feature/5125790490427392> has more links
> * https://github.com/w3c/editing/issues/305 
> <https://github.com/w3c/editing/issues/305> may also be relevant
> 
> -- 
> - Darwin Huang
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210702/b7d25b65/attachment.htm
>  
> <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210702/b7d25b65/attachment.htm>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Position on font-family: math

2021-08-13 Thread Frédéric Wang via webkit-dev

Hello WebKittens,

I'd like to get opinion about implementing "font-family: math":

https://www.w3.org/TR/css-fonts-4/#valdef-font-family-math

This is a generic font family name from CSS fonts level 4, which is 
exactly doing what we need for MathML to get a default user-customizable 
math font (instead of the hardcoded values we currently have in the 
mathml.css UA sheet).


See also

https://webkit-search.igalia.com/webkit/rev/b28eaa8f270a9223d76cc4da9072d42baf2061fc/Source/WebCore/css/mathml.css#78

https://trac.webkit.org/wiki/MathML/Fonts#CustomizingMathFont

https://bugs.webkit.org/show_bug.cgi?id=156843

--
Frédéric Wang


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


[webkit-dev] Position on font-family: emoji (and -webkit-pictograph)

2021-08-13 Thread Frédéric Wang via webkit-dev

Hi,

In 2011, a font-family: -webkit-pictograph was implemented in WebKit 
[1]. However a new "font-family: emoji" value was added in the CSS Fonts 
Module Level 4 spec [3].


I understand there is backward compat concerns about removing features 
but do we agree to add "emoji" as an alias for "-webkit-pictograph", 
similar to what we did in [3] for "system-ui"?


Thanks,

[1] https://bugs.webkit.org/show_bug.cgi?id=65197
[2] https://drafts.csswg.org/css-fonts/#font-family-prop
[3] https://bugs.webkit.org/show_bug.cgi?id=151493

--
Frédéric Wang

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


Re: [webkit-dev] Request for position: supports() extended syntax for @font-face

2021-08-09 Thread Myles Maxfield via webkit-dev


> On Aug 9, 2021, at 7:49 AM, Dominik Röttsches  wrote:
> 
> 
> Hi @ webkit-dev, hi Myles,
> 
> we'd like to know your opinion on the extended supports() 
> syntax of the @font-face src: descriptor. 
> 
> Specification or proposal URL: 
> https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing, in particular 
> the [ format( [supports #]?)]? part of the spec.
> The changes have originally been approved / developed in the CSS WG process 
> already. As we're considering shipping this feature, we'd like to know if 
> Apple is considering implementing support as well.
> 
> CSS WG Resolution for issue #633 initially adding format() and supports() 
> syntax
> CSS WG change in issue #6340 to clarify parsing rules for supports syntax
> 
> Is this something you're considering developing / shipping in WebKit? As 
> Myles has been an active contributor in the proposal in issue #633, I am 
> hoping we have your support on this matter.

Positive signal.

> 
> Thanks in advance,
> 
> Dominik
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: CSS @font-face descriptor advance-override

2021-08-09 Thread Myles Maxfield via webkit-dev
Positive signal on size-adjust

> On May 4, 2021, at 3:38 AM, Dominik Röttsches via webkit-dev 
>  wrote:
> 
> 
> As an update to our intent here. as posted by Xiaocheng earlier, we're 
> planning to ship the size-adjust descriptor. 
> 
>> On Mon Feb 22 16:50:28 PST 2021 Xiaocheng Hu xiaoche...@chromium.org wrote:
>> 
>> Hi webkit-dev,
>> This is a request for WebKit's position on a new descriptor
>> 'advance-override' of the CSS @font-face rule.
>> This is a new feature that the CSSWG just added into CSS Fonts Level 5 for
>> reducing layout shifting caused by web fonts. Chrome has already
>> implemented it in M90 behind a flag.
>  
>> Explainer:
>> https://gist.github.com/xiaochengh/3aae8a97d1b0388c8e701819b63e2c49
>> Spec: https://drafts.csswg.org/css-fonts-5/#font-metrics-override-desc
>> May I assume https://github.com/w3c/csswg-drafts/pull/5991, authored by
>> Myles, as a positive signal?
>> Thank you!
> _______
> 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] Request for position: supports() extended syntax for @font-face

2021-08-09 Thread Dominik Röttsches via webkit-dev
Hi @ webkit-dev, hi Myles,

we'd like to know your opinion on the extended supports()
syntax of the @font-face src: descriptor.


   - Specification or proposal URL:
   https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing, in
   particular the [ format(
   <https://drafts.csswg.org/css-fonts-4/#font-format-values> [supports
   
   <https://drafts.csswg.org/css-fonts-4/#font-technology-values>#]?)]? part
   of the spec.

The changes have originally been approved / developed in the CSS WG process
already. As we're considering shipping this feature, we'd like to know if
Apple is considering implementing support as well.


   - CSS WG Resolution for issue #633
   <https://github.com/w3c/csswg-drafts/issues/633> initially adding
   format() and supports() syntax
   - CSS WG change in issue #6340
   <https://github.com/w3c/csswg-drafts/issues/6340> to clarify parsing
   rules for supports syntax


Is this something you're considering developing / shipping in WebKit? As
Myles has been an active contributor in the proposal in issue #633, I am
hoping we have your support on this matter.

Thanks in advance,

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


[webkit-dev] Request for Position on AccessHandles for the Origin Private File System

2021-08-09 Thread Emanuel Krivoy via webkit-dev
Hello webkit-dev,

We would like to get an official position on AccessHandles (
https://github.com/WICG/file-system-access/blob/main/AccessHandle.md), an
extension to the Origin Private File System that brings very performant
access to data. This new surface differs from existing ones by offering
in-place and exclusive write access to a file’s content. This change, along
with the ability to consistently read unflushed modifications and the
availability of a synchronous variant on dedicated workers, significantly
improves performance and unblocks new use cases for the File System Access
API.

We had requested a position on a previous iteration of this API:
https://lists.webkit.org/pipermail/webkit-dev/2021-February/031689.html.
This new proposal is a response to feedback that Storage Foundation seemed
to duplicate existing functionality and should be integrated into the File
System Access API.

Thank you,
Emanuel Krivoy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] 2021 WebKit Contributors Meeting - Save the Date

2021-08-06 Thread Jonathan Davis via webkit-dev
Hello WebKit Contributors,

You are invited to participate in a virtual WebKit Contributors Meeting hosted 
online via WebEx on Monday, September 27th from 1 PM to around 6 PM Pacific and 
Tuesday, September 28th from 8 AM to around noon Pacific.

To attend you must be an active contributor to the WebKit open-source project. 
The meeting will be free of charge, and registration will open soon.

The event will feature presentation-led discussions of 10-40 minutes long, 
followed by queue-moderated discussion. If you have a topic to present for 
discussion, please email me, or message me on WebKit Slack. There will also be 
a lightning talk segment if you have a topic you can present in less than 10 
minutes.

Feel free to reach out to me with ideas or questions on this year’s online 
event.

Thank you,
Jon Davis
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Commit Queue down for maintainence

2021-07-28 Thread Aakash Jain via webkit-dev
Commit Queue is back online. Please let me know if you notice any issue.

Thanks
Aakash

> On Jul 28, 2021, at 1:27 PM, Aakash Jain  wrote:
> 
> Hi Everyone,
> 
> We just took commit-queue bots offline for some maintenance. I will send 
> another update when they are back online.
> 
> Thanks
> Aakash

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


[webkit-dev] Fixed merged commits in GitHub Mirror

2021-07-28 Thread Jonathan Bedard via webkit-dev
Morning folks,

Last Friday, git-svn failed us and merged two commits together (this was the 
cause of the incorrect commits.webkit.org <http://commits.webkit.org/> links 
folks saw over the last few days). I’ve fixed it, but that fix involves 
force-pushing, if you have a GitHub checkout, you might need to `git reset 
HEAD~125 —hard` and re-pull to fix the problem (be aware of local commits you 
may have, because `git reset —hard` will throw those out).

Thank you for your patience,

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


[webkit-dev] Commit Queue down for maintainence

2021-07-28 Thread Aakash Jain via webkit-dev
Hi Everyone,

We just took commit-queue bots offline for some maintenance. I will send 
another update when they are back online.

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


[webkit-dev] Request for Position: EyeDropper API

2021-07-22 Thread Ionel Popescu via webkit-dev
Hi webkit-dev,

This is a request for Webkit's position on EyeDropper API.

Explainer: 
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EyeDropper/explainer.md

TAG review: https://github.com/w3ctag/design-reviews/issues/587

Chrome Status entry: https://chromestatus.com/feature/6304275594477568

Please let us know if you have any feedback!

Thanks,
Ionel

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


Re: [webkit-dev] Request for Position: User Preference Media Features Client Hints Headers

2021-07-20 Thread Thomas Steiner via webkit-dev
Updated links post migration to the WICG:

* Specification or proposal URL:
https://wicg.github.io/user-preference-media-features-headers/
* Explainer URL:
https://github.com/WICG/user-preference-media-features-headers/blob/main/README.md
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for Position: User Preference Media Features Client Hints Headers

2021-07-20 Thread Thomas Steiner via webkit-dev
FYI, this has now shipped in Chrome (
https://groups.google.com/a/chromium.org/g/blink-dev/c/tEZ4RVsP1ms/m/TJpJhstGAgAJ)
with Google Search engineering working on adding the header to the site.
I'd still appreciate WebKit's view on this.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position: CSS tree-scoped at-rule names and refs (for @font-face etc.)

2021-07-19 Thread Xiaocheng Hu via webkit-dev
Hi webkit-dev,

This is a request for WebKit's position on CSS tree-scoped names and
references for @font-face, @keyframes, @counter-style and other
name-defining at-rules.

Spec:
  https://drafts.csswg.org/css-scoping/#shadow-names

Explainer:
  https://drafts.csswg.org/css-scoping/#example-f1503361
  https://drafts.csswg.org/css-scoping/#example-ee72cb37

Existing WebKit bug:
  I'm not aware of any WebKit bug for exactly the same issue. Please let me
know if I missed any. There are some related bugs as listed below:
  https://bugs.webkit.org/show_bug.cgi?id=72461
  https://bugs.webkit.org/show_bug.cgi?id=186837

Summary:

It has been a long standing issue on how name-defining at-rules should be
handled across shadow tree boundaries. The existing behaviors are
non-interoperable between browsers, and even inconsistent in the same
browser between different rules [1]. Following a recent CSSWG resolution
[2], a new and reasonable behavior has been proposed. Chrome is planning to
implement this new behavior, starting with the @counter-style rule [3].

[1] https://wiki.csswg.org/spec/css-scoping
[2] https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-848941922
[3] https://chromestatus.com/feature/5716198446596096
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position: Web App Note Taking - New Note URL

2021-07-19 Thread Glen Robertson via webkit-dev
Hi,

I am requesting a standards position signal on Web App Note Taking - New
Note URL
This proposed spec allows web app authors to declare a
`note_taking: { new_note_url:  }`
member in their web app manifest. User agents can use the member to enable
OS integrations.

Explainer:
https://github.com/WICG/manifest-incubations/blob/gh-pages/note_taking-explainer.md
Spec:
https://wicg.github.io/manifest-incubations/index.html#note_taking-member
Chromestatus: https://chromestatus.com/feature/5205972320518144

Let me know if you have any questions.

Thanks
-Glen Robertson (Chrome OS web apps platform team)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Ryan Haddad is now a WebKit Reviewer

2021-07-15 Thread Aakash Jain via webkit-dev
Hello All,

I would like to announce that Ryan Haddad is now a WebKit Reviewer. His 
expertise is tools and infrastructure. Please join me in congratulation him.

 Congratulations Ryan! 

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


Re: [webkit-dev] Request for position: CSS scrollbar-gutter

2021-07-15 Thread Felipe Erias via webkit-dev

Hi webkit-dev,

This is a request for an updated position on scrollbar-gutter.

The initial version of this spec raised concerns among WebKit and Gecko, 
mainly regarding its interaction with overlay scrollbars.


These issues were eventually solved in a CSS WG meeting where it was 
agreed to reduce the scope of this property to the functionality that 
could gather unanimous support among the browser representatives.


The updated spec can be summarized as follows:

* the syntax of scrollbar-gutter becomes

 auto | stable && both-edges?

  where
  — "auto" keeps the default behaviour;
  — "stable" reserves space for a classic scrollbar along the inline 
edge when the overflow value of the box is auto, scroll, or hidden;

  — "both-edges" reserves a symmetrical space on the opposite edge.

* with overlay scrollbars, scrollbar-gutter does not have any effect.


Thank you so much.

Best,
Felipe


References:

https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
https://github.com/w3c/csswg-drafts/issues/4674#issuecomment-857841639
https://github.com/w3c/csswg-drafts/issues/6349#issuecomment-880053625


On 23/02/2021 22:54, Felipe Erias via webkit-dev wrote:

Hi webkit-dev,

This is a request for WebKit's position on the CSS "scrollbar-gutter" 
property. The spec status is Working Draft. This feature is already 
implemented in Chrome behind a flag.


Spec:
   https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property

Explainer:
   https://github.com/felipeerias/scrollbar-gutter-explainer

Existing WebKit bug:
   https://bugs.webkit.org/show_bug.cgi?id=167335

Summary:

The scrollbar-gutter property provides control over the presence of 
scrollbar gutters (the space which may be reserved to display a scrollbar).


This gives Web authors more agency over how their layouts interact with 
the scrollbars provided by the browser, so they can e.g. prevent 
excessive layout changes as content expands while avoiding unwanted 
visuals when scrolling isn't needed.


Thanks!

Best.
Felipe
_______________
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] Request for Position on supporting more flex-basis keywords

2021-07-14 Thread David Grogan via webkit-dev
Hi WebKit devs,

I'm going to make the 'flex-basis' property (and its part of the 'flex'
shorthand) in Blink honor the css-sizing-3 keywords 'min-content,'
'max-content', and 'fit-content', and the css-flexbox-1 keyword 'content'.

Neither Blink nor WebKit currently support those keywords in flexbox.

This is a request for Webkit's position on implementing those keywords in
flexbox.

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


Re: [webkit-dev] Request for position: EME MediaKeySession Closed Reason

2021-07-09 Thread 王消寒
Kindly ping again. Thanks!

On Fri, Jun 25, 2021 at 9:49 AM Xiaohan Wang (王消寒) 
wrote:

> Kindly ping! I'd like to enable related features in Chromium for
> experimentation, and a clear signal here would be really helpful. Thanks!
>
> On Tue, Jun 15, 2021 at 2:35 PM Xiaohan Wang (王消寒) 
> wrote:
>
>> +Jer
>>
>> Kindly ping! Thanks!
>>
>>
>>
>> On Tue, Jun 8, 2021 at 11:36 AM Xiaohan Wang (王消寒) 
>> wrote:
>>
>>> This is a request for WebKit's position on the "EME MediaKeySession
>>> Closed Reason" proposal:
>>>
>>> *Links*
>>>
>>>- W3C EME spec issue/explainer:
>>>https://github.com/w3c/encrypted-media/issues/473
>>>- W3C EME spec Pull Request:
>>>https://github.com/w3c/encrypted-media/pull/487
>>>- Previous Media Working Group meeting discussion on this topic
>>>(with Jer Noble):
>>>https://lists.w3.org/Archives/Public/public-media-wg/2020Sep/0004.html
>>>
>>> Summary
>>>
>>> A MediaKeySessionClosedReason is proposed to indicate the reason for EME
>>> MediaKeySession closure, and the `closed` attribute would return a
>>> `Promise` instead of the current
>>> `Promise`.
>>>
>>> Motivation
>>>
>>> The current EME spec says "the CDM may close a session at any point,
>>> such as when the session is no longer needed or when system resources are
>>> lost". However, there's no way to specify the exact reason for session
>>> closure. In some cases, this is part of normal user flow, e.g. user close
>>> laptop lid to put the device into sleep mode, where the player should
>>> resume playback. In some other cases, this is due to some unrecoverable
>>> fatal error.
>>>
>>> This proposal updates the `closed` attribute on MediaKeySession to
>>> provide a MediaKeySessionClosedReason so that the JavaScript player can
>>> handle session closure differently based on the reasons.
>>>
>>> *Contact email*
>>> xhwang at chromium.org
>>>
>>> Looking forward to your feedback!
>>>
>>> Best,
>>> Xiaohan
>>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position - Installed Web applications as URL Handlers

2021-07-09 Thread Diego Gonzalez via webkit-dev
Hello webkit-dev,

We would like to request for WebKit's position on a proposal to installed Web 
applications to register for URL handling through the Web Application 
Manifest<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fappmanifest%2F=04%7C01%7Cluigonza%40microsoft.com%7C0a7789fb25124dc7046108d941997961%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637612949711253057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=fmdhNgSrHS0JE7ed%2FLNJmBxIwlL4r4U0Q2nOkUPago8%3D=0>.

Links
- Explainer: 
https://github.com/WICG/pwa-url-handler/blob/main/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fpwa-url-handler%2Fblob%2Fmain%2Fexplainer.md=04%7C01%7Cluigonza%40microsoft.com%7C0a7789fb25124dc7046108d941997961%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637612949711253057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=mSvzjIQPGPJpnsidfBVAFGXFKZva9xC8HcJ%2BJ5DRSRw%3D=0>
- Article with descriptions of the developer and user experiences: 
https://web.dev/pwa-url-handler/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.dev%2Fpwa-url-handler%2F=04%7C01%7Cluigonza%40microsoft.com%7C0a7789fb25124dc7046108d941997961%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637612949711263013%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=EYNPt9AWWSUcoVjNIyTIo7KMV%2BDBe9rem0gWyBto4Gc%3D=0>
- Chrome Status page with links to more documentation: Progressive Web Apps 
as URL Handlers - Chrome Platform Status 
(chromestatus.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2Ffeature%2F5739732661174272=04%7C01%7Cluigonza%40microsoft.com%7C0a7789fb25124dc7046108d941997961%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637612949711263013%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=kc%2FCElUl9fDld3YicjjBKhyrgRlDhVyB14DkYCSN26o%3D=0>
- Sample app: Hello! 
(luhuangmsft.github.io)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fluhuangmsft.github.io%2Fpwa%2F=04%7C01%7Cluigonza%40microsoft.com%7C0a7789fb25124dc7046108d941997961%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637612949711272971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=1hmudmMBRSzzwl%2FJSrR2gqw%2FAaT%2BapvE82BCoMYmCHA%3D=0>

Summary
Developers can create a more engaging experience if installed Web apps are able 
to register as handlers for https URLs. We proposed a scheme for an installed 
Web apps to register for URL handling behavior through the web application 
manifest, such that it may launched when matching URL links are activated. 
Native applications today on many operating systems (Windows, Android, iOS, 
MacOS) are able to register for URL handling.

This work targets the Web Application Manifest specification 
(https://www.w3.org/TR/appmanifest/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fappmanifest%2F=04%7C01%7Cluigonza%40microsoft.com%7C0a7789fb25124dc7046108d941997961%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637612949711272971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=DZgVX1YB4CQ2G%2BUlN%2Flr4ATGfSyOdBYOIwHNX69Co6w%3D=0>).
 Changes will include recognizing a "url_handlers" field in the manifest to 
register for URL handling, as well as adding a "Web App Origin Association" 
supplement to the spec. that specifies how registered origins are validated.

Status
Web app URL handling is being implemented in the Chromium browser as an 
experimental feature.

Contacts
Mandy Chen mandy.c...@microsoft.com<mailto:mandy.c...@microsoft.com>, Lu Huang 
lu.hu...@microsoft.com<mailto:lu.hu...@microsoft.com>, Diego Gonzalez 
luigo...@microsoft.com<mailto:luigo...@microsoft.com>, Marijn Kruisselbrink 
m...@chromium.org<mailto:m...@chromium.org>


Thank you for your kind attention. We look forward to your response.


Regards,

Lu Huang & Diego González


Diego González-Zúñiga
PM, Microsoft Edge

[cid:image001.png@01D774B2.3845D3E0]

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


[webkit-dev] Request for position: Clipboard API SVG support

2021-07-02 Thread Darwin Huang via webkit-dev
Looking for a position on adding svg support for the async clipboard API
(ex. `navigator.clipboard.write`), in a similar manner to the HTML support
<https://webkit.org/blog/10855/async-clipboard-api/> already added. Thank
you!

* Base Specification Title: Clipboard API and events
<https://www.w3.org/TR/clipboard-apis/>
* Specification or proposal URL: Explainer here
<https://docs.google.com/document/d/1Rx7gi01avpRRNYKSpp3U4WQdjery0H0IkX2XxDtfZ8I/edit>
Other information:
* https://www.chromestatus.com/feature/5125790490427392 has more links
* https://github.com/w3c/editing/issues/305 may also be relevant

-- 
- Darwin Huang
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: CSS spelling and grammar features

2021-07-01 Thread Delan Azabani via webkit-dev
On 2021-01-06 10:45, dazabani wrote:
> I’m seeking WebKit’s position on the following features in css-pseudo
> and css-text-decor:

Just following up on this. Any thoughts?

See also my request for position regarding CSS highlight inheritance:
https://lists.webkit.org/pipermail/webkit-dev/2021-January/031660.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position: CSS highlight inheritance (css-pseudo #highlight-cascade)

2021-07-01 Thread Delan Azabani via webkit-dev
I’m seeking WebKit’s position on the “Cascading and Per-Element
Highlight Styles” section of css-pseudo-4 [0].

Most impls (with the sole exception of Presto) have historically not
propagated highlight styles through the element tree. This has meant
that only the global ::selection selector (*::selection) worked
intuitively, and made it awkward to style the highlights on some
subset of elements.

Authors had to repeat each selector with a “*” descendant, and ensure
that “overriding” rules win the cascade. For example, to highlight
content under p.foo in yellow, but content under  anywhere in the
document in cyan, one might:

p.foo::selection,
p.foo *::selection {
background-color: yellow;
}
em:not(#specificity)::selection,
em:not(#specificity) *::selection {
background-color: cyan;
}

The spec gives highlights an inheritance-based processing model, where
all properties (inherited or otherwise) default to the value on the
parent’s highlight. Note that the spec’s processing model is no longer
cascade-based, as of w3c/csswg-drafts#2474 [1].

We believe the compat risk is minimal, because the new model won’t
break existing content with global ::selection rules, nor will it
break rules that use the cascade to build an ersatz “propagation” like
the example above. As far as we can tell, only content that relies on
descendants of a highlight-styled element being reset to initial
styles should be affected.

[0] https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
[1] https://github.com/w3c/csswg-drafts/issues/2474

Cheers,
Delan Azabani
Igalia // web platform
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for Position: MSE-in-Workers

2021-06-30 Thread Matt Wolenetz via webkit-dev
Hi webkit-dev,

This is a request for Webkit's position on the MSE-in-Workers feature:

Explainer:
https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md

Main MSE spec issue tracking this feature:
https://github.com/w3c/media-source/issues/175

ChromeStatus entry:
https://chromestatus.com/features/5177263249162240

Draft specification:
https://github.com/w3c/media-source/pull/282

TAG review:
https://github.com/w3ctag/design-reviews/issues/656

Demo page (Chromium has experimental implementation):
https://wolenetz.github.io/mse-in-workers-demo/mse-in-workers-demo.html

Please let us know if you have any feedback!

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


Re: [webkit-dev] Request for position: EME MediaKeySession Closed Reason

2021-06-25 Thread 王消寒
Kindly ping! I'd like to enable related features in Chromium for
experimentation, and a clear signal here would be really helpful. Thanks!

On Tue, Jun 15, 2021 at 2:35 PM Xiaohan Wang (王消寒) 
wrote:

> +Jer
>
> Kindly ping! Thanks!
>
>
>
> On Tue, Jun 8, 2021 at 11:36 AM Xiaohan Wang (王消寒) 
> wrote:
>
>> This is a request for WebKit's position on the "EME MediaKeySession
>> Closed Reason" proposal:
>>
>> *Links*
>>
>>- W3C EME spec issue/explainer:
>>https://github.com/w3c/encrypted-media/issues/473
>>- W3C EME spec Pull Request:
>>https://github.com/w3c/encrypted-media/pull/487
>>- Previous Media Working Group meeting discussion on this topic
>>(with Jer Noble):
>>https://lists.w3.org/Archives/Public/public-media-wg/2020Sep/0004.html
>>
>> Summary
>>
>> A MediaKeySessionClosedReason is proposed to indicate the reason for EME
>> MediaKeySession closure, and the `closed` attribute would return a
>> `Promise` instead of the current
>> `Promise`.
>>
>> Motivation
>>
>> The current EME spec says "the CDM may close a session at any point, such
>> as when the session is no longer needed or when system resources are lost".
>> However, there's no way to specify the exact reason for session closure. In
>> some cases, this is part of normal user flow, e.g. user close laptop lid to
>> put the device into sleep mode, where the player should resume playback. In
>> some other cases, this is due to some unrecoverable fatal error.
>>
>> This proposal updates the `closed` attribute on MediaKeySession to
>> provide a MediaKeySessionClosedReason so that the JavaScript player can
>> handle session closure differently based on the reasons.
>>
>> *Contact email*
>> xhwang at chromium.org
>>
>> Looking forward to your feedback!
>>
>> Best,
>> Xiaohan
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] content-visibility (Was Re: Request For Position on CSS containment)

2021-06-24 Thread Ryosuke Niwa via webkit-dev
Please rename the subject when you're going to discuss the work on a new
feature.

On Thu, Jun 24, 2021 at 9:44 AM cathiechen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> We made a lot of progress regarding CSS containment [1].
> Rob and I have finished the layout containment and size containment [2].\o/
> And the patches of paint containment and style containment are ready for
> review now [3].
>
> So we think now it's time to move on to content-visibility:
> (https://www.w3.org/TR/css-contain-2/#content-visibility)
>

That seems premature. Have we implemented all the perf optimizations for
layout, size, & paint containment? I'd rather not start piling on more
features before we get to a point where we're happy with the performance of
these features.

Since content-visibility depends on paint and style containment, we will do
> some specification research first, then prototype it based on Rob's patches.
>

Does the research part also include making a judgement call as to whether
it's a good idea at all? It's wholly unclear to me that content-visibility
is a feature we'd like to implement in WebKit given its implications to the
accessibility and other browser features.

- R. Niwa
_______________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request For Position on CSS containment

2021-06-24 Thread cathiechen via webkit-dev
Hi webkit-dev,

We made a lot of progress regarding CSS containment [1].
Rob and I have finished the layout containment and size containment [2].\o/
And the patches of paint containment and style containment are ready for review 
now [3].

So we think now it's time to move on to content-visibility:
(https://www.w3.org/TR/css-contain-2/#content-visibility)
Since content-visibility depends on paint and style containment, we will do 
some specification research first, then prototype it based on Rob's patches. 
Thank you for your feedback!

[1] https://bugs.webkit.org/show_bug.cgi?id=172026
[2] https://bugs.webkit.org/show_bug.cgi?id=223569, 
https://bugs.webkit.org/show_bug.cgi?id=223570
[3] https://bugs.webkit.org/show_bug.cgi?id=224742, 
https://bugs.webkit.org/show_bug.cgi?id=226458

Best,
Rob and Cathie

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


[webkit-dev] Request for position on scheduler.postTask

2021-06-23 Thread Scott Haseley via webkit-dev
Hello WebKit-dev,

I’d like to request WebKit’s official position on scheduler.postTask(), an
API for scheduling and controlling prioritized tasks. It is specified in
[1] and further described in [2]. We’ve presented the API a few times to
the WebPerf WG. One concern raised there by rniwa was the risk of priority
inversions, which we’ve explored in [3].

We recently finished running an Origin Trial in Chrome. Airbnb, who we’ve
been working closely with, experimented with using the API to improve their
site’s performance, which they wrote about recently [4].

[1] Spec: https://wicg.github.io/scheduling-apis/
[2] Explainer:
https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-post-task.md
[3] Priority inversion exploration:
https://github.com/WICG/scheduling-apis/blob/main/misc/priority-inversion.md
[4] Airbnb blog post:
https://medium.com/airbnb-engineering/building-a-faster-web-experience-with-the-posttask-scheduler-276b83454e91

Additional Links:
 - Preliminary TAG review:
https://github.com/w3ctag/design-reviews/issues/338
 - TAG Spec review (under review):
https://github.com/w3ctag/design-reviews/issues/647
 - Chrome Status entry:
https://www.chromestatus.com/feature/6031161734201344

Thank you,
Scott
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position on Cascade Layers

2021-06-22 Thread Rune Lillesveen via webkit-dev
On Thu, Jan 14, 2021 at 9:17 PM Rune Lillesveen 
wrote:

> Hello webkit-dev,
>
> I'm asking for WebKit's position on Cascade Layers drafted in CSS Cascade
> Level 5. We plan to start prototyping behind a flag in Chromium in Q1.
>

It got delayed, but we are trying again in Q3.

Explainer:
> https://github.com/oddbird/css-sandbox/blob/main/src/layers/explainer.md
> Specification URL: https://drafts.csswg.org/css-cascade-5/#layering
> Request for TAG review:
> https://github.com/w3ctag/design-reviews/issues/597
>

-- 
Rune Lillesveen
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] FYI: Chrome will block ports 989 and 990

2021-06-18 Thread Adam Rice via webkit-dev
Just letting you know that Chrome is going to block ports 989 (ftps-data)
and port 990 (ftps) in version 93. This is to prevent cross-protocol
attacks. See https://github.com/whatwg/fetch/pull/1250 for background. I
think it would be good for users if WebKit also blocked these ports. There
is an issue at https://bugs.webkit.org/show_bug.cgi?id=226971.

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


[webkit-dev] Embedded EWS upgrades

2021-06-17 Thread Matt Lewis via webkit-dev
Hello webkit developers,
We are currently going through the process of updating the OS and SDKs of the 
embedded ews builders and testers. We are temporarily going to take iOS ews 
down while we perform this as fast as possible. As hosts are updated we will be 
returning them to active status and processing patches.

Thanks for your patience,
Matt Lewis
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: EME MediaKeySession Closed Reason

2021-06-15 Thread 王消寒
+Jer

Kindly ping! Thanks!



On Tue, Jun 8, 2021 at 11:36 AM Xiaohan Wang (王消寒) 
wrote:

> This is a request for WebKit's position on the "EME MediaKeySession Closed
> Reason" proposal:
>
> *Links*
>
>- W3C EME spec issue/explainer:
>https://github.com/w3c/encrypted-media/issues/473
>- W3C EME spec Pull Request:
>https://github.com/w3c/encrypted-media/pull/487
>- Previous Media Working Group meeting discussion on this topic
>(with Jer Noble):
>https://lists.w3.org/Archives/Public/public-media-wg/2020Sep/0004.html
>
> Summary
>
> A MediaKeySessionClosedReason is proposed to indicate the reason for EME
> MediaKeySession closure, and the `closed` attribute would return a
> `Promise` instead of the current
> `Promise`.
>
> Motivation
>
> The current EME spec says "the CDM may close a session at any point, such
> as when the session is no longer needed or when system resources are lost".
> However, there's no way to specify the exact reason for session closure. In
> some cases, this is part of normal user flow, e.g. user close laptop lid to
> put the device into sleep mode, where the player should resume playback. In
> some other cases, this is due to some unrecoverable fatal error.
>
> This proposal updates the `closed` attribute on MediaKeySession to provide
> a MediaKeySessionClosedReason so that the JavaScript player can handle
> session closure differently based on the reasons.
>
> *Contact email*
> xhwang at chromium.org
>
> Looking forward to your feedback!
>
> Best,
> Xiaohan
>
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Removing the ENABLE(CSS_SCROLL_SNAP) flag

2021-06-15 Thread Simon Fraser via webkit-dev
Sounds fine.

Simon

> On Jun 15, 2021, at 5:04 AM, Martin Robinson via webkit-dev 
>  wrote:
> 
> Recently, css-scroll-snap was enabled on all ports. The implementation
> has also been extended to be mostly platform-independent. Since all
> ports are compiling this code and it's a fairly basic CSS feature should
> we go ahead and remove the ENABLE(CSS_SCROLL_SNAP) build flag? I think
> this would greatly simplify the scrolling code.
> 
> Thanks!
> 
> --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


  1   2   3   4   5   6   7   8   9   10   >