Re: [webkit-dev] WebKit Documentation

[Simon Fraser via webkit-dev]

> On Mar 9, 2023, at 10:48 AM, Brandon Stewart via webkit-dev 
>  wrote:
> 
> Hello,
> 
> Sorry for the delay on the documentation update.
> 
> For getting the documentation system online, we were trying to settle on a 
> subdomain.
> 
> What would people prefer we use as the official documentation location:
> (1) docs.webkit.org
> (2) developer.webkit.org
> (3) documentation.webkit.org

Make both 1) and 3) work, choose one as the canonical one and have the other 
redirect. Minor preference for docs.webkit.org  as the 
canonical one.

Simon

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

Re: [webkit-dev] Unsigned to avoid negative values

[Simon Fraser via webkit-dev]

Late to the party but….

Avoiding unsigned is usually recommended to avoid inadvertent underflow:

unsigned big = 200;
unsigned small = 100;
auto result = small - big; // underflow

This is particularly bad when doing math on buffer offsets and sizes, and can 
result in OOB bugs. I believe Apple’s media frameworks code has a “no unsigned 
usage” rule because of that. I’m surprised that no-one has raised it in this 
discussion.

Simon

> On Jan 24, 2023, at 2:00 AM, Myles Maxfield via webkit-dev 
>  wrote:
> 
> Hello!
> 
> I recently learned that the C++ core guidelines recommend against using 
> unsigned to avoid negative values. Section 4.4 on page 73 of The C++ 
> Programming Language says unsigned types should be used for bitfields and not 
> in an attempt to ensure values are positive. Some talks by people on the C++ 
> standards committee (e.g., Herb Sutter) recommend against using unsigned 
> types simply because the value is expected to by positive.
> 
> Should we be avoiding unsigneds for these purposes? WebKit uses unsigneds all 
> over the place, and I’m assuming a fair many of them are there to indicate 
> that negative values are avoided. The C++ recommendation goes against my 
> intuition that the type is there for clarity, to indicate expectations about 
> the meaning and behavior of its value. But if it’s standard practice to just 
> use int instead, perhaps we should update the style guide?
> 
> What do you think?
> 
> —Myles
> ___
> 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] Update commit log template to add placeholder for explanation of why a patch fixes a bug

[Simon Fraser via webkit-dev]

> On Nov 17, 2022, at 12:23 PM, David Kilzer via webkit-dev 
>  wrote:
> 
> Hi,
> 
> The following PR adds placeholder text in the commit log template to remind 
> authors to explain why a change fixes a bug:
> 
> Bug 248012: Update commit message template to request a brief explanation of 
> why a PR fixes the bug
> 
> 
> 
> It looks like this:
> 
> Need a short description (OOPS!).
> Need the bug URL (OOPS!).
> Include a Radar link (OOPS!).
> 
> Reviewed by NOBODY (OOPS!).
> 
> Short explanation why this fixes the bug (OOPS!).

I would remove the word “Short”. Sometimes a longer explanation is needed. More 
that one paragraph is often a good thing (para 1 explains the bug, para 2 
explains how the change fixes it).

Simon



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

Re: [webkit-dev] Backlogs on ios-wk2

[Simon Fraser via webkit-dev]

https://trac.webkit.org/changeset/292051/webkit 
 should have fixed most of 
those crashes.

Simon

> On Mar 29, 2022, at 11:52 AM, Ken Russell via webkit-dev 
>  wrote:
> 
> Hi WebKit developers,
> 
> It looks like there's a ~10 hour backlog on the ios-wk2 bot (perhaps others 
> too?) right now:
> https://ews-build.webkit.org/#/builders/68 
> 
> 
> It looks like there are some crashes in layout tests that might be slowing 
> things down due to retries:
> https://ews-build.webkit.org/#/builders/68/builds/11776 
> 
> https://ews-build.s3-us-west-2.amazonaws.com/iOS-15-Simulator-WK2-Tests-EWS/455999-11776/results.html
>  
> 
> 
> Could someone please take a look?
> 
> Thanks,
> 
> -Ken
> 
> 
> -- 
> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposed changes to Bugzilla 'Resolution' categories

[Simon Fraser via webkit-dev]

