Re: [webkit-dev] Raw string literals

> On Nov 17, 2021, at 2:58 PM, Alex Christensen via webkit-dev > wrote: > > Right now, our style checker disapproves of raw string literals, which were > introduced in C++11. It complains with this message: > > Multi-line string ("...") found. This lint script doesn't do well with such >

Re: [webkit-dev] Request for position: New Canvas 2D API

> On May 3, 2021, at 9:58 AM, Simon Fraser via webkit-dev > wrote: > > >> On May 1, 2021, at 10:07 AM, Aaron Krajeski via webkit-dev >> mailto:webkit-dev@lists.webkit.org>> wrote: >> >> Hi webkit-dev, >> >> This is a request for WebKit's position on New Canvas 2D API >>

Re: [webkit-dev] Request for Position on Storage Foundation API

We are not opposed to the concept of efficient access to files, but we are strongly opposed to minting a brand new Web API for file access instead of enhancing one of the existing ones. This issue outlines the problem: https://github.com/fivedots/storage-foundation-api-explainer/issues/4

Re: [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks

This sounds obnoxious and potentially anti-competitive. But I think it’s restricted to OAuth flows, which would indeed only affect other sites that allow the user to sign in with their Google account. So that would be the thing to test. > On Nov 17, 2020, at 12:20 PM, Michael Catanzaro via

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

> On Oct 17, 2020, at 10:00 AM, Sam Weinig wrote: > > Hi webkit-dev, > > I’d like to propose, and gauge feedback on, reducing (with the goal of > ultimately removing) the use of Makefile based DerivedSources.make. > > My understanding is that currently only the Xcode based ports still use

Re: [webkit-dev] User Agent Client Hints

> On Nov 2, 2020, at 8:56 AM, Yoav Weiss wrote: > > Thanks for re-reviewing, Maciej! > > Adding Mike Taylor, who's likely to take a closer look at this. > > On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > I

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

> On Oct 30, 2020, at 1:40 PM, David Bokan wrote: > > Hi Ryosuke, > > Would just like to clarify one point. > > On Fri, Sep 25, 2020 at 12:42 PM David Bokan > wrote: > [Sorry, meant to reply-all] > > On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa

Re: [webkit-dev] User Agent Client Hints

I just did a fresh review of that spec and explainer. Thanks for addressing many of the previous issues. This addresses many of the potential objections. Here’s the new issues I filed: https://github.com/WICG/ua-client-hints/issues/141

Re: [webkit-dev] WebKit Transition to Git

> On Oct 13, 2020, at 2:37 PM, Konstantin Tokarev wrote: > > > > 13.10.2020, 22:33, "Maciej Stachowiak" : >>> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro >>> wrote: >>> >>> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand

Re: [webkit-dev] WebKit Transition to Git

> On Oct 3, 2020, at 9:42 AM, Tetsuharu OHZEKI > wrote: > >>> I think having to create an account on a website isn't the main thing >>> preventing people to contribute anyway? It's more about having to use >>> project-specific tools to prepare the patch for submission (in the case >>> of

Re: [webkit-dev] WebKit Transition to Git

> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro wrote: > > On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand wrote: >> Would you also consider preventing merge commits in order to keep a >> clean mainline branch? > > Big +1 to blocking merge commits. Merge commits in a huge project like

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

Can you clarify what question you’re looking to have answered? Are you asking for a new standards position in light of the replies below? - Maciej > On Sep 18, 2020, at 7:35 AM, David Bokan wrote: > > Friendly ping to get an answer here. > > Do my answers above address those points or is

Re: [webkit-dev] Suggesting to enable paint timing by default

now who the best person to vet the maturity > of the code is though, sorry. > > Thanks a lot Keith, I appreciate it! > @Maciej Stachowiak <mailto:m...@apple.com>, what would be a good way to > assert whether the code maturity is good enough to enable paint timing by

Re: [webkit-dev] Plugin process

> On Jul 20, 2020, at 10:23 AM, Darin Adler wrote: > >> On Jul 20, 2020, at 7:35 AM, Michael Catanzaro wrote: >> >> Then we can make the plugin process specific to PLATFORM(COCOA) > > Side note: It will be specific to PLATFORM(MAC). And we’ll probably attempt to remove it from

Re: [webkit-dev] Request for position on Media Feeds

Without having read the spec in detail, the first thing I wonder is why not use RSS for this purpose? That seems to be the de facto standard for audio feeds (i.e. podcasts). This is dismissed in a cursory way in the explainer. There’s some more detailed discussion in the issue filed by the

Re: [webkit-dev] Request for position on First-Party Sets

an initial draft of a > policy, and will bring that for discussion when ready. That sounds like a positive development, looking forward to it. > > Kaustubha > > > > > > On Wed, May 27, 2020 at 3:16 PM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > >

Re: [webkit-dev] Request for position on First-Party Sets

(1) I notice that this proposal still exists only in a random personal repo. Could it please be contributed to an appropriate standards or incubation group? Privacy CG would almost certainly welcome this, and I’m sure it would be easy to move to WICG as well. There doesn’t seem to be a reason

Re: [webkit-dev] Suggesting to enable paint timing by default

> On May 11, 2020, at 9:53 PM, Noam Rosenthal wrote: > > > > On Tue, May 12, 2020 at 1:36 AM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > I noticed from comments in one of the Radars that the patch may result in an > additional “fake paint”, so

Re: [webkit-dev] Suggesting to enable paint timing by default

I noticed from comments in one of the Radars that the patch may result in an additional “fake paint”, so it should probably be performance tested. Have you done any testing? We’ll likely want to A/B some of Apple’s page load speed benchmarks. I’d like to hear from others on maturity of the

Re: [webkit-dev] Platform.h vs. makefiles

al in having a separate data file, however I'm not sure > if it can inform IDE parsing and syntax highlighting for code > enabled/disabled at compile time. Header files seem like they would get that > right more often. > > - Alexey > > >> 10 мая 2020 г., в 10:07 PM, Mac

Re: [webkit-dev] Platform.h vs. makefiles

> On May 10, 2020, at 11:11 PM, Darin Adler wrote: > >> On May 10, 2020, at 10:07 PM, Maciej Stachowiak wrote: >> >> I think the best way to configure WebKit is to use a separate data file, >> neither a header nor a makefile or similar, that defines the

Re: [webkit-dev] Platform.h vs. makefiles

I think the best way to configure WebKit is to use a separate data file, neither a header nor a makefile or similar, that defines the options in a single place with clear syntax. Then everything else is generated from that. Such a system could cover runtime flags as well, which are even more

Re: [webkit-dev] Position on User-Agent Client Hints

Accidentally removed Yoav from Cc and I’m not sure if he is on this list. > On May 8, 2020, at 12:04 AM, Maciej Stachowiak wrote: > > > I would consider myself mildly positive as to the direction, but that’s my > personal view for the moment, absent consultation with m

Re: [webkit-dev] Position on User-Agent Client Hints

I would consider myself mildly positive as to the direction, but that’s my personal view for the moment, absent consultation with my colleagues. I will solicit more viewpoints. I particularly appreciate the responsiveness to feedback and that Yoav in particular has been willing to iterate. I

Re: [webkit-dev] Support "registerProtocolHandler" in WebKit2

Looking at my old email, I think it’s worth supporting for Mail clients for example, but I think it would require some OS-level engineering as well to have it work on macOS. (Other Apple platforms currently don’t support customizing the default mail client). And I do still think that allow

Re: [webkit-dev] Support for scrolling=off and scrolling=noscroll

Seems like a reasonable change. > On Mar 17, 2020, at 7:19 AM, Frédéric Wang wrote: > > The spec > says that iframe and frame elements have a "scrolling" attribute that can be > set to "no", "off", or "noscroll" to disable

Re: [webkit-dev] Same-Site cookies by default

> On Mar 6, 2020, at 6:58 PM, Patrick Griffis wrote: > > On 2020-03-06 6:51 pm, John Wilander wrote: >> Hi Patrick! >> >> Thanks for bringing this up. I’ll share my view of where we are. >> >> First of all, cookies mostly live in the http layer so the various >> WebKit ports would have to

Re: [webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

I agree this usage of “roll out” is potentially confusing. I think people say “roll out” for the symmetry to “check in”. It also creates the convenient term “roll back in” for when a rollout is undone. Personally, I think we should say “revert” and avoid use of roll-phrases entirely.

Re: [webkit-dev] Same-Site cookies by default

Current WebKit trunk blocks all third party cookies (with ITP enabled), which is a more extreme version of the same thing. We’re currently testing the compatibility fallout. Treating cookies as SameSite=Lax by default is moot when third-party cookies are blocked, as the SameSite=None behavior

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

> On Mar 2, 2020, at 11:22 PM, Noam Rosenthal wrote: > > > > On Mon, Nov 11, 2019 at 10:13 PM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > >> On Nov 11, 2019, at 4:37 AM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote: >&g

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

> On Mar 3, 2020, at 12:44 AM, Noam Rosenthal wrote: > > > > On Tue, Mar 3, 2020 at 10:36 AM Ryosuke Niwa > wrote: > > By the way, do you know what the status / interests at Mozilla? Given > WebKit's painting / navigation behavior / implementation is still pretty

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

> On Mar 1, 2020, at 4:19 PM, Noam Rosenthal wrote: > > > > On Mon, Mar 2, 2020 at 1:18 AM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > >> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote: >&

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal wrote: > > > > On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > >> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote: >>

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

New version, with Oxford comma everywhere. I didn’t add the use of “itself” because I don’t think the sentence is ambiguous as written, given the second clause. And if it is ambiguous, “itself” would not remove the ambiguity. Below the diff, there’s the full text of the page as it would appear

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal wrote: > > > The first visually non-empty milestone almost always happens way before this > point. The above is just a fallback to make sure we eventually hit this > milestone. For example, if a document is totally blank even after loading the >

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

> On Feb 27, 2020, at 3:41 AM, Noam Rosenthal wrote: > > > > On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal > wrote: > > > On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss > wrote: > > > On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa

Re: [webkit-dev] Proposal for an "intent to" process for web-exposed features

I think we should have some structure, not just freeform emails. We can start with a simple template, but there’s some info that folks almost always want, so it’s easier if it’s included in the first place, rather than needing predictable follow-up questions I also like having a title

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa wrote: > > > On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > >> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal > <mailto:noam.j.rosent...@gmail.com>> wrote: &

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal > wrote: > > > > On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > Some quick comments: > > the definition of First Contentful Paint here in the spec: >

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

Some quick comments: I am concerned that the definitions of these paint milestones have engine-dependent assumptions, and some may not be spelled out in the spec. For example, the definition of First Contentful Paint here in the spec: does

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

V2, with stronger privacy language. project-new.html WebKit is an open source Web content engine for browsers and other applications. 1212 1313 14 We value real-world web compatibility, standards compliance, stability, performance, security, portability, usability, and relative ease of

Re: [webkit-dev] Request for position on Badging API

> On Feb 19, 2020, at 4:35 PM, Maciej Stachowiak wrote: > > > >> On Feb 19, 2020, at 4:31 PM, Matt Giuca > <mailto:mgi...@chromium.org>> wrote: >> >> >> >> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa > <mailto:rn...@webkit.or

Re: [webkit-dev] Request for position on Badging API

> On Feb 19, 2020, at 4:31 PM, Matt Giuca wrote: > > > > On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa > wrote: > > On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca > wrote: > On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa

Re: [webkit-dev] Note regarding wording of MacOS X on webkit.org

The correct current spelling is macOS, please report any other places you know if that have an older or incorrect spelling. > On Feb 18, 2020, at 9:50 AM, Oliver Propst wrote: > >  > While this is not a major issue I have noticed that webkit.org makes several > references to "Mac OSX" while

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

> On Feb 16, 2020, at 8:43 PM, Brent Fulgham wrote: > > > >> On Feb 16, 2020, at 12:39 PM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote: >> >> >> There hasn’t been any feedback on this, so below is a proposed change (in >> P

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

There hasn’t been any feedback on this, so below is a proposed change (in PrettyPatch HTML format) to . In addition to adding Privacy as a goal, I also added Battery Life, and tweaked a few of the existing goals. Thoughts? project-new.html WebKit is an

Re: [webkit-dev] Step 1 of Plugin removal: Deleting NPAPI (and thus Flash support)

I discussed this some with Apple folks internally. Besides the PDF plugin mentioned by Dean, macOS apps using the WebKit API have the ability to embed NPAPI plugins in their app bundle and register them for WebView use. We are not sure if this is currently in use by any important apps, but we

[webkit-dev] Proposal: add Privacy to WebKit Project Goals

I came across an old post that links this WebKit Project Goes page: https://webkit.org/project/ (it’s also linked from the webkit.org front page, though perhaps not many notice). These goals, originally written in 2007, hold up surprisingly well in 2020. The most

Re: [webkit-dev] WebKit position on Web NFC

We oppose this feature and will not implement it. We do not believe a permission prompt is a sufficient mitigation for the serious security and privacy risks raised by this specification. In addition, we think exposing direct hardware access to the web is a bad idea and compromises the

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

> On Dec 11, 2019, at 12:48 PM, Nick Burris wrote: > > Hi Maciej, > Thanks for the reply! David's away this week, my responses are inline: > (1) We’re concerned about compatibility issues in a world where some browsers > support this but not all. Aware browsers will strip `:~:`, but unaware

Re: [webkit-dev] WebKit position on Wake Lock API

Is there a Blink Intent thread currently running on this or about to start? And do you happen to know if there is a Mozilla standards-positions issue on this? (We like to take into consideration whet the other browser engines are thinking.) > On Dec 10, 2019, at 11:46 PM, Thomas Steiner

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

Hi David, Apple folks have discussed this internally. In general, we think this is useful functionality to expose. Some points of feedback (let me know if any of these should be filed as an issue against the spec): (1) We’re concerned about compatibility issues in a world where some browsers

Re: [webkit-dev] Safari Tech Preview 96 available on wpt.fyi!

There’s a number of mysterious timeouts with 96. Not sure if flakiness or real? The new WebCrypto failures are surprising, but likely real and should be investigated: https://wpt.fyi/results/WebCryptoAPI/wrapKey_unwrapKey?diff=ADC=is%3Adifferent_id=347530011_id=381930013

Re: [webkit-dev] Removing WebSQL support

I tend to agree. Do any other ports want it? (Besides the small compatibility stub to avoid breaking metered paywalls.) > On Nov 22, 2019, at 12:35 AM, Ryosuke Niwa wrote: > > Hi all, > > It looks like we've successfully shipped iOS 13 and Safari 13 with WebSQL > disabled. I think it's

Re: [webkit-dev] WebKit team feedback on proposal to limit registerProtocolHandler API to secure contexts?

Hi Eric, Thanks for asking for our input. I’ve discussed this with experts on this area at Apple. WebKit does not currently support `registerProtocolHander` and likely will not. It’s a powerful capability, and hard to use sensibly in practice (except perhaps the `mailto:` scheme in

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

> On Nov 11, 2019, at 4:37 AM, Noam Rosenthal wrote: > > > > On Mon, Nov 11, 2019 at 12:13 AM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > - Is there a specification for Content-DPR? All I could find in bugzila and > elsewhere is links to <https://

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

> On Nov 10, 2019, at 2:13 PM, Maciej Stachowiak wrote: > > > >> On Nov 10, 2019, at 12:05 PM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote: >> >> >> >> On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak > <mailto:m...@app

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

> On Nov 10, 2019, at 12:05 PM, Noam Rosenthal wrote: > > > > On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > Is this header useful without the DPR client-hint? > Absolutely. > A server/CDN can decide to serve an

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

Is this header useful without the DPR client-hint? > On Nov 10, 2019, at 1:16 AM, Noam Rosenthal wrote: > > Hola > > I would like to open a discussion that has started a few years back and has > never reached a consensus: https://bugs.webkit.org/show_bug.cgi?id=145380 >

Re: [webkit-dev] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

acceptable to everyone). >> >> Thanks >> Aakash >> >>> On Nov 1, 2019, at 8:35 PM, Maciej Stachowiak wrote: >>> >>> >>> How about only a single comment when the first failure occurs? (Or else >>> when all bots pass

Re: [webkit-dev] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

How about only a single comment when the first failure occurs? (Or else when all bots pass, if there is never a failure.) This should help the author, the reviewer, and anyone else cc’d, without being too spammy. > On Nov 1, 2019, at 5:20 PM, Aakash Jain wrote: > > Hi Ryosuke, > > Many

Re: [webkit-dev] Lazy loading

> On Oct 28, 2019, at 3:08 PM, Rob Buis wrote: > > On 10/28/19 9:07 PM, Maciej Stachowiak wrote: > >>> Yet another possible task is making lazy loading work for CSS backgrounds, >>> this is implemented in the prototype but I don't think there are many tests

Re: [webkit-dev] Lazy loading

> On Oct 28, 2019, at 11:39 AM, Rob Buis wrote: > > Hi, > > I made a lazy image loading prototype earlier this year > (https://bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting it > up into reviewable patches. The main implementation part landed recently so I > am wondering

Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

> On Oct 11, 2019, at 9:38 AM, Konstantin Tokarev wrote: > > > > 10.10.2019, 23:10, "Ryosuke Niwa" : >> People often associate the term "WebKit" with Apple's WebKit port in >> practice. The risk here is really about people not understanding the nuance >> of port specific bugs & set of

Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

> On Oct 10, 2019, at 9:02 AM, Carlos Alberto Lopez Perez > wrote: > > On 09/10/2019 21:53, Maciej Stachowiak wrote: >> In terms of legalities: >> >> The WebKit logo (as well as the term WebKit) is trademarked by Apple, but >> there are acceptabl

Re: [webkit-dev] Implementing OffscreenCanvas

> On Oct 10, 2019, at 10:18 AM, John Wilander wrote: > >> On Oct 10, 2019, at 9:42 AM, Maciej Stachowiak wrote: >> >> For clarity, it’s already possible to render to a regular canvas offscreen. >> The can be hidden using any of the techniques that can make

Re: [webkit-dev] Implementing OffscreenCanvas

For clarity, it’s already possible to render to a regular canvas offscreen. The can be hidden using any of the techniques that can make any other canvas invisible. Name notwithstanding, OffscreenCanvas is mainly about being able to render from a Worker, not about enabling rendering offscreen.

Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

> On Oct 9, 2019, at 5:43 AM, Carlos Alberto Lopez Perez > wrote: > > On 03/10/2019 00:43, Ryosuke Niwa wrote: >> I don't know the rules regarding the logo use but it might be a bit >> misleading to use WebKit logo without any qualification for GTK+ port on >> wpt.fyi. >> >> I'd imagine

Re: [webkit-dev] Having trouble building

> On Oct 5, 2019, at 9:36 PM, Ken Russell wrote: > > On Sat, Oct 5, 2019 at 1:11 AM Tim Horton > wrote: > > > > On Oct 4, 2019, at 8:55 PM, Ken Russell > > wrote: > > > > Hi, > > > > Recently I upgraded to Xcode 11.0 and re-synced

Re: [webkit-dev] Moving to Python 3

> On Jul 13, 2019, at 7:26 PM, Maciej Stachowiak wrote: > > > >> On Jul 13, 2019, at 4:14 PM, Michael Catanzaro wrote: >> >> On Sat, Jul 13, 2019 at 6:02 PM, Maciej Stachowiak wrote: >>> This is exactly what virtualenvs can do. And this is how we

Re: [webkit-dev] Moving to Python 3

> On Jul 13, 2019, at 4:14 PM, Michael Catanzaro wrote: > > On Sat, Jul 13, 2019 at 6:02 PM, Maciej Stachowiak wrote: >> This is exactly what virtualenvs can do. And this is how we should do it >> IMO, even for systems that natively have some version of Python 3. >

Re: [webkit-dev] Moving to Python 3

> On Jul 13, 2019, at 3:44 PM, Ryosuke Niwa wrote: > >  > > >> On Fri, Jul 12, 2019 at 11:22 PM Jonathan Bedard wrote: >> I would agree that if we move to Python 3, we need a script which installs >> Python 3 in an impossible to mess-up way on Mojave and High Sierra. >> >> I don’t think

Re: [webkit-dev] Moving to Python 3

> On Jul 12, 2019, at 3:23 PM, Ryosuke Niwa wrote: > >  >> On Fri, Jul 12, 2019 at 1:04 PM Jonathan Bedard wrote: > >> >> > On Jul 12, 2019, at 12:49 PM, Michael Catanzaro >> > wrote: >> > >> > On Fri, Jul 12, 2019 at 2:18 PM, Jonathan Bedard wrote: >> >> The trouble I foresee us

Re: [webkit-dev] Remove SVGTests.hasExtension?

The one remaining thing we could potentially worry about is platform-specific content, like books or content embedded in apps. But given what SVGTests.hasExtension() is supposed to do, that seems very unlikely. Since SVG WG resolved to remove it, has it in fact been removed from the SVG spec?

Re: [webkit-dev] MathML Refresh Heads up

> On Mar 15, 2019, at 3:33 PM, Frédéric Wang wrote: > > Hi Ryosuke and Myles, > > Thank you for your reply. First, the exact thing about what will be in MathML > Core is still open, people are welcome to join and participate to the MathML > CG [1] or comment on the GitHub tracker [2]. > >

Re: [webkit-dev] Filtering results on wpt.fyi, Safari-specific failures

ental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D> > There’s definitely lots of failures that look legit. > > On Mon, Feb 25, 2019 at 8:31 PM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > Neat. > > I see some obvious areas for foc

Re: [webkit-dev] Filtering results on wpt.fyi, Safari-specific failures

Neat. I see some obvious areas for focus, where Safari fails lots of tests that the other browser don’t. For context, I tried looking at this view, which shows all tests that Safari and Firefox pass with Safari results regardless of result:

Re: [webkit-dev] Code Style: Opinion on returning void

It seems like `return foo();` where foo() is a void function can always be replaced with `foo(); return;` for greater clarity at the cost of one extra line break. For people who prefer the one-line style, can you say why you don’t like the other way? - Maciej > On Feb 20, 2019, at 10:33 AM,

Re: [webkit-dev] Moving to Git

> On Feb 20, 2019, at 12:14 PM, Michael Catanzaro wrote: > > FWIW, it's not hard to enforce fast-forward merges with a git hook; that way, > we can guarantee that the history has no merge commits and is fully linear. > GitLab has built-in support to enforce this for merge requests (though

Re: [webkit-dev] Experimental features review

> On Feb 14, 2019, at 9:01 AM, Michael Catanzaro wrote: > > On Wed, Feb 13, 2019 at 9:16 PM, Simon Fraser wrote: >> For these two, we now have them on by default because we think they are >> ready to ship. They still exist as experimental features so that people can >> turn them off for

Re: [webkit-dev] Exciting JS features (class fields) in need of review :)

you haven’t gotten more active review, and I am glad that Saam is now giving you another review pass. Cheers, Maciej > > Cheers, > Xan > > On Thu, Feb 14, 2019 at 8:47 AM Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > I left the boring review feed

Re: [webkit-dev] Exciting JS features (class fields) in need of review :)

I left the boring review feedback that this work should be behind a feature flag. Mentioning it here because this may apply to other feature patches you have in progress. (I am not qualified to review the substance of what the patch is doing.) > On Feb 13, 2019, at 1:51 PM, ca...@igalia.com

Re: [webkit-dev] Rename Bugzilla's "WebKit2" component to "WebKit Process Model"

> On Feb 6, 2019, at 9:48 AM, Lucas Forschler wrote: > > Thanks Ryosuke, > > I’d be in favor of adding a Bugzilla component “WebKit Process Model” > I believe Simon has also asked for a WKWebView component. (WKWebView > viewport/tiling/animated resize issues) > > Would the two of these

Re: [webkit-dev] Rename Bugzilla component "ANGLE" to "WebGL"

ANGLE is a separate chunk of code, and one the we periodically sync with an upstream repository, so I am not sure this is a good idea. > On Feb 1, 2019, at 10:59 AM, Lucas Forschler wrote: > > I just realized we already have a WebGL Bugzilla component. So I propose > deprecating the ANGLE

Re: [webkit-dev] Rename Bugzilla Component "Media Elements" to "Media"

Sounds good to me. > On Feb 1, 2019, at 10:52 AM, Lucas Forschler wrote: > > Hello all, > > I propose renaming the Bugzilla component “Media Elements” to “Media”. > > Are there any objections or concerns with this rename? > > Thanks, > Lucas > ___

Re: [webkit-dev] Compile error in WebGL2RenderingContext.cpp

> On Jan 17, 2019, at 10:15 AM, Michael Catanzaro wrote: > > > > On Thu, Jan 17, 2019 at 11:12 AM, Darin Adler wrote: >> Vector’s inline capacity feature was originally created as an alternative to >> variable length arrays for most of the purposes people would want to put >> them. > >

Re: [webkit-dev] the name "AtomicString"

> On Dec 20, 2018, at 11:24 AM, Geoffrey Garen wrote: > So hard to pronounce though! Why not UniqueString? It’s not quite as explicit but close enough. >>> >>> Wouldn’t it be confusing to use UniqueString type for a string that is >>> *common* in order to save memory? >> >> I

Re: [webkit-dev] the name "AtomicString"

> On Dec 19, 2018, at 9:41 PM, Chris Dumez wrote: > >> >> On Dec 19, 2018, at 9:17 PM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote: >> >> >> >>> On Dec 19, 2018, at 8:06 PM, Ryosuke Niwa >> <mailto:rn...@webkit.

Re: [webkit-dev] the name "AtomicString"

> On Dec 19, 2018, at 8:06 PM, Ryosuke Niwa wrote: > > On Wed, Dec 19, 2018 at 1:13 PM Simon Fraser > wrote: > > On Dec 19, 2018, at 12:33 PM, Michael Catanzaro > > wrote: > > > > On Tue, Dec 18, 2018 at 9:31 PM, Darin Adler >

Re: [webkit-dev] Hash table empty value

> On Dec 19, 2018, at 12:54 PM, Michael Catanzaro wrote: > > On Tue, Dec 18, 2018 at 2:31 PM, Ryosuke Niwa wrote: >> I tend to agree but then we'd come up with other numbers for the empty & >> deleted values. >> I've been thinking that we could use -1 and -2 but that's also somewhat >>

Re: [webkit-dev] the name "AtomicString"

> On Dec 19, 2018, at 12:33 PM, Michael Catanzaro wrote: > > On Tue, Dec 18, 2018 at 9:31 PM, Darin Adler wrote: >> I’ve gotten used to the name AtomicString over the years, but I wouldn’t >> strongly object to changing it if other programmers are often confused by >> it’s similarity to the

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

Right now, after a maybeMove type call on std::optional, you get either the original value, or a value that is officially valid but unspecified, and actually an optional that says it contains a value but doesn’t. With Chris’s proposal, you’d get a WTF::Optional with either the original value,

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

> On Dec 16, 2018, at 8:37 PM, Chris Dumez wrote: > > >> On Dec 16, 2018, at 7:43 PM, Fujii Hironori wrote: >> >> I don't like the proposal because it encourages misuse of move. >> We can use move only for values about to be destroyed. > > Just for reference, there are close to 400 matches

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

> On Dec 16, 2018, at 3:47 PM, Daniel Bates wrote: > > > >> On Dec 14, 2018, at 3:52 PM, Chris Dumez > > wrote: >> >> So to be clear, it is often not truly about using the value after it is >> moved. It is about expecting that the variable / member has been nulled

Re: [webkit-dev] Proposal for Device-Specific Layout Tests

> On Dec 12, 2018, at 2:20 PM, Jonathan Bedard wrote: > >> >> On Dec 12, 2018, at 11:16 AM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote: >> >> >> >>> On Dec 12, 2018, at 10:07 AM, Jonathan Bedard >> <mailto:jbed...@

Re: [webkit-dev] Proposal for Device-Specific Layout Tests

> On Dec 12, 2018, at 10:07 AM, Jonathan Bedard wrote: > > Ryosuke and I discussed this on Monday, and in passing, Ryosuke mentioned > that he personally finds something like this: > > .html > -expected.txt > -expected-.txt > > more clear than the directory method I

Re: [webkit-dev] Freenode spam counter-measure

gt; But ChanServ replied: >> >>ChanServ: You are not authorized to perform this command. >> >> I wonder who is authorized!? > > Looks like the authorized people include Maciej Stachowiak and Timothy > Hatcher. >

Re: [webkit-dev] wpt survey

Hello WebKit folks, You may be interested in this survey about Web Platform Tests. > -- Forwarded message -- > From: Simon Pieters mailto:si...@bocoup.com>> > Date: Tue, Jun 19, 2018 at 10:21 AM > Subject: Re: wpt survey > To: Jory Burson mailto:j...@bocoup.com>> > Cc: Philip

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

You can also just cd to the WebCore directory and type make. > On Mar 16, 2018, at 3:24 PM, youenn fablet wrote: > > If you have a full build and made changes to WebCore, you might only need to > recompile WebCore. With make for instance, one can do: > make d -C

Re: [webkit-dev] HSTS user tracking

> On Mar 1, 2018, at 10:44 AM, Michael Catanzaro wrote: > > On Fri, Jan 5, 2018 at 3:11 PM, Brent Fulgham wrote: >> I´m sorry we haven´t been forthcoming with details. We have wanted to put >> together a blog post explaining our fix, but have been

  1   2   3   4   5   6   7   8   9   10   >