Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

> On Aug 29, 2017, at 6:40 PM, Sam Weinig wrote: > > > >> On Aug 29, 2017, at 6:36 PM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote: >> >> >> >>> On Aug 29, 2017, at 5:54 PM, Sam Weinig >> <mailto:wei...@apple.com&g

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

> On Aug 30, 2017, at 2:15 AM, Konstantin Tokarev wrote: > > > > 30.08.2017, 03:01, "Michael Catanzaro" : >> On Tue, Aug 29, 2017 at 6:20 PM, Alicia Boya García >> wrote: >>> As long as the sets are generated consistently that approach should be >>> equally fine and indeed it would reduce

Re: [webkit-dev] Get rid of RefPtr, replace with std::optional?

> On Sep 1, 2017, at 9:30 AM, Brady Eidson wrote: > > I recently worked on a patch where - because of the organic refactoring of > the patch over its development - I ended up with a std::optional instead > of a RefPtr. > > A followup review after it had already landed pointed this out, and i

Re: [webkit-dev] Get rid of RefPtr, replace with std::optional?

> On Sep 1, 2017, at 10:07 AM, Brady Eidson wrote: > > > >> On Sep 1, 2017, at 9:46 AM, Maciej Stachowiak wrote: >>> >>> Does RefPtr do anything for us today that std::optional doesn’t? >> >> The obvious things would be: uses less s

Re: [webkit-dev] Remove Credential Management code

Apple's WebKit team is still interested in Credential Management. - Maciej > On Sep 6, 2017, at 9:29 AM, Sam Weinig wrote: > > Hey gang, > > I’d like to propose removing the Credential Management code from WebCore. > Work began on supporting this spec in January of this year, but so far, o

Re: [webkit-dev] Forward.h's Vector

> On Sep 13, 2017, at 8:11 AM, JF Bastien wrote: > > Hello WebCritters, > > I’m moving some code around, and one particular header I have is included > everywhere in JSC so I’d like it to be lightweight and include as few other > headers as possible. It unfortunately uses WTF::Vector, but it

Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

> On Oct 23, 2017, at 9:04 AM, Konstantin Tokarev wrote: > > > > 23.10.2017, 18:43, "Frédéric WANG" >: >> Hi, >> >> There have been some discussions recently on >> https://bugs.webkit.org/show_bug.cgi?id=177744 regarding the relevance >> of the compile-time flag fo

Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

> On Oct 24, 2017, at 12:14 AM, Frédéric WANG wrote: > > On 23/10/2017 18:11, Maciej Stachowiak wrote: >> >> Is there any way we can convert MathML to a runtime switch? It seems >> like the main consideration is rendering quality given available >> fonts, rath

Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

> On Oct 25, 2017, at 1:44 AM, Frédéric WANG wrote: > > On 24/10/2017 18:50, Maciej Stachowiak wrote: >> I don't have a strong opinion on whether we should support disabling >> MathML. My point is just that if we support disabling it, it should be >> a runtime s

Re: [webkit-dev] Formatting style for inline comments in Python code

> On Oct 26, 2017, at 10:20 AM, Eric Carlson wrote: > > > >> On Oct 26, 2017, at 9:50 AM, Brian Burg > > wrote: >> >> >> >>> 2017/10/26 午前9:21、Alexey Proskuryakov >> >のメール: >>> >>> >>> 25 окт. 2017 г., в 18:21, Michael Catanzaro >>> <

Re: [webkit-dev] Formatting style for inline comments in Python code

> On Nov 2, 2017, at 5:41 PM, Aakash Jain wrote: > > > >> On Oct 26, 2017, at 10:21 AM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote: >> >> >> >>> On Oct 26, 2017, at 10:20 AM, Eric Carlson >> <mailto:eric.carl...@

Re: [webkit-dev] Formatting style for inline comments in Python code

> On Nov 3, 2017, at 8:59 AM, Aakash Jain wrote: > > > >> On Nov 2, 2017, at 8:45 PM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote: >> >> >> >>> On Nov 2, 2017, at 5:41 PM, Aakash Jain >> <mailto:aakash_j...@apple.com

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