> On Feb 10, 2022, at 11:55 AM, Brent Fulgham via webkit-dev 
>  wrote:
> 
> Hi Floks,
> 
> I would like to propose some changes to the categories we use to resolve 
> bugs. I’ve been trying to do some Bugzilla gardening to better reflect the 
> state of various “edge case” bugs that often leave users confused about the 
> state of issues they’ve reported, and unsure of whether fixes are needed or 
> have been shipped.
> 
> Some of this is due to inertia, but some is due to lack of clarity in how to 
> treat a few categories of bugs.
> 
> (1) Add a new “Behaves As Designed” option:
> 
> This will represent bugs that were filed when the reporter misunderstands a 
> feature, or wants behavior that we have considered, but chosen not to allow.
> 
> This would be used instead of the somewhat offensive “WONTFIX” or mildly 
> offensive “INVALID” resolutions we currently use.

I like.

> 
> (2) Add a new “Platform To Resolve” option:
> 
> This will represent bugs that are actually in an underlying component outside 
> of sources in the WebKit project. This might be used to represent graphics 
> driver bugs, kernel issues, platform User Interface libraries, or most 
> frequently bugs in applications driving WebKit.
> 
> This would be used instead of the somewhat offensive ‘INVALID” resolution.

I've used RESOLVED/MOVED for this, which seems reasonable (though the MOVED is 
pretty vague: moved where?).

Simon

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

Re: [webkit-dev] Fuzzy Reftest Plans, and Metadata Locations

[Simon Fraser via webkit-dev]

> On Oct 30, 2021, at 10:45 AM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> On Thu, Oct 28, 2021 at 10:24 AM Sam Sneddon via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
> As part of the ongoing work on GPU Process, we’re interested in adding 
> support for reftest fuzzy matching (i.e., allowing a certain amount of 
> tolerance when comparing the generated images).
> 
> Our intention is to match the semantics of WPT’s reftests 
> (https://web-platform-tests.org/writing-tests/reftests.html#fuzzy-matching 
> ):
> 
> There are cases where we’ll want to apply these to the tests unconditionally, 
> for example where varying behaviour is expected across ports (such as 
> anti-aliasing differences), and in these cases for WPT tests these 
> annotations should probably be exported upstream.
> 
> The current plan, and work is underway to do this, is to support this syntax 
> via parsing the HTML in Python when there is a hash mismatch, which should 
> minimise the performance impact versus always reading this metadata.
> 
> However, this doesn’t entirely suffice. There are cases where we might want 
> to allow more tolerance on one platform or another, or vary based on GPU 
> model or driver. As such, this requires not only platform specific metadata 
> (i.e., similar to that which we have in TestExpectations files today), but 
> also expectations with finer granularity.
> 
> Are we sure we really need that? What are examples of tests that do warrant 
> such a mechanism?
> 
> Generally, we want to keep our testing infrastructure as simple as possible.
> 
> One option is to extend the meta content to encode conditional variants, 
> though this doesn’t work for WPT tests (unless we get buy-in to upstream 
> these annotations into the upstream repo, though that might be desirable for 
> the sake of results on wpt.fyi). We would need to be confident that this 
> wouldn’t become unwieldy however; we wouldn’t want to end up with something 
> like 
> (if:port=Apple)maxDifference=1;totalPixels=10,(if:platform=iOS)maxDifference=10;totalPixels=20,(if:port=GTK)maxDifference=10;totalPixels=300.
> 
> Another option is to extend TestExpectations to store more specific data 
> (though again this might become unwieldy, as we’re unlikely to add new 
> “platforms” based on every variable we might want to distinguish results on). 
> This also means the metadata is far away from the test itself, and the 
> TestExpectations files would continue to grow even further (and we already 
> have 34k lines of TestExpectations data!). TestExpectations is also a rather 
> horrible file format to modify the parser of.
> 
> I'm fine with either of the above options but I don't think we should 
> introduce this kind of micro syntax if we're going with meta.
> 
> We should probably specify a platform in a different attribute altogether. 
> e.g.
> 

I like this suggestion; WPT already allows multiple  because 
you can specify a per-reference fuzzy value:
.

> 
> I really hate that WPT is using a micro-syntax for this. Why isn't this 
> simply a different content attribute like this:
>  total-pixels="300">

Indeed. Maybe be should propose that change to avoid complicating the 
micro-syntax?

> 
> There is also test-options.json which has most of the same downsides as 
> TestExpectations, albeit without the pain in modifying the parser.
> 
> Finally, we could add per-test or per-directory files alongside the tests. 
> (Due to how things work, these could presumably also be in directories in 
> platform/.) This I think is probably the best option as it keeps the metadata 
> near the test, without needing to modify the test (which, per above, is 
> problematic for WPT as we move to automatically exporting changes). One could 
> imagine either a __dir__-metadata.json (to use a similar name to how WPT 
> names directory-level metadata files) or a -expected-fuzzy.json file 
> alongside each test.
> 
> Both of these two options seem worse than either encoding in the test or 
> putting in the test expectations. They invent a brand new mechanism to store 
> metadata for tests. We don't want to introduce yet another file / mechanism 
> people need to be aware of.

It may be that, for performance, we have a run-tests-time step that extracts 
fuzzy data from tests and puts it in a file somewhere, but that's orthogonal to 
where devs go to look for/edit fuzzy data.

Also something to consider: when importing WPT, we extract "slow" metadata and 
store it in a file. We should converge our solutions for all these WPT features 
that involve metadata in tests.

Simon

___
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

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

[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

Re: [webkit-dev] Request for Position on Delegated Ink Trails

[Simon Fraser via webkit-dev]

I don't think WebKit has a strong opinion on this. From an Apple perspective, 
we try very hard to make our hardware and software stack be performant enough 
that special cases like this are not necessary. I can't speak to other WebKit 
platforms.

Simon

> On May 11, 2021, at 9:32 AM, Mario Bianucci via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
>  
> Apologies for the noise, but bringing this back up to the top of people’s 
> inboxes.
>  
> This is a request for WebKit's position on Delegated Ink Trails.
>  
> It is currently in progress behind a flag in Chromium. The spec is in 
> progress, but until it is available, here is a link to the WICG explainer:
> https://github.com/WICG/ink-enhancement 
> 
>  
> Thanks,
> Mario Bianucci
> ___
> 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: New Canvas 2D API

[Simon Fraser via webkit-dev]

> On May 1, 2021, at 10:07 AM, Aaron Krajeski via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> This is a request for WebKit's position on New Canvas 2D API 
>  features. 
> 
> Explainer/Chrome Dev Summit Video
> https://github.com/fserb/canvas2d 
> https://youtu.be/dfOKFSDG7IM 
> 
> Summary
> Updated functionality for the Canvas2D API. Adds nine new features/functions 
> to CanvasRenderingContext2D:
>   - "ContextLost" and "ContextRestored" events

Seems reasonable.

>   - "willReadFrequently" option for canvases where lots of readback is 
> expected

Seems reasonable.

>   - CSSColorValues as style inputs

Seems reasonable (gated on Typed OM support).

>   - More CSS text modifier support

WebKit has already expressed support for the proposal.

>   - A reset function

We'e already expressed some concerns in the issue.

>   - A roundRect draw primitive

Seems reasonable.

>   - Full 4x4 transformation matrices

WebKit's architecture on macOS/iOS currently has no way to render these, so we 
don't support this proposal at this time.

>   - Conic gradients

Seems reasonable.

>   - Better support for SVG filters

Seems reasonable, although this would have performance implications in our 
current architecture.

Simon

> 
> Contact emails
> aaro...@chromium.org , fs...@chromium.org 
> 
> 
> Spec and tests
>   - WHATWG spec in progress:
>   Text Modifiers 
>   Filters 
>   Perspective Transforms 
>   reset() 
>   CSSColorValue 
>   willReadFrequently 
>   RoundRect 
>   ConicGradient 
>   Context Loss 
>   - MDN spec 
>  Conic gradient 
> 
>   Text Modifiers 
>  (via 
> ChromeLabs/puppy-content)
>   - Web platform tests
>   RoundRect
> 
>   reset() 
> 
>   Perspective Transforms 
> 
>   Context Loss 
> 
>  (this is not testable on WPT)
>   Filters 
> 
>   CSSColorValue Input 
> 
>   WillReadFrequently 
> 
>  (testable in WPT, work in progress to add tests there)
>   Conic Gradient 
> 
>   Text Modifiers 
> 
>   - Chrome Status 
> 
> Look forward to hearing your feedback!
> 
> Cheers!
>   Aaron
> ___
> 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 CSS containment

[Simon Fraser via webkit-dev]

We have no code for css containment yet.

Simon


> On Mar 15, 2021, at 12:57 PM, Rob Buis  wrote:
> 
> Hi,
> 
> If true, then https://bugs.webkit.org/show_bug.cgi?id=172026 can be closed.
> 
> I am finding the feature in features.json, but I am not sure that means there 
> is actual code.
> 
> There may be code in RenderLayerBacking, but AFAIU that would mean "only" 
> contain: paint and would not be WebExposed? Can somebody check?
> 
> Regards,
> 
> Rob.
> 
> Am 15.03.21 um 20:18 schrieb Simon Fraser:
>> WebKit supports CSS containment.
>> 
>> Simon
>> 
>>> On Mar 15, 2021, at 9:14 AM, Rob Buis via webkit-dev 
>>>  wrote:
>>> 
>>> Hi webkit-dev,
>>> 
>>> This is a request for WebKit's position on CSS containment.
>>> 
>>> Our first interest is to implement the contain property as specified here:
>>> https://www.w3.org/TR/css-contain-1/
>>> 
>>> After that, we want to work on style containment and the content-visibility 
>>> property:
>>> https://www.w3.org/TR/css-contain-2/
>>> Regards,
>>> 
>>> Cathie and Rob.
>>> ___
>>> 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 CSS containment

[Simon Fraser via webkit-dev]

WebKit supports CSS containment.

Simon

> On Mar 15, 2021, at 9:14 AM, Rob Buis via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> This is a request for WebKit's position on CSS containment.
> 
> Our first interest is to implement the contain property as specified here:
> https://www.w3.org/TR/css-contain-1/
> 
> After that, we want to work on style containment and the content-visibility 
> property:
> https://www.w3.org/TR/css-contain-2/
> Regards,
> 
> Cathie and Rob.
> ___
> 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: CSS scrollbar-gutter

[Simon Fraser via webkit-dev]

WebKit does not support this feature as specified.

Our opinion is that we don't want to encourage web developers to reserve space 
for scrollbars in a way that prevents non-interactive content from intruding 
into that space. This undoes a big advantage of overlay scrollbars, in that 
they leave more space for content.

Our preference would be some kind of margin value (perhaps a constant) that 
allows authors to move only interactive content outside of the area affected by 
overlay scrollbars.

Simon


> On Feb 23, 2021, at 5:54 AM, 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

Re: [webkit-dev] Request for position: Support full 'filter' syntax (i.e filter functions/shorthands) on SVG elements

[Simon Fraser via webkit-dev]

WebKit supports this proposal.

Simon

> On Dec 18, 2020, at 5:32 AM, Fredrik Söderquist via webkit-dev 
>  wrote:
> 
> Hello webkit-dev,
> 
> I'm seeking WebKit's position on application of filter functions/full 
> 'filter' property syntax (as already implemented for HTML elements) on SVG 
> elements.
> 
> Spec: https://drafts.fxtf.org/filter-effects-1/#FilterProperty 
> 
> Chrome Status entry: https://chromestatus.com/feature/5076637643177984 
> 
> 
> (Is there any more specific bug than 
> https://bugs.webkit.org/show_bug.cgi?id=68469 
>  ?)
> 
> Thanks,
> /fs

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

Re: [webkit-dev] Request for position: overflow: clip and overflip-clip-margin

[Simon Fraser via webkit-dev]

We support the addition of these properties.

Simon

> On Dec 7, 2020, at 2:09 PM, Scott Violet via webkit-dev 
>  wrote:
> 
> Hello Webkit-dev,
> 
> I'm seeking WebKit's position on overflow:clip [1] and overflow-clip-margin 
> [2]. These are part of CSS Overflow Module Level 3.
> 
> [1] - https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip 
> 
> [2] - https://drafts.csswg.org/css-overflow-3/#propdef-overflow-clip-margin 
> 
> 
> Thanks,
> 
>   -Scott
> ___
> 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