> On Nov 17, 2017, at 7:15 AM, Konstantin Tokarev wrote: > > > > 16.11.2017, 20:10, "Alexey Proskuryakov" : >> Migrating WebKit tests seems undesirable to me, as that would make us lose >> all their modification history. As mentioned before, WPT tests are >> inherently getting less attentio

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

> On Nov 17, 2017, at 7:05 AM, Frédéric WANG wrote: > > Hi Philip, > > We (at Igalia) are strong supporters of WPT tests and we've appreciated a lot > the effort made by Youenn and others to make them possible in WebKit. They > are very important for interoperability and make life much easie

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

> On Nov 17, 2017, at 7:53 AM, Frédéric WANG wrote: > > On 17/11/2017 16:26, Maciej Stachowiak wrote: >> WebKit has a lot of tests that were regression tests for a specific >> bug fix, not as conformance tests (though they might b useful for that >> too). In such

Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

> On Dec 12, 2017, at 11:42 AM, Mathias Bynens wrote: > > On Tue, Dec 12, 2017 at 8:38 PM, JF Bastien > wrote: > > On Tue, Dec 12, 2017 at 11:27 AM Mathias Bynens > wrote: > Ideally, projects such as jsvu wouldn’t have to make such decisions.

Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

the same. If I was building an installer that included these > ports, I’d prefer to get the downloads through Google/V8 too, if possible. > > On Tue, Dec 12, 2017 at 8:54 PM, Maciej Stachowiak <mailto:m...@apple.com>> wrote: > We do not have any Linux binaries blessed, appro

Re: [webkit-dev] HSTS user tracking

Brent Fulgham or John Wilander would know the details. - Maciej > On Jan 5, 2018, at 8:04 AM, Michael Catanzaro wrote: > > > Hi devs, > > Any info about how to mitigate this problem would be appreciated. Thanks! > > Michael > > ___ > webkit-dev

Re: [webkit-dev] Buildbot upgrade on build.webkit.org

> On Jan 8, 2018, at 1:33 PM, Aakash Jain wrote: > > Hi Everyone, > > I filed the Buildbot bug regarding Waterfall view not displaying steps > information by default: https://github.com/buildbot/buildbot/issues/3884 > "Waterfall view should

Re: [webkit-dev] OWNERS policy

> On Feb 21, 2018, at 11:06 PM, Carlos Garcia Campos > wrote: > > El mié, 21-02-2018 a las 13:49 -0800, Ryosuke Niwa escribió: >> If there was any confusion, WebKit2 Owner's policy is still active >> and in effect. > > And maybe it's time to get rid of it? I never liked the idea, but I > have

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 preoccupied with a >> number of other securi

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 Source/WebCore > > Y > > On

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 Jäg

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] Unified sources have broken our #include hygiene

> On Sep 13, 2018, at 3:49 AM, Frédéric Wang wrote: > > Hi, > > I've recently found two non-trivial issues with unified builds. They are > not missing #include but instead conflicts between C++ files: > > - Two C++ files including the same header but with a #define directive > set to differen

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 propose

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

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

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

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

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

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

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

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 w

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

I regret that 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 bor

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 regr

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 not

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] 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: https://wpt.fyi/results/?label=master&label=experime

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

p;label=experimental&product=chrome%5Btaskcluster%5D&product=firefox%5Btaskcluster%5D&product=safari%5Bazure%5D&aligned> > 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

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

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

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 t

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

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 peopl

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

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 a

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

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

uming it's 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 pas

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

> 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 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] 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 particular)

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 time

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&filter=ADC&q=is%3Adifferent&run_id=347530011&run_id=381930013

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

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

[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] 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 f

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 open

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

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

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] 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] 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: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] 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 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] 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] 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] 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. “unrevert

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 wor

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 scrol

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 lis

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] 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 my col

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 sc

<    8   9   10   11   12   13   14   15   16   17   >