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

Re: [webkit-dev] Request for a position on the Idle Detection API

[Simon Fraser]

Can you describe what a permission prompt would look like that allows the user 
to make an informed decision about whether they should allow or deny the 
permission?

Simon

> On Oct 28, 2020, at 4:56 PM, Reilly Grant  wrote:
> 
> Greetings WebKit engineers,
> 
> I would like to request an official position from the WebKit team on the 
> emerging Idle Detection API  
> specification. I am aware that this API was included in a list of APIs 
>  which you have decided not to 
> implement due to fingerprinting concerns. I assume that this objection was 
> based on the original explainer provided for this API. Since that list was 
> posted the API has been extended to include a permission that sites must 
> acquire before being granted access to user presence signals. I would like to 
> start a conversation to understand the fingerprinting risks you foresee from 
> this API.
>   
> Reilly Grant
> Software Engineer
> reil...@google.com 
> Google Chrome
> ___
> 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 Event Timing

[Simon Fraser]

Our feedback is that this API seems reasonable, but that there's overlap with 
the "long tasks" API,
and it's not clear if we need both.

Simon

> On Aug 6, 2020, at 10:43 AM, Rob Buis  wrote:
> 
> Hi Webkit-Dev,
> 
> I would like to get an official position from Webkit on the Event Timing Web 
> Perf API.
> Besides providing information about input event latency it can be used to 
> obtain
> First Input Timing metrics. This specification builds on the Performance 
> Timeline
> specification, which is implemented in Webkit. Chrome has implemented the 
> Event
> Timing API, see the chrome status entry below.
> 
> - Specification: https://wicg.github.io/event-timing/
> - Explainer: https://github.com/WICG/event-timing
> - MDN: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming
> - ChromeStatus: https://chromestatus.com/feature/5167290693713920
> - Caniuse.com URL: https://caniuse.com/#feat=mdn-api_performanceeventtiming
> 
> Regards,
> 
> 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] [webkit-changes] [264332] trunk/Source

[Simon Fraser]

Could someone educate me about ? When should I use this instead 
of individual wtf headers?

Simon

> On Jul 14, 2020, at 2:32 PM, Sam Weinig  wrote:
> 
> While I don’t want to take away from what Darin is saying here about correct 
> usage of forward declaration and , I’d like to understand why 
> we have two different compilation models supported in WebKit. Is there a 
> reason both need to be supported? Can we remove one?
> 
> - Sam
> 
>> On Jul 14, 2020, at 10:40 AM, Darin Adler > > wrote:
>> 
>> We need to be cautious about adding header includes to other headers. Adding 
>> includes to .cpp files is likely fine and not a deeply consequential 
>> decision, but adding to headers is something that can have a massive effect 
>> on build times over time.
>> 
>>> On Jul 13, 2020, at 10:44 PM, hironori.fu...@sony.com 
>>>  wrote:
>>>  <>Modified: trunk/Source/WebCore/platform/graphics/ColorSerialization.h 
>>> (264331 => 264332)
>>> 
>>> --- trunk/Source/WebCore/platform/graphics/ColorSerialization.h 
>>> 2020-07-14 05:17:20 UTC (rev 264331)
>>> +++ trunk/Source/WebCore/platform/graphics/ColorSerialization.h 
>>> 2020-07-14 05:44:25 UTC (rev 264332)
>>> @@ -25,6 +25,8 @@
>>>  
>>>  #pragma once
>>>  
>>> +#include 
>> This change is wrong. The header to include here is Forward.h, not 
>> WTFString.h. Not super-harmful since WTFString.h is already so widely 
>> included, but we need to be really cautious in headers.
>> 
>>> Modified: trunk/Source/WebCore/svg/SVGParserUtilities.h (264331 => 264332)
>>> 
>>> --- trunk/Source/WebCore/svg/SVGParserUtilities.h   2020-07-14 05:17:20 UTC 
>>> (rev 264331)
>>> +++ trunk/Source/WebCore/svg/SVGParserUtilities.h   2020-07-14 05:44:25 UTC 
>>> (rev 264332)
>>> @@ -24,6 +24,7 @@
>>>  #include "ParsingUtilities.h"
>>>  #include 
>>>  #include 
>>> +#include 
>> Same mistake.
>> 
>> I’d really like to come up with some other system for reviewing adding 
>> headers to *headers*.
>> 
>> — Darin
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

[Simon Fraser]

I also object to losing good stack traces for crashes on Debug bots.

Also, I don't think Debug bots should build something different from what I 
build at my desk.

Simon

> On Jun 17, 2020, at 1:36 PM, Mark Lam  wrote:
> 
> Hi folks,
> 
> We're planning to switch the JSC EWS bot and build.webkit.org 
>  Debug build and test bots to building with the 
> following set first:
> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
> 
> This means the Debug builds will be built with optimization level forced to 
> O3.
> 
> Why are we doing this?
> 1. So that the JSC EWS will start catching ASSERT failures.
> 2. JSC stress test Debug bots have been timing out and not running tests at 
> all.  Hopefully, this change will fix this issue.
> 3. Tests will run to completion faster and we’ll catch regressions sooner.
> 
> The downside: crash stack traces will be like Release build stack traces.  
> But I don’t think we should let this deter us.  It’s not like there’s no 
> stack information.  And just as we do with debugging Release build test 
> failures, we can always do a Debug build locally to do our debugging.
> 
> We would like to apply this change to all Debug build and test bots, not just 
> the JSC ones.  Does anyone strongly object to this change?
> 
> Thanks.
> 
> Cheers,
> Mark
> 
> ___
> 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 removing 'no-preference' for prefers-color-scheme media feature

[Simon Fraser]

Thanks. I filed https://bugs.webkit.org/show_bug.cgi?id=212952 
 for the webkit fix.

Simon

> On Jun 8, 2020, at 6:35 AM, Rune Lillesveen  wrote:
> 
> Hi,
> 
> Per CSSWG resolution [1], 'no-preference' has been removed from the Media 
> Queries Level 5 specification. We (Blink) intend to align with the spec and 
> remove support for the 'no-preference' keyword from Blink. Firefox has also 
> stated that they will follow to do so [2].
> 
> [1] https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-634779976 
> 
> [2] 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/3RhZFvZE1LM/t7BpLBWkAwAJ
>  
> 
> 
> ___
> 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] Position on emerging standard: Scroll-linked Animations

[Simon Fraser]

We support the proposal in general. We think it's a good starting point for 
more complex scroll-linked effects, and look forward to discussing ways to 
achieve more rich scrolling-triggered behaviors in future.

Simon

> On Jun 3, 2020, at 5:08 PM, Majid Valipour  wrote:
> 
> Hi,
> 
> I like to request an official WebKit/Safari position on the Scroll-linked 
> Animations proposal. The proposal has been in incubation in CSSWG (and in 
> WICG before that) for some time now and has received feedback from WebKit 
> engineers among other working group participants.
> 
> Links to additional relevant documents and discussions:
> 
> - Explainer: 
> https://github.com/w3c/csswg-drafts/blob/master/scroll-animations-1/EXPLAINER.md
>  
> 
> - Draft Specification: https://drafts.csswg.org/scroll-animations/ 
> 
> - Some key open issues: https://github.com/w3c/csswg-drafts/milestone/6 
> 
> - Request for Mozilla's Position: 
> https://github.com/mozilla/standards-positions/issues/347 
> 
> - Blink Intent to Implement: 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/8V4ixKVmNY4/vJQdo9GCBgAJ
>  
> 
> 
> 
> Thanks,
> Majid Valipour
> ___
> 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] WebKit's position on @property

[Simon Fraser]

In general we are supporting. We've given some feedback here: 
>

Simon

> On Apr 23, 2020, at 2:44 AM, Anders Hartvoll Ruud  
> wrote:
> 
> Hi,
> 
> In Blink there's currently an intent to ship 
> 
>  @property from CSS Properties & Values 
> .
>  I've noticed that there's an in-progress implementation of 
> CSS.registerProperty in WebKit, and I'm wondering if you're also considering 
> implementing @property, or you have any thoughts on it in general.
> 
> Anders
> 
> ___
> 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] Is anyone maintaining Nicosia scrolling code?

[Simon Fraser]

> On Feb 23, 2019, at 3:29 AM, z...@falconsigh.net wrote:
> 
> On Sat, Feb 23, 2019, at 2:47 AM, Simon Fraser wrote:
>> There’s a bunch of code in Source/WebCore/page/scrolling/nicosia/ that 
>> I keep breaking with scrolling tree refactoring. Most of it it stubs. 
>> Is anyone maintaining this code, because it obviously doesn’t work, and 
>> I’d like to remove the maintenance burden.
>> 
> 
> I added the stubs there, and was planning to start adding actual 
> implementations there in the following weeks, now that a new release cycle 
> was just entered.
> 
> I wouldn't mind disabling or removing the code temporarily in order to enable 
> you an easier time refactoring around it. But given that the async scrolling 
> capability is something we plan to add support for in the WPE and GTK ports, 
> I'd appreciate some input about the scope and the timeframe of your work and 
> possibility of sharing as much of the implementation as possible between 
> different ports.

I’m hitting Nicosia compile issues again 
(https://bugs.webkit.org/show_bug.cgi?id=208282) and the last Nicosia-related 
commit was on October 3.

Does Nicosia qualify as a “science project” in the sense listed at 
https://webkit.org/project/ <https://webkit.org/project/> . Googling for 
Nicosia finds no technology-related hits on the first page.

Simon



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

Re: [webkit-dev] Naming convention for static member variables

[Simon Fraser]

Thank you. I filed https://bugs.webkit.org/show_bug.cgi?id=207961 
<https://bugs.webkit.org/show_bug.cgi?id=207961>

Simon

> On Feb 19, 2020, at 11:39 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 19.02.2020, 22:31, "Simon Fraser" :
>> class Foo {
>>   static bool thing.
>> };
>> 
>> What's the naming convention for static member variables like this? I've 
>> seen m_foo, which seems positively harmful. I've seen s_foo, which I like.
>> 
>> There are 165 instances of s_ that I can find in the project. There are 17 
>> instances of static m_.
> 
> According to [1], convention is "s_". Apparently, it just lacks an 
> enforcement in style checker.
> 
> [1] https://webkit.org/code-style-guidelines/#names-data-members
> 
> -- 
> Regards,
> Konstantin
> 

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

[webkit-dev] Naming convention for static member variables

[Simon Fraser]

class Foo {
  static bool thing.
};

What's the naming convention for static member variables like this? I've seen 
m_foo, which seems positively harmful. I've seen s_foo, which I like.

There are 165 instances of s_ that I can find in the project. There are 17 
instances of static m_.

Simon

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

Re: [webkit-dev] Position on emerging standard: video.requestAnimationFrame()

[Simon Fraser]

> On Feb 5, 2020, at 4:52 PM, Thomas Guilbert  wrote:
> 
> I am moving the execution of the video.rAF callbacks to be part of the 
> rendering steps. This should guarantee that "changes made inside the callback 
> appear at the same time as other changes in the same event loop cycle".
> I don't know if there is a place within the rendering steps where it makes 
> most sense for them to run. I'm planning on having them run before the 
> window.rAF callbacks, but I don't know after which of the other steps for now.
> 
> That being said, if you paint a 24fps  into a  on every 
> video.rAF call, the canvas might still be 1/60th of a second behind the 
> video. This happens when we miss the rendering steps after jumping back on 
> the main thread, and have to wait for the next rendering steps (waiting 
> doesn't really change anything though, if the callbacks were fired earlier, 
> their changes would still appear later).
> 
> Simon, does having video.rAF callbacks run as part of the rendering steps 
> address some of your concerns?

It does, although I still don't like the name.

The spec also needs somehow trigger the "update the rendering" steps if a new 
video frame is available and there is a pending video.rAF (video playback alone 
does not trigger the rendering steps, at least in WebKit, for performance 
reasons).

Simon

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

Re: [webkit-dev] Position on emerging standard: video.requestAnimationFrame()

[Simon Fraser]

> On Feb 3, 2020, at 11:25 AM, Ken Russell  wrote:
> 
> The name "requestAnimationFrame" was chosen mainly to achieve parity with the 
> AnimationFrameProvider mixin, which now provides the same animation facility 
> to the main thread and dedicated workers:
> https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#animation-frames
>  
> <https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#animation-frames>
> https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691 
> <https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691>
> 
> It offers a nice symmetry with other JavaScript-driven animations.

But the video.requestAnimationFrame behavior seems fundamentally different to 
window.requestAnimationFrame. It feels like it's conflating two different 
things.

Simon

> 
> -Ken
> 
> 
> 
> On Mon, Feb 3, 2020 at 6:58 AM Philip Jägenstedt  <mailto:foo...@chromium.org>> wrote:
> Hi Simon,
> 
> Naming is hard as usual and was discussed on 
> https://github.com/w3ctag/design-reviews/issues/429 
> <https://github.com/w3ctag/design-reviews/issues/429>, where you've already 
> commented.
> 
> Is there a pair of names that you think would work better here? 
> onFrameAvailable() would IMHO be quite unidiomatic, the web platform doesn't 
> have any other onFoo() methods, and what would the "cancel" variant be called?
> 
> Can you file an issue in https://github.com/WICG/video-raf/issues 
> <https://github.com/WICG/video-raf/issues> if you see a good alternative?
> 
> Also curious if +Eric Carlson <mailto:eric.carl...@apple.com> has any 
> feedback on this?
> 
> On Wed, Jan 22, 2020 at 10:49 PM Simon Fraser  <mailto:simon.fra...@apple.com>> wrote:
> 
>> On Jan 21, 2020, at 5:27 PM, Thomas Guilbert > <mailto:tguilb...@google.com>> wrote:
>> 
>> The idea was to reuse an API name that developers are already familiar with, 
>> in a similar context. The name is also being used in XRSession 
>> (https://developer.mozilla.org/en-US/docs/Web/API/XRSession/requestAnimationFrame
>>  
>> <https://developer.mozilla.org/en-US/docs/Web/API/XRSession/requestAnimationFrame>),
>>  and in OffscreenCanvas (or technically DedicatedWorkerGlobalScope). The 
>> AnimationFrameProvider mixin 
>> <https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#animationframeprovider>
>>  could also be updated so HTMLVideoElement can extend it.
>> 
>> Yes, this isn't formally spec'ed out, but it will be. For now, they are 
>> added to the task queue and run like any other task. So, going off the spec 
>> you linked, I think this would be "5) Perform oldestTask's step"  and not 
>> "10) Rendering: [...] 11. Foreach document run animation frame callbacks for 
>> that Document".
> 
> I would expect something that's called "requestAnimationFrame" to only fire 
> in the "update the rendering" steps; requestAnimationFrame is a "before 
> rendering" callback. So firing a callback with the same name at other times 
> seems like it will lead to author confusion.
> 
> The author's expectation should be that any content/style changes they make 
> inside a requestAnimationFrame callback will appear on-screen in the same 
> frame as other changes in the same event loop cycle, and that 
> requestAnimationFrame won't be called more often than is necessary to update 
> the screen at the appropriate frame rate.
> 
> Simon
> 
>> 
>> On Tue, Jan 21, 2020 at 1:01 PM Simon Fraser > <mailto:simon.fra...@apple.com>> wrote:
>>> On Jan 21, 2020, at 12:37 PM, Thomas Guilbert >> <mailto:tguilb...@google.com>> wrote:
>>> 
>>> Hello,
>>> I'm reaching out to see if webkit would like to weigh in on the following 
>>> proposal:
>>> https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691 
>>> <https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691>
>>> The HTMLVideoElement.requestAnimationFrame() API allows web developers to 
>>> be notified when a video frame has been presented for composition, and 
>>> provides metadata for that frame.
>>> If you want to try it out, a prototype is available in Chromium Dev, behind 
>>> the enable-experimental-web-platform-features flag.
>> 
>> This is not official feedback, but I have some issues with the proposal.
>> 
>> First, the name is confusing. It sounds like you're requesting a frame from 
>> the video, but it&#x

Re: [webkit-dev] Position on emerging standard: video.requestAnimationFrame()

[Simon Fraser]

> On Jan 21, 2020, at 5:27 PM, Thomas Guilbert  wrote:
> 
> The idea was to reuse an API name that developers are already familiar with, 
> in a similar context. The name is also being used in XRSession 
> (https://developer.mozilla.org/en-US/docs/Web/API/XRSession/requestAnimationFrame
>  
> <https://developer.mozilla.org/en-US/docs/Web/API/XRSession/requestAnimationFrame>),
>  and in OffscreenCanvas (or technically DedicatedWorkerGlobalScope). The 
> AnimationFrameProvider mixin 
> <https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#animationframeprovider>
>  could also be updated so HTMLVideoElement can extend it.
> 
> Yes, this isn't formally spec'ed out, but it will be. For now, they are added 
> to the task queue and run like any other task. So, going off the spec you 
> linked, I think this would be "5) Perform oldestTask's step"  and not "10) 
> Rendering: [...] 11. Foreach document run animation frame callbacks for that 
> Document".

I would expect something that's called "requestAnimationFrame" to only fire in 
the "update the rendering" steps; requestAnimationFrame is a "before rendering" 
callback. So firing a callback with the same name at other times seems like it 
will lead to author confusion.

The author's expectation should be that any content/style changes they make 
inside a requestAnimationFrame callback will appear on-screen in the same frame 
as other changes in the same event loop cycle, and that requestAnimationFrame 
won't be called more often than is necessary to update the screen at the 
appropriate frame rate.

Simon

> 
> On Tue, Jan 21, 2020 at 1:01 PM Simon Fraser  <mailto:simon.fra...@apple.com>> wrote:
>> On Jan 21, 2020, at 12:37 PM, Thomas Guilbert > <mailto:tguilb...@google.com>> wrote:
>> 
>> Hello,
>> I'm reaching out to see if webkit would like to weigh in on the following 
>> proposal:
>> https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691 
>> <https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691>
>> The HTMLVideoElement.requestAnimationFrame() API allows web developers to be 
>> notified when a video frame has been presented for composition, and provides 
>> metadata for that frame.
>> If you want to try it out, a prototype is available in Chromium Dev, behind 
>> the enable-experimental-web-platform-features flag.
> 
> This is not official feedback, but I have some issues with the proposal.
> 
> First, the name is confusing. It sounds like you're requesting a frame from 
> the video, but it's really a "frame available" callback. Why not call it 
> onFrameAvailable()?
> 
> Second, its interaction with normal requestAnimationFrame() and the HTML 
> event loop needs to be better defined. Where in in the 
> https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model
>  
> <https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model>
>  do these callbacks fire?
> 
> Simon
> 
> 

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

Re: [webkit-dev] Position on emerging standard: video.requestAnimationFrame()

[Simon Fraser]

> On Jan 21, 2020, at 12:37 PM, Thomas Guilbert  wrote:
> 
> Hello,
> I'm reaching out to see if webkit would like to weigh in on the following 
> proposal:
> https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691 
> 
> The HTMLVideoElement.requestAnimationFrame() API allows web developers to be 
> notified when a video frame has been presented for composition, and provides 
> metadata for that frame.
> If you want to try it out, a prototype is available in Chromium Dev, behind 
> the enable-experimental-web-platform-features flag.

This is not official feedback, but I have some issues with the proposal.

First, the name is confusing. It sounds like you're requesting a frame from the 
video, but it's really a "frame available" callback. Why not call it 
onFrameAvailable()?

Second, its interaction with normal requestAnimationFrame() and the HTML event 
loop needs to be better defined. Where in in the 
https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model
 

 do these callbacks fire?

Simon


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

Re: [webkit-dev] Supporting for finding ref tests

[Simon Fraser]

> On Nov 12, 2019, at 4:52 AM, Frédéric Wang  wrote:
> 
> On 09/11/2019 04:02, Ryosuke Niwa wrote:
>> 
>  - Requires us modifying each port's DRT to support this format
> 
> No, it just requires webkitpy hacking which I've done in the patch.
 I'm not certain writing a bunch of regular expressions in webkitpy is
 a reliable mechanism to find expected results. Another issue I found
 back then was that it significantly slowed run-webkit-tests' startup
 time because WPT has a workflow to find all tests & their expected
 results upfront before any tests could run.
>>> The patch uses html5lib (via BeautifulSoup), which is exactly what WPT, and 
>>> our importer use to find the ref tests.
>>> 
>>> We don't find references up-front; only when running each test. This patch 
>>> does add some overhead for parsing each test file,
>>> which I measured to be about 1-2 sec on a directory which took 30s to run. 
>>> I think this slight slowdown is worthwhile (we could
>>> probably eliminate it with some webkitpy optimizations).
>> Hm... that's ~3% overhead.
> 
> @Simon: I agree with Ryosuke that 3% sounds big. IIUC you are parsing
> the HTML file when running each test? I thought that there is a
> MANIFEST.json file which is supposed to cache that information, why
> can't we use it?

I don't see any files call MANIFEST.json in the wpt repo.

There are reftest.list files but these are obsolete.

I hope to get that 3% back by other webkitpy perf optimizations (python 
optimization hints welcome).

Simon

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

Re: [webkit-dev] Supporting for finding ref tests

[Simon Fraser]

> On Nov 8, 2019, at 2:15 PM, Robert Ma  wrote:
> 
> WPT has recently passed an RFC 
> 
>  trying to simplify the reftest graph (although it has not been implemented 
> yet), which eliminates a lot of the complexities and concerns.

That sounds like a very sensible proposal.

It will take some work in webkitpy to support multiple , but since 
we don't support that when importing now anyway, I don't see it as a blocker to 
adding  support.

I filed webkit.org/b/204022  to implement support 
for multiple .

Simon

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

Re: [webkit-dev] Supporting for finding ref tests

[Simon Fraser]

> On Nov 8, 2019, at 2:07 PM, Ryosuke Niwa  wrote:
> 
> On Fri, Nov 8, 2019 at 2:01 PM Simon Fraser  wrote:
>> 
>> I'd like to land a patch to support finding test references via > rel="match/mismatch">:
>> https://bugs.webkit.org/show_bug.cgi?id=203784
>> 
>> There has been some discussion about this in the past:
>> https://lists.webkit.org/pipermail/webkit-dev/2011-November/018470.html
>> 
>> But I think the benefits outweigh the drawbacks. As that mail states:
>> 
>> *Link element approach*
>> Pros:
>> 
>>   - Can reuse same ref. file for multiple tests
>> 
>> Still true.
>> 
>>   - Can have multiple ref. files for single test
>> 
>> True but no something that we support, and I haven't see any WPT use this 
>> (our importer throws an error if it sees this)
>> 
>>   - Information is self-contained in the test file
>> 
>> Still true
>> 
>>   - We may get away with test suite build step
>> 
>> It certainly simplifies WPT test import.
>> 
>> Currently importing some CSS suites (e.g. css-backgrounds) results in broken 
>> -expected.html files because copying them breaks references to sub resources.
>> 
>> (It turns out that we can't convert W3C ref tests to use WebKit conventions
>> due to the first two points.)
>> 
>> We're doing this much more now, and the "multiple references" point is moot, 
>> so I think we can import WPT tests mostly as-is.
>> 
>> Cons:
>> 
>>   - Requires us modifying each port's DRT to support this format
>> 
>> No, it just requires webkitpy hacking which I've done in the patch.
> 
> I'm not certain writing a bunch of regular expressions in webkitpy is
> a reliable mechanism to find expected results. Another issue I found
> back then was that it significantly slowed run-webkit-tests' startup
> time because WPT has a workflow to find all tests & their expected
> results upfront before any tests could run.

The patch uses html5lib (via BeautifulSoup), which is exactly what WPT, and our 
importer use to find the ref tests.

We don't find references up-front; only when running each test. This patch does 
add some overhead for parsing each test file,
which I measured to be about 1-2 sec on a directory which took 30s to run. I 
think this slight slowdown is worthwhile (we could
probably eliminate it with some webkitpy optimizations).

>> 
>>   - Adding link elements itself may affect tests (all W3C tests are
>>   required to have link elements at the moment)
>> 
>> I haven't seen this be an issue.
> 
> Another issue is that if you were to modify a test which happens to be
> also used as a reference or a mismatch result (worse) for some other
> test, then you may not notice that without inspecting every other test
> in existence.

EWS will tell you. Also, generally a file won't act as both a test and a 
reference; I don't see us deviating from
our current "-expected.html" naming conventions. BTW, you don't *have* to add a 
 tag; we'll still fall
back to the current search behavior. If you have both, then webkitpy will warn.

> 
>>   - Hard to understand relationship between files. e.g. if we want to
>>   figure out which tests use ref.html, we must look at all test files
>> 
>> This is true, but I don't really see it being a problem in practice.
> 
> This definitely is an issue. It's possible WPT has improved things but
> we've definitely had an experience where tests were used as reference
> for other tests, etc... and having to think about this issue every
> time I touch test drove me nuts.

Do you have any examples? If this does happen in WPT, we should discourage it 
(and can fix it via PRs).

Generally references live in a resources/ or references/ subdirectory, or have 
"-ref" in the name.

> 
>> What I have seen is us importing CSS 2.1 tests that have foo.html and 
>> foo-ref.html, and treating foo-ref.html as a test so generating 
>> foo-expected.txt and foo-ref-expected.txt. That seems worse.
> 
> Seems like we can treat "-ref" as a special suffix like we already do
> with support directory and resources directory.

All that works now.

> 
>> So now that WPT is heavily invested in  I think we should follow 
>> suite. It will simplify WPT import, and reduced the number of cloned 
>> -expected.html files significantly.
> 
> I really don't want to deal with tests being used as references for
> other tests. I'm okay with this approach if we forbid that.

I'm OK with that (enforced by code review unless we see the need for tooling).

Simon

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

[webkit-dev] Supporting for finding ref tests

[Simon Fraser]

I'd like to land a patch to support finding test references via :
https://bugs.webkit.org/show_bug.cgi?id=203784 


There has been some discussion about this in the past:
https://lists.webkit.org/pipermail/webkit-dev/2011-November/018470.html 


But I think the benefits outweigh the drawbacks. As that mail states:
> *Link element approach*
> Pros:
> 
>- Can reuse same ref. file for multiple tests
Still true.
>- Can have multiple ref. files for single test
True but no something that we support, and I haven't see any WPT use this (our 
importer throws an error if it sees this)
>- Information is self-contained in the test file
Still true
>- We may get away with test suite build step
It certainly simplifies WPT test import.
Currently importing some CSS suites (e.g. css-backgrounds) results in broken 
-expected.html files because copying them breaks references to sub resources.
> (It turns out that we can't convert W3C ref tests to use WebKit conventions
> due to the first two points.)
We're doing this much more now, and the "multiple references" point is moot, so 
I think we can import WPT tests mostly as-is.
> 
> Cons:
> 
>- Requires us modifying each port's DRT to support this format
No, it just requires webkitpy hacking which I've done in the patch.
>- Adding link elements itself may affect tests (all W3C tests are
>required to have link elements at the moment)
I haven't seen this be an issue.
>- Hard to understand relationship between files. e.g. if we want to
>figure out which tests use ref.html, we must look at all test files
This is true, but I don't really see it being a problem in practice. What I 
have seen is us importing CSS 2.1 tests that have foo.html and foo-ref.html, 
and treating foo-ref.html as a test so generating foo-expected.txt and 
foo-ref-expected.txt. That seems worse.
>- Other browser vendors (Firefox and Opera) prefer manifest file approach
This is no longer true. "reftest.list" files are deprecated 
(webkit.org/b/203783, https://github.com/web-platform-tests/wpt/issues/20060 
).
So now that WPT is heavily invested in  I think we should follow 
suite. It will simplify WPT import, and reduced the number of cloned 
-expected.html files significantly.
Simon

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

Re: [webkit-dev] Lazy loading

[Simon Fraser]

> 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 about the next steps.
> 
> One thing left to do for sure is cleaning up/adding tests. For one there are 
> tests in http/tests/lazyload which can just be WPT tests, so I'll work in 
> this area for sure. As usual, while adding new tests bugs may show up and 
> more patches will be needed.
> 
> Another possible task is implementing metadata fetch, but it makes the code 
> more complex and chromium has backtracked from it.
> 
> Changing the behavior of loading=auto to make lazy loading the default seems 
> risky and should possibly only be done when lazy image loading is deemed 
> stable enough.

Agreed. Is there any compat data from other browsers?

> 
> 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 
> for it.
> 
> A related task is implementing lazy loading for iframe's, I took a quick look 
> and this looks like similar work to lazy image loading, but should be much 
> easier to implement now the building blocks are there.

I think this one has the highest potential to give big page loading gains, 
especially if we can get this one turned on by default (or maybe for 
cross-origin frames), so I suggest working on this.

Do we have any data from other browsers to know whether enabling lazy-loading 
iframe by default breaks the web?

> 
> Finally there is the task of setting threshold viewport distance values for 
> triggering deferred loads. I only have access to iOS simulator, so I wonder 
> if that is something Apple could help with?

I would be happy to help.

> 
> I do not have a strong preference among these tasks. Thoughts?
> Cheers,
> 
> Rob.
> 
> P.S: I intend to attend the WebKit Contributors meeting, so feel free to chat 
> with me there about lazy loading.

See you there!

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

Re: [webkit-dev] Unprefix -webkit-clip-path

[Simon Fraser]

I support unprefixing!

Simon

> On Oct 28, 2019, at 11:55 AM, Dirk Schulze  wrote:
> 
> Hi,
> 
> I didn’t hear any objections to unprefix -webkit-clip-path. Unless no new 
> concerns get raised, I’ll land the patch later this week.
> 
> Greetings,
> Dirk
> 
>> On 21. Oct 2019, at 13:01, Dirk Schulze > > wrote:
>> 
>> Hi,
>> 
>> I’d like to unprefix the -webkit-clip-path implementation.
>> 
>> The spec for clip-path is CSS Masking
>> ED: https://drafts.fxtf.org/css-masking-1/ 
>> 
>> CR: https://www.w3.org/TR/css-masking-1/ 
>> 
>> 
>> Currently, WebKit has 2 independent(!) implementations:
>> 1. The SVG clip-path CSS property that only applies to SVG elements and only 
>> allows referencing of clipPath SVG elements.
>> 2. The -webkit-clip-path CSS property that started with basic shapes (CSS 
>> shape functions) and added support for referencing of clipPath SVG elements. 
>> While initially it just worked on HTML elements it covers SVG elements as 
>> well now.
>> 
>> Therefore, the -webkit-clip-path implementation is a superset of the 
>> clip-path implementation and I intend to replace the latter with the former 
>> entirely. -webkit-clip-path will get an alias for clip-path.
>> 
>> “Unprefixing" clip-path (ship with newly supported features) has been in 
>> discussion at Mozilla as well:
>> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/clip-path%7Csort:date/mozilla.dev.platform/X29xtxQRPJc/4k1avpSxDQAJ
>>  
>> 
>> https://groups.google.com/forum/#!msg/mozilla.dev.platform/RM5O36MZ4x4/mU0cOsT7EgAJ
>>  
>> 
>> 
>> Main concern was the confusion around the path() CSS shape function which 
>> was the only CSS shape function not defined in CSS Shapes Level 1 (but 
>> defined in the Motion spec). As a result, the CSS WG moved the function to 
>> CSS Shapes Level 1 which should address the concerns of the Mozilla 
>> community.
>> 
>> The work happens here: https://bugs.webkit.org/show_bug.cgi?id=187888 
>> 
>> 
>> There are a few low-priority issues left (see master bug 
>> https://bugs.webkit.org/show_bug.cgi?id=126207 
>> ). They should not have a 
>> real-world affect though as they are corner cases.
>> 
>> Please raise your concerns here on the mailing list or send your support.
>> 
>> Thanks a lot,
>> Dirk Schulze
> 
> ___
> 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] What to do about scroll anchoring?

[Simon Fraser]

> On Sep 27, 2019, at 10:08 PM, Emilio Cobos Álvarez  wrote:
> 
> And, to be clear, we _can_ fix these compat issues, some way or another.
> 
> One thought is to limit the amount of scroll adjustments without user 
> scrolling or stuff like that, which would prevent the "you get stuck on the 
> page".
> 
> Making anchoring opt-in rather than opt-out is another option, but that 
> defeats most of the purpose of the feature, I guess.
> 
> See also some of the Chromium docs on the compat issues they found[1] and how 
> were they trying to fix them before adding the "layout-affecting-property 
> changed" heuristic, which is what is on the spec right now and what they 
> implement.
> 
> I just think that these are very hacky heuristics that are just going to 
> bring a lot of compat pain and developer confusion.
> 
> It doesn't help that all these things can break or not depending on the speed 
> at which the user scrolls, the amount of scroll events that the user 
> dispatches, the timing of these events relative to other events, etc…


I expressed my main issue with scroll anchoring at the F2F, which is that it’s 
an on-by-default behavior that is making up for bad web authoring, and is 
harmful if only implemented by a subset of browsers.

I would support removing it entirely, or having it be opt-in.

Simon

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

Re: [webkit-dev] Planned EWS improvements

[Simon Fraser]

> On Sep 27, 2019, at 10:27 PM, Konstantin Tokarev  wrote:
> 
> 27.09.2019, 08:15, "Simon Fraser" :
>>> On Sep 27, 2019, at 3:27 AM, Aakash Jain  wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> I have been making number of improvements to EWS. I also have various 
>>> planned improvements to EWS. I wanted to reach out to you guys to see if 
>>> anyone
>> 
>> Not everyone on this list is a guy.
> 
> FWIW, plural form of "guy" is often used as gender-neutral vocative, see e.g. 
> [1,2]
> 
> [1] https://www.merriam-webster.com/dictionary/guy
> [2] https://dictionary.cambridge.org/us/dictionary/english/guy

I apologize to Aakash for calling this out publicly.

However, ‘guys’ clearly has gender-specific roots, and to my ears, it sounds 
male-biased, There are many other words that can be used in its place which are 
more inclusive (“folks”, “everyone”, “you all” etc).

Simon

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

Re: [webkit-dev] Planned EWS improvements

[Simon Fraser]

> On Sep 27, 2019, at 3:27 AM, Aakash Jain  wrote:
> 
> Hi Everyone,
> 
> I have been making number of improvements to EWS. I also have various planned 
> improvements to EWS. I wanted to reach out to you guys to see if anyone

Not everyone on this list is a guy.

> wants me to prioritize any particular improvement(s). If there is any 
> improvement which you want to see and is not listed below, please feel free 
> to let me know. Also most of the queues have been transitioned from old to 
> new EWS and I am working on the remaining ones (jsc, windows and 
> commit-queue).
> 
> Here is the list of improvements (in no particular order):
> 
> 1) Develop a webpage showing summary of EWS builds for a patch. This page 
> would provide the summary of important build-steps, high-level details about 
> the failure (e.g.: name of the tests which failed, or possibly relevant build 
> failure logs), and include link(s) to the Buildbot page(s). This page will 
> open on clicking the status-bubbles (and would be replacement of old EWS 
> status page like https://webkit-queues.webkit.org/patch/379563/win-ews 
> ). Currently clicking 
> the status-bubble opens the Buildbot build page, which contains a lot of 
> infrastructure details, and probably is information-overload for many 
> engineers, so this summary page should help with that. 
> https://webkit.org/b/197522 
> 
> 2) Redesign status-bubble tooltip to include more detailed information about 
> failures (e.g.: each test failure name along-with url to flakiness dashboard, 
> and url to complete results.html file, as suggested by David Kilzer in 
> https://lists.webkit.org/pipermail/webkit-dev/2019-September/030799.html 
> ). 
> We should also add the tooltip support for iPad/iPhone 
> https://webkit.org/b/201940 

#1

> 
> 3) Add a way to retry a patch in EWS. This would allow engineers to confirm 
> that the failures indicated by EWS aren't flaky/incorrect. Maybe a good place 
> to add the 'retry' button would be the status-bubble's tool-tip (visible only 
> if the bubble is red) https://webkit.org/b/196599 
> 
#2

> 
> 4) Parse the relevant build failure message from build logs (and display in 
> summary page) https://webkit.org/b/201941 
> 
> 5) Style failure should be displayed in-line on the review page along-with 
> the code, just like the reviewer's comments https://webkit.org/b/202252 
> 
> 
> 6) Add more test-suites to EWS (e.g.: LLDB tests, resultsdbpy tests) 
> https://webkit.org/b/189206 , 
> https://webkit.org/b/201928 
> 
> 7) Add commit-queue support for security bugs https://webkit.org/b/201939 
> 
> 
> 8) API tests should upload crashlogs https://webkit.org/b/201929 
> 

Simon

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

Re: [webkit-dev] [webkit-help] ResizeObserver

[Simon Fraser]

Thanks for all you work on this, Cathie!

Simon

> On Apr 1, 2019, at 7:27 AM, cathiechen  wrote:
> 
> Hi,
> 
> The initial support for ResizeObserver has been landed.
> 
> For more details: https://bugs.webkit.org/show_bug.cgi?id=157743
> 
> Thanks:)
> 
> 
> Cathie Chen
> 
> On 1/23/19 9:54 PM, Antonio Gomes wrote:
>> moved to webkit-dev, bcc'ing webkit-help
>> +Cathie
>> 
>> I know Cathie is working on it. Cathie, feel free to provide a status update.
>> 
>> On Tue, Jan 22, 2019 at 4:06 PM Eric Gorr  wrote:
>>> Will do.
>>> 
>>> Might be worth mentioning this feature on https://webkit.org/status ... ?
>>> 
>>> On Tue, Jan 22, 2019 at 2:57 PM Simon Fraser  wrote:
>>>> On Jan 22, 2019, at 11:46 AM, Eric Gorr  wrote:
>>>> 
>>>> I was just wondering when we might expect the ResizeObserver ( 
>>>> https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver ) to be 
>>>> supported in webkit ?
>>>> 
>>>> 
>>>> Please express your interest on 
>>>> https://bugs.webkit.org/show_bug.cgi?id=157743
>>>> 
>>>> I don't' have anything to share about a schedule for this feature. As 
>>>> always, we're taking patches!
>>>> 
>>>> Simon
>>>> 
>>> ___
>>> webkit-help mailing list
>>> webkit-h...@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-help
> ___
> 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] Style guideline on initializing non-POD types via member initialization

[Simon Fraser]

> On Mar 14, 2019, at 1:06 PM, Filip Pizlo  wrote:
> 
> I like to draw this distinction: is the initializer a constant?
> 
> It’s not a constant if it relies on arguments to the constructor. “This” is 
> an argument to the constructor. 
> 
> It’s also not a constant if it involves reading the heap. 
> 
> So, like you, I would want to see this code done in the constructor. But I’m 
> not sure that my general rule is the same as everyone’s. 

This seems like a reasonable proposal to me: only use initializers when their 
input is constant data.

Any objections?

Simon

> 
> -Filip
> 
>> On Mar 14, 2019, at 12:59 PM, Simon Fraser  wrote:
>> 
>> I've seen some code recently that initializes non-POD members via 
>> initializers. For example, SVGAElement has:
>> 
>>   AttributeOwnerProxy m_attributeOwnerProxy { *this };
>> 
>> I find this a little disorientating, and would normally expect to see this 
>> in the constructor as m_attributeOwnerProxy(*this), as it makes it easier to 
>> find places to set breakpoints, and the ordering of initialization is easier 
>> to see.
>> 
>> Are people OK with this pattern, or should we discourage it via the style 
>> guidelines (and style checker)?
>> 
>> Simon
>> 
>> ___
>> 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] Style guideline on initializing non-POD types via member initialization

[Simon Fraser]

I've seen some code recently that initializes non-POD members via initializers. 
For example, SVGAElement has:

AttributeOwnerProxy m_attributeOwnerProxy { *this };

I find this a little disorientating, and would normally expect to see this in 
the constructor as m_attributeOwnerProxy(*this), as it makes it easier to find 
places to set breakpoints, and the ordering of initialization is easier to see.

Are people OK with this pattern, or should we discourage it via the style 
guidelines (and style checker)?

Simon

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

Re: [webkit-dev] Reminder regarding formatting uint64_t

[Simon Fraser]

Or use LOG_WITH_STREAM() where I presume << pageID() << does the right thing.

We’d need some new RELEASE_LOG_ macros for that.

Simon

> On Feb 27, 2019, at 2:47 PM, Ryosuke Niwa  wrote:
> 
> We should probably stop using these formatting strings in favor of makeString 
> by making *LOG* functions to use makeString behind the scene.
> 
> See https://trac.webkit.org/changeset/242014 
>  for example.
> 
> - R. Niwa
> 
> On Wed, Feb 27, 2019 at 2:36 PM Michael Catanzaro  > wrote:
> Hi,
> 
> For the past several years, I've been regularly fixing -Wformat 
> warnings that look like this:
> 
> ../../Source/WebKit/WebProcess/WebPage/WebPage.cpp:3148:46: warning: 
> format ‘%llu’ expects argument of type ‘long long unsigned 
> int’, but argument 6 has type ‘uint64_t’ {aka ‘long unsigned 
> int’} [-Wformat=]
>  RELEASE_LOG_ERROR(ProcessSuspension, "%p - WebPage 
> (PageID=%llu) - LayerTreeFreezeReason::ProcessSuspended was set when 
> removing LayerTreeFreezeReason::PageTransition; current reasons are %d",
> 
> ^~
>  this, m_pageID, m_LayerTreeFreezeReasons.toRaw());
>
> 
> Problem is that uint64_t is long long unsigned int on Mac, but only 
> long unsigned int on Linux. It can't be printed with %llu, so please 
> use PRIu64 instead. E.g.:
> 
> LOG("%llu", pageID); // wrong
> LOG("%" PRIu64, pageID); // correct
> 
> This is good to keep in mind for any sized integer types, but uint64_t 
> in particular since this is what causes problems for us in practice.
> 
> Thanks,
> 
> Michael
> 
> ___
> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Is anyone maintaining Nicosia scrolling code?

[Simon Fraser]

There’s a bunch of code in Source/WebCore/page/scrolling/nicosia/ that I keep 
breaking with scrolling tree refactoring. Most of it it stubs. Is anyone 
maintaining this code, because it obviously doesn’t work, and I’d like to 
remove the maintenance burden.

Simon

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

Re: [webkit-dev] Moving to Git

[Simon Fraser]

> On Feb 21, 2019, at 12:18 AM, Bug Tracker 
>  wrote:
> 
> Thank you all very much for your help! I really appreciate it. :-)
> 
> P.S.: I decided to start learning git-svn.

https://trac.webkit.org/wiki/UsingGitWithWebKit 
 has the information you need.

Simon

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

Re: [webkit-dev] Moving to Git

[Simon Fraser]

Are you a WebKit developer? I can't tell from your email.

Simon

> On Feb 20, 2019, at 8:27 AM, Bug Tracker 
>  wrote:
> 
> Hi,
> 
> I was curious about the status of the proposal for migrating from SVN to Git 
> (https://trac.webkit.org/wiki/Moving%20to%20Git 
> ).
> 
> The relevant page on the Trac wiki hasn't been updated for over 5 years and 
> since then Git has become much more popular (the de facto standard for new 
> projects, more or less), while:
> SVN support is diminishing (e.g. in Xcode).
> Git support on Windows is much better than 5 years ago.
> It's difficult to find free robust SVN clients / UIs, unlike the plethora of 
> options available for Git.
> Most young and relatively new developers (with less than 10 years of 
> experience, like myself) are much more comfortable with Git and maybe have 
> not even used SVN before, so moving to Git could encourage more users and 
> contributors.
> 
> Is there any progress in this direction?
> 
> Thank you, in advance!
> ___
> 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] Code Style: Opinion on returning void

[Simon Fraser]

I find it mind bending. It makes me wonder if the author made a coding error.

Simon

> On Feb 20, 2019, at 7:48 AM, Daniel Bates  wrote:
> 
> Thanks for the opinion!
> 
> Dan
> 
> On Feb 20, 2019, at 7:26 AM, Saam Barati  > wrote:
> 
>> I prefer it as well.
>> 
>> - Saam
>> 
>> On Feb 20, 2019, at 6:58 AM, Chris Dumez > > wrote:
>> 
>>> I also prefer allowed returning void. 
>>> 
>>> Chris Dumez
>>> 
>>> On Feb 19, 2019, at 10:35 PM, Daniel Bates >> > wrote:
>>> 
 
 
 On Feb 19, 2019, at 9:42 PM, Ryosuke Niwa >>> > wrote:
 
> On Tue, Feb 19, 2019 at 8:59 PM Daniel Bates  > wrote:
> > On Feb 7, 2019, at 12:47 PM, Daniel Bates  > > wrote:
> >
> > Hi all,
> >
> > Something bothers me about code like:
> >
> > void f();
> > void g()
> > {
> > if (...)
> > return f();
> > return f();
> > }
> >
> > I prefer:
> >
> > void g()
> > {
> > if (...) {
> > f();
> > return
> > }
> > f();
> > }
> >
> Based on the responses it seems there is sufficient leaning to codify
> the latter style.
> 
> I don't think there is a sufficient consensus as far as I can tell. Geoff
 
 I didn't get this from Geoff's remark. Geoff wrote:
 
 ***“return f()” when f returns void is a bit mind bending.***
 Don't want to put words in Geoff's mouth. So, Geoff can you please 
 confirm: for the former style, for the latter style, no strong opinion.
 
> and Alex both expressed preferences for being able to return void,
 
 I got this from Alex's message
 
> and Saam pointed out that there is a lot of existing code which does this.
 
 I did not get this. He wrote emphasis mine:
 
 I've definitely done this in JSC. ***I don't think it's super common***, 
 but I've also seen code in JSC not written by me that also does this.
 
> Zalan also said he does this in his layout code.
 
 I did not get this, quoting, emphasis mine:
 
 I use this idiom too in the layout code. I guess I just prefer a more
 compact code.
 ***(I don't feel too strongly about it though)***
 
 By the way, you even acknowledged that "WebKit ... tend[s] to have a 
 separate return.". So, I inferred you were okay with it. But from this 
 email I am no longer sure what your position is. Please state it clearly.
 
> - R. Niwa
> 
 ___
 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 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] Experimental features review

[Simon Fraser]

> On Feb 13, 2019, at 11:32 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> Last year, we cleaned up experimental features in WebPreferences.yaml to 
> ensure no experimental features were enabled by default. Since then we have 
> regressed a bit when enabling cool new web features. :) Currently we have 12 
> offenders, listed below. Most likely, the category: experimental line should 
> be removed from these features. Alternatively, the defaultValue should be 
> changed to either false or DEFAULT_EXPERIMENTAL_FEATURES_ENABLED (or 
> something depending on that).
> 
> If you know about any of these settings, please keep reading and help decide 
> what to do with them:
> 
> IntersectionObserverEnabled
> VisualViewportAPIEnabled

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 regression testing, but is the policy now to move them back to Debug 
features at this stage?

Simon

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

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

[Simon Fraser]

> 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 term “atomic operations”.
> 
> Well there were two other developers in the thread Ryosuke linked to who made 
> the exact same mistake as me, so I do think the current name is problematic. 
> A change wouldn't need to be drastic, though. I think suggestions from the 
> old thread like "StringAtom" or "AtomString" would be unproblematic. The 
> problem is the specific word "atomic" carries an expectation that the object 
> be safe to access concurrently across threads without locks; I think that 
> expectation doesn't exist if not for the "ic" at the end.
> 
> FWIW I've only ever heard the "interned string" terminology prior to now.

SingletonString?
UniquedString?

Simon

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

Re: [webkit-dev] Clarifying feature flags

[Simon Fraser]

> On Nov 5, 2018, at 6:01 PM, don.olmst...@sony.com wrote:
>  
> I'm really interested in other people's thoughts on this.
>  

Agreed that this would be great to clean up. We’ve accrued a lot of junk in 
this area.

Simon



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

Re: [webkit-dev] dump-class-layout script not working

[Simon Fraser]

I assume you've actually done a debug build?

Your command line works for me:

 100$ $ ./Tools/Scripts/dump-class-layout --architecture=x86_64 -c Debug 
JavaScriptCore JSString
  +0 < 24> JSString
  +0 <  8> JSC::JSCell JSC::JSCell
  +0 <  1> JSC::HeapCell JSC::HeapCell
  +0 <  4>   JSC::StructureID m_structureID
  +4 <  1>   JSC::IndexingType m_indexingTypeAndMisc
  +5 <  1>   JSC::JSType m_type
  +6 <  1>   JSC::TypeInfo::InlineTypeFlags m_flags
  +7 <  1>   JSC::CellState m_cellState
  +8 <  4>   unsigned int m_length
 +12 <  2>   uint16_t m_flags
 +14 <  2>   
 +16 <  8> WTF::String m_value
 +16 <  8> WTF::RefPtr > m_impl
 +16 <  8>   WTF::DumbPtrTraits::StorageType m_ptr
Total byte size: 24
Total pad bytes: 2
Padding percentage: 8.33 %

BTW you should never work on class layouts in debug builds, since they may be 
different from shipping.

There are some unit tests for dump-class-layout (they used to be run as part of 
webkitpy tests, but I think Dan changed that?). Do all the tests pass for you?

Simon

> On Nov 5, 2018, at 4:02 PM, Frank Jaeger  wrote:
> 
> Hi Simon, thanks for your help. I am running the script on macOS Mojave 10.14 
> and I'm pretty sure I have the lldb python bindings installed. Or otherwise 
> it should fail when importing them at the beginning of the script, right? 
> From what I understood by reading the script's code, it is directly calling 
> into the lldb binding to dump the class layout, and it's failing inside. 
> 
> As I've said before, the error it gives me implies that the provided 
> framework/class pair has not been found in the image, even though I am sure 
> that the pair is valid and found in the image (e.g. JSC::JSString).
> Da: simon.fra...@apple.com  per conto di Simon Fraser 
> 
> Inviato: lunedì 5 novembre 2018 14:17
> A: Frank Jaeger
> Cc: webkit-dev@lists.webkit.org
> Oggetto: Re: [webkit-dev] dump-class-layout script not working
>  
> Dump-class-layout uses the lldb python bindings. Maybe those are not 
> available on your platform?
> 
> I think we’ve only ever tried it on macOS. What platform are you trying on?
> 
> Simon
> 
>> On Nov 4, 2018, at 12:43 PM, Frank Jaeger > <mailto:fjaege...@outlook.com>> wrote:
>> 
>> Hello. First of all I'm really sorry if this is the wrong mailing list to 
>> post to, webkit-help would have probably been better but it doesn't seem 
>> very active.
>> 
>> I run into some problems while trying to use the dump-class-layout script 
>> (found in Tools/Scripts/). I built WebKit using the build-webkit script with 
>> the --debug flag.
>> 
>> After building, I tried to run the dump-class-layout script with the 
>> following arguments:
>> 
>> ./Tools/Scripts/dump-class-layout --architecture=x86_64 -c Debug 
>> JavaScriptCore JSString
>> 
>> I also tried different frameworks and classes. The script always fails 
>> telling me that "no type matches x in y" where x is the class name I used in 
>> the run and y is the framework name.
>> 
>> Why is this happening? The script is correctly finding the built and 
>> symbolicated framework image, so why is it not working properly? Thanks in 
>> advance.
>> ___
>> 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] dump-class-layout script not working

[Simon Fraser]

Dump-class-layout uses the lldb python bindings. Maybe those are not available 
on your platform?

I think we’ve only ever tried it on macOS. What platform are you trying on?

Simon

> On Nov 4, 2018, at 12:43 PM, Frank Jaeger  wrote:
> 
> Hello. First of all I'm really sorry if this is the wrong mailing list to 
> post to, webkit-help would have probably been better but it doesn't seem very 
> active.
> 
> I run into some problems while trying to use the dump-class-layout script 
> (found in Tools/Scripts/). I built WebKit using the build-webkit script with 
> the --debug flag.
> 
> After building, I tried to run the dump-class-layout script with the 
> following arguments:
> 
> ./Tools/Scripts/dump-class-layout --architecture=x86_64 -c Debug 
> JavaScriptCore JSString
> 
> I also tried different frameworks and classes. The script always fails 
> telling me that "no type matches x in y" where x is the class name I used in 
> the run and y is the framework name.
> 
> Why is this happening? The script is correctly finding the built and 
> symbolicated framework image, so why is it not working properly? Thanks in 
> advance.
> ___
> 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] Does any platform set acceleratedCompositingForOverflowScrollEnabled?

[Simon Fraser]

I'd like to remove the code related to 
acceleratedCompositingForOverflowScrollEnabled; it complicates RenderLayer 
z-order code, and is not sufficient for our desires of being able to accelerate 
all overflow-scrolls, not just those that can be made stacking context without 
affecting z-order.

Simon

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

[webkit-dev] Unified sources have broken our #include hygiene

[Simon Fraser]

Unified sources allow you to get away without #including all the files you need 
in a .cpp file, because some earlier file in the group has probably already 
included them for you.

This means that when you add a new file to the build, and the unified sources 
get shuffled around, you end up with a long list of build breakages, some 
platform-specific, that you can only fix by repeating EWS trials. Here's an 
example: https://bugs.webkit.org/show_bug.cgi?id=189223. That patch added on 
new file in Source/WebCore/rendering, which required unrelated #include changes 
in at least:

rendering/RenderBlockFlow.cpp:
rendering/RenderFrame.cpp:
rendering/RenderImage.cpp:

How can we solve this? Should we have an EWS that builds non-unified? Can we 
somehow have the style checker do #include enforcement?

Simon

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

[webkit-dev] Introducing the GC Heap Inspector

[Simon Fraser]

Yesterday I landed support for a way to dump and inspect a GC heap snapshot. 
This work was motivated by the need to have easier ways to debug Document 
leaks, especially those involving GC.

The basic idea is that you do some steps that trigger a document leak, then get 
a heap dump. Typically this involves loading the test page, then navigating 
away, clearing caches, triggering a GC and capturing a snapshot. The snapshot 
is dumped as JSON file in /tmp; you can then drag this snapshot into the view 
which lives in Tools/GCHeapInspector, and see why objects are referencing the 
leaked document.

This is documented on https://trac.webkit.org/wiki/Inspecting%20the%20GC%20heap 
 

Let me know if you have questions. Improvements to the inspector page are 
welcomed.

Simon

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

Re: [webkit-dev] CSS Logical Properties and Values

[Simon Fraser]

> On Aug 21, 2018, at 5:56 PM, Oriol Brufau  wrote:
> 
> I have written a patch for adding logical shorthand properties. However,
> I'm not much sure about how I can implement them behind a flag.
> 
> I tried hiding them behind a run-time flag. But unlike Blink, it seems I
> can't do this easily in CSSProperties.json.
> Instead, I wrapped the code added in CSSPropertyParser.cpp and
> CSSComputedStyleDeclaration.cpp inside conditionals with
> `RuntimeEnabledFeatures::sharedFeatures().cssLogicalEnabled()`.
> This disables the effects of the properties, but doesn't prevent them
> from being exposed via `prop in element.style`.
> 
> So I will try a compile flag instead. But there are some Web Platform
> Tests for the new properties, and I would like them to pass.
> Is there a way to tell the testbot to compile with this flag?
> 
> I would appreciate some guidance on the preferred way of doing this.

The way we do this this now is via flags on CSSParserContext. See 
"conicGradientsEnabled" for an example.

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

Re: [webkit-dev] CSS Logical Properties and Values

[Simon Fraser]

This plan sounds great! Thanks for working on this.

Simon

> On Aug 8, 2018, at 9:53 AM, Oriol Brufau  wrote:
> 
> https://drafts.csswg.org/css-logical-1/ 
>  defines properties and values to 
> control layout
> through logical, rather than physical, direction and dimension mappings.
>  
> I have been working on implementing this in Blink, now I'm starting with 
> WebKit.
>  
> Various properties are already supported but using non-standard names with a 
> -webkit-
> prefix. The standard properties have already been shipped in Firefox and 
> Blink, so
> I will start with implementing them and converting the prefixed ones into 
> aliases.
> This will happen in https://bugs.webkit.org/show_bug.cgi?id=188386 
> , the specific list
> of properties is:
>  * margin-{block,inline}-{start,end}
>  * padding-{block,inline}-{start,end}
>  * border-{block,inline}-{start,end}
>  * border-{block,inline}-{start,end}-{width,style,color}
>  * {block,inline}-size
>  * {min,max}-{block,inline}-size
> See Blink's Intent to Ship: 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tkN-r119eNc 
> 
>  
> After this I will continue with the remaining flow-relative box model 
> properties and the
> flow-relative values for existing properties:
>  * margin-{block,inline}
>  * padding-{block,inline}
>  * border-{block,inline}
>  * border-{block,inline}-{width,style,color}
>  * float: inline-{start,end}
>  * clear: inline-{start,end}
>  * resize: {block,inline}
> This will be behind an experimental flag, like it's being done in Blink. 
> Firefox shipped some.
> See Blink's Intent to Implement: 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/48OwfwZrbvI/A1XZFGkzAwAJ
>  
> 
>  
> I would like to get your feedback and comments about this topic, if you are 
> fine with the plan
> we will start to land patches next week.
> ___
> 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 WebKit style to better accommodate accepted Obj-C block syntax

[Simon Fraser]

+1 for no space between ^ and {

Simon

> On Oct 3, 2017, at 4:51 PM, Megan Gardner  wrote:
> 
> 
> Currently, the webkit style checker does not allow ^{ at the beginning of 
> Obj-C blocks. It demands that there is a space between the ^ and the {. This 
> is not how obj-c code is usually styled, and there is plenty of code already 
> in webkit that is formatted with the carrot and and brace together. This 
> seems to have been changed recently with 
> https://bugs.webkit.org/show_bug.cgi?id=161247. I think we should revisit 
> this, as ^ { is much less common that ^{ and is canonical style in pure Obj-C.
> 
> Megan Gardner
> ___
> 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] web-bluetooth

[Simon Fraser]

> On Sep 27, 2017, at 10:47 AM, Jonathan Ruiz  
> wrote:
> 
> 
> Hi All,
> 
> is there any plan to implement web-bluetooth or is it completely discarded?
> 

>

Simon

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

[webkit-dev] Breakpoints in #included .cpp files [Was: 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)]

[Simon Fraser]

> On Aug 28, 2017, at 9:46 PM, Geoffrey Garen  wrote:
> 
>> The line numbers and filenames will be total nonsense if we just concatenate 
>> multiple source files together. But that's very easy to fix if the script 
>> that concatenates the sources also adds a #line statement between "files" to 
>> change the filename and reset the line number to 1. See 
>> https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html (I suspect it will work 
>> just fine for Clang as well).
> 
> Our plan is to use #include. That has worked in the past.

This should be tested before proceeding with the unified build plan. This has 
certainly not always worked in the past (for Apple folks, see 
rdar://problem/16751849 and rdar://problem/16829492, which is still open).

Non-working breakpoints would be a show-stopper for many.

Simon

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

Re: [webkit-dev] Fail to execute setup-git-clone

[Simon Fraser]

I would suggest checking out WebKit into a directory that doesn't have any 
non-ASCII characters in the path (sorry!).

Simon

> On Aug 15, 2017, at 6:01 PM, 于晶彬  wrote:
> 
> Hello,
> I'm trying to configure git to track the Subversion repository, using the 
> command shown in the webkit.org , but there seems to be 
> some errors, as shown in http://paste.ubuntu.com/25322396/ 
>  What should I do next?
> 
> Python Version:
> 2.7.10
> 
> MacOS Version:
> MacOS Sierra 10.12.6 (16G29)
> 
> git Version:
> 2.13.1
> 
> Subversion Version:
> 1.9.7 (r1800392)
> 
> Thanks!

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

Re: [webkit-dev] Intent to remove: ENABLE_PROXIMITY_EVENTS

[Simon Fraser]

> On Aug 11, 2017, at 3:31 PM, Simon Fraser  wrote:
> 
> Does any platform care about the code protected by ENABLE_PROXIMITY_EVENTS? 
> It was added in 2015 via webkit.org/b/102658 but as far as I can tell, no 
> platform uses it.

Removal bug is https://bugs.webkit.org/show_bug.cgi?id=175545.

Simon

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

Re: [webkit-dev] Intent to remove: ENABLE_REQUEST_AUTOCOMPLETE

[Simon Fraser]

> On Aug 11, 2017, at 4:51 PM, Simon Fraser  wrote:
> 
> ENABLE_REQUEST_AUTOCOMPLETE and its AutocompleteErrorEvent was added via 
> webkit.org/b/105568 for https://wiki.whatwg.org/wiki/RequestAutocomplete but 
> as far as I can see that never made it into the HTML spec, and the code 
> wasn't enabled anywhere.
> 
> Speak up if you don't want this code removed.

Removal bug is https://bugs.webkit.org/show_bug.cgi?id=175504

Simon

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

Re: [webkit-dev] Proposal to remove: VIEW_MODE_CSS_MEDIA

[Simon Fraser]

Thanks.

Removal bug is https://bugs.webkit.org/show_bug.cgi?id=175557.

Simon

> On Aug 12, 2017, at 8:52 AM, Michael Catanzaro  wrote:
> 
> That's our old deleted API. We don't expose that API anymore so that won't be 
> a problem for us.
> 
> Michael
> 

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

[webkit-dev] Intent to remove: ENABLE_REQUEST_AUTOCOMPLETE

[Simon Fraser]

ENABLE_REQUEST_AUTOCOMPLETE and its AutocompleteErrorEvent was added via 
webkit.org/b/105568 for https://wiki.whatwg.org/wiki/RequestAutocomplete but as 
far as I can see that never made it into the HTML spec, and the code wasn't 
enabled anywhere.

Speak up if you don't want this code removed.

Simon

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

[webkit-dev] Proposal to remove: VIEW_MODE_CSS_MEDIA

[Simon Fraser]

VIEW_MODE_CSS_MEDIA wraps an implementation of CSS View Mode 
(https://dev.w3.org/2006/waf/widgets-vmmf/#the--view-mode--media-feature) which 
is used by Gtk and exposed through their API 
,
 but is that or any other port still interested in this feature?

Simon

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

[webkit-dev] Intent to remove: ENABLE_PROXIMITY_EVENTS

[Simon Fraser]

Does any platform care about the code protected by ENABLE_PROXIMITY_EVENTS? It 
was added in 2015 via webkit.org/b/102658 but as far as I can tell, no platform 
uses it.

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

Re: [webkit-dev] Another WPT bite

[Simon Fraser]

> On May 12, 2017, at 12:04 PM, Alexey Proskuryakov  wrote:
> 
> 
>> 12 мая 2017 г., в 11:52, Ben Kelly > > написал(а):
>> 
>> On Fri, May 12, 2017 at 2:26 PM, Rick Byers > > wrote:
>> On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov > > wrote:
>> Since imported WPT tests are very flaky, and are not necessarily written to 
>> defend against important regressions, investigating issues with them is 
>> relatively lower priority than investigating issues observed with WebKit 
>> tests. So I would recommend not mixing tests for WebKit regressions with WPT 
>> tests - if your test eventually ends up in LayoutTests/imported, it will 
>> become a lot less effective.
>> 
>> FWIW this is absolutely NOT how we're treating this in chromium.  If this is 
>> how things end up in practice then we will have failed massively in this 
>> effort.
>> 
>> We figure if we want the web to behave consistently, we really have no 
>> choice but to treat web-platform-tests as first class with all the 
>> discipline we give to our own tests.  As such we are actively moving 
>>  many of our LayoutTests to 
>> web-platform-tests and depending entirely on the regression prevention they 
>> provide us from there.  Obviously there will be hiccups, but because our 
>> product quality will depend on web-platform-tests being an effective and 
>> non-flaky testsuite (and because we're starting to require most new features 
>> have web-platform-tests before they ship), I'm confident that we've got the 
>> incentives in place to lead to constant ratcheting up the engineering 
>> discipline and quality of the test suite.
>> 
>> FWIW, mozilla also treats WPT as first class tests.  We're not actively 
>> moving old tests to WPT like google, but all new tests (at least in DOM) are 
>> being written in WPT.  Of course, we do have exceptions for some tests that 
>> require gecko-specific features (forcing GC, etc).
> 
> 
> We don't have a concept of "first class", but I hope that when choosing 
> between looking into a simple test that was added for a known important bug, 
> and looking into an imported test whose importance is unclear, any WebKit 
> engineer will pick the former. And since no one can fix all the things, such 
> prioritization makes imported tests less effective.

I just ran into a classic example of how a WPT incurred more overhead. I made a 
code change that broke 
LayoutTests/imported/w3c/web-platform-tests/cssom-view/elementFromPoint.html. I 
tried loading it in Safari and it doesn't run the test code because it can't 
find /resources/testharness.js when loaded from a local file.

So then I have to figure out how to fire up the WPT server (run-webkit-httpd), 
then figure out which host to use (localhost or 128.0.0.1?) and which port, and 
finally to figure out the right path to the test.

There's no reason this test should not work when loaded from file://.

Simon

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

Re: [webkit-dev] Another WPT bite

[Simon Fraser]

> On May 11, 2017, at 9:30 PM, Anne van Kesteren  wrote:
> 
> On Tue, May 9, 2017 at 8:27 PM, Simon Fraser  wrote:
>> I'm also concerned that with 4 vendors upstreaming their WPT tests, the WPT
>> repo will just become a morass of partially overlapping tests that takes 4x
>> longer to run than a curated repo.
> 
> Why do you think WPT is not curated? It's an actively maintained test
> suite. Treating it as a dumping ground would be a mistake I think.
> 
> For WHATWG standards we make sure to update corresponding tests for
> each change to the standard as well at which point any needed cleanup
> occurs (we didn't start out with this process unfortunately so there's
> definitely some cleanup left to be done here and there, but that's
> true for each software project).

I was under the impression that tests upstreamed from vendor repositories would 
land in WPT tests
with minimal review, based on the fact that they had been reviewed when landed 
in the vendor repo.

What's to stop 4 vendors from upstreaming similar but non-identical tests for a 
given feature?

Simon

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

Re: [webkit-dev] Another WPT bite

[Simon Fraser]

> On May 9, 2017, at 11:10 AM, Maciej Stachowiak  wrote:
> 
>> On May 9, 2017, at 8:11 AM, Geoffrey Garen > > wrote:
>> 
>>> What we're suggesting is to give preferential treatments to
>>> testharness.js over js-test.js / js-test-pre.js when you were already
>>> planning to write a test with the latter two scripts.
>> 
>> OK, I think this makes sense.
>> 
>> But I still think the very best kind of test is a flat file with 10-20 lines 
>> of code in it. Particularly for debugging JavaScript issues, large wrapper 
>> frameworks get in the way.
>> 
>>> - Tests would be more easily upstreamable to web-platform-tests, which are 
>>> run by all major browser engines. This would help a lot in terms of 
>>> interoperability. As previously discussed, Gecko and Blink already do 
>>> automated export of tests to web-platform-tests. I believe we should do in 
>>> the same direction and contribute more tests back.
>> 
>> I wonder why these other projects do automated export instead of 
>> incorporating testharness.js directly.
> 
> I don't think that's an "also", not an "instead". My understanding is that 
> they do two-way sync with the web-platform-tests GitHub, so there's a process 
> for downloading tests and upstreaming tests authored by their team. But they 
> still have their own copy.

Another consideration here is "would my test be useful for other browser 
vendors". I don't think the answer is a unanimous "yes", so I think we should 
only use WPT for tests that will think are worth sharing.

I'm also concerned that with 4 vendors upstreaming their WPT tests, the WPT 
repo will just become a morass of partially overlapping tests that takes 4x 
longer to run than a curated repo.

Simon


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

Re: [webkit-dev] !!Tests for equality comparison

[Simon Fraser]

+1 for ! liking ! when testing numeric values against zero.

Simon

> On Apr 27, 2017, at 4:33 PM, Chris Dumez  wrote:
> 
> I also do not like this rule when it comes to integers.
> 
> I personally think JF’s proposal to allow == 0 sounds nice. I don’t think JF 
> was suggesting rewriting existing code (which would indeed cause a lot of 
> churn).
> 
> --
>  Chris Dumez
> 
> 
> 
> 
>> On Apr 27, 2017, at 4:30 PM, Geoffrey Garen > > wrote:
>> 
>> I’ve never really liked this style rule, and I’ve always felt like it snuck 
>> into the style document without much discussion.
>> 
>> Even so, I usually tolerate it.
>> 
>> Geoff
>> 
>>> On Apr 27, 2017, at 4:06 PM, JF Bastien >> > wrote:
>>> 
>>> Hello C++ fans!
>>> 
>>> The C++ style check currently say:
>>> Tests for true/false, null/non-null, and zero/non-zero should all be done 
>>> without equality comparisons
>>> 
>>> I totally agree for booleans and pointers… but not for integers. I know 
>>> it’s pretty much the same thing, but I it takes me slightly longer to 
>>> process code like this:
>>> 
>>> int numTestsForEqualityComparison = 0:
>>> // Count ‘em!
>>> // …
>>> if (!numTestsForEqualityComparison)
>>>   printf(“Good job!”);
>>> 
>>> I read it as “if not number of tests for equality comparison”. That's 
>>> weird. It takes me every slightly longer to think about, and I’ve gotten it 
>>> wrong a bunch of times already. I’m not trying to check for “notness", I’m 
>>> trying to say “if there were zero tests for equality comparison”, a.k.a.:
>>> 
>>> if (numTestsForEqualityComparison == 0)
>>>   printf(“Good job!”);
>>> 
>>> So how about the C++ style let me just say that? I’m not suggesting we 
>>> advise using that style for integers everywhere, I’m just saying it should 
>>> be acceptable to check zero/non-zero using equality comparison.
>>> 
>>> 
>>> !!Thanks (i.e. many thanks),

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

Re: [webkit-dev] SVN trouble

[Simon Fraser]

EWS is still down. Do we have an ETA?

Simon

> On Feb 24, 2017, at 10:25 PM, Alexey Proskuryakov  wrote:
> 
> 
>> 24 февр. 2017 г., в 19:50, Chris Dumez > > написал(а):
>> 
>> 
>> 
>> 
>>> On Feb 24, 2017, at 11:41 AM, Alexey Proskuryakov >> > wrote:
>>> 
>>> I believe that all infrastructure has recovered. We are currently looking 
>>> into one unrelated issue with webkit-queues, so EWS and commit queue don't 
>>> work.
>>> 
>>> - Alexey
>> 
>> 
>> It looks like EWS is still down. Did it break again or is it just not fixed 
>> yet?
> 
> 
> It did work for a period of time, but no conclusive fix yet.
> 
> - Alexey

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

Re: [webkit-dev] CSS Parse error in element.

[Simon Fraser]

What WebKit revision are your sources based on? It's quite likely the this bug 
has been fixed.

Simon

> On Feb 9, 2017, at 4:09 AM, Atul Sowani  wrote:
> 
> Finally I zeroed in on 3 "calc" candidates from the stylesheet which are 
> causing the CSS parser to fail:
> 
> height:calc(100vh - 200px)
> height:calc(100vh - 230px)
> max-height:calc(100vh - 200px)
> 
> I think it is the very first one and the remaining two never get processed.
> 
> I put in some debug statements in the code and the corresponding output for 
> this is:
> 
> ATUL: value->id = 0 propId = 1080
> ATUL: in CSSPropertyHeight
> ATUL: in CSSPropertyWebkitLogicalHeight
> ATUL: in CSSCalcValue::create
> ATUL: in parseValueExpression, calling parseAdditiveValueExpression
> ATUL: calling CSSCalcBinaryOperation::create from parseAdditiveValueExpression
> ATUL: operatorCharacter = -
> ATUL: lhs = 1 rhs = 1
> ATUL: leftSide category = ATUL: m_category = 5
> 5
> ATUL: rightSide category = ATUL: m_category = 1
> 1
> ATUL: m_category = 5
> ASSERTION FAILED: leftSide->category() != CalcOther && rightSide->category() 
> != CalcOther
> css/CSSCalculationValue.cpp(293) : static 
> WTF::PassRefPtr 
> WebCore::CSSCalcBinaryOperation::create(WTF::PassRefPtr,
>  WTF::PassRefPtr, WebCore::CalcOperator)
> 1   0x12e8a80c bin/phantomjs() [0x12e8a80c]
> < stack trace removed >
> 
> So the question is, is the calc expression valid one?
> 
> Best regards,
> Atul.
> 
> On Thu, Feb 9, 2017 at 2:17 PM, Atul Sowani  > wrote:
> @Konstantin thanks for the suggestions. I disabled CSS JIT on x85 but there 
> was no negative impact on the results on x86. So I guess the issue is a 
> genuine ppc64le problem. I have picked up the starting points mentioned in 
> this thread earlier and debugging the issue. I have also isolated the issue 
> to a single CSS file which is causing the problem. Now I am trying to isolate 
> the exact entry in the CSS file which is causing the trouble.
> 
> Thanks!
> Atul.
> 
> On Tue, Feb 7, 2017 at 3:53 PM, Konstantin Tokarev  > wrote:
> 
> 
> 07.02.2017, 12:55, "Atul Sowani" mailto:sow...@gmail.com>>:
> > Thanks Geoffrey, Alex, Yoav for the debugging pointer. I am debugging the 
> > issue further using this information and will most likely need some more 
> > help in immediate future as well.
> >
> > Unfortunately, I don't have a stand-alone test case which can be tested 
> > with qtwebkit. I am trying to load a page using PhantomJS and it's 
> > crashing. The typical URLs which cause it to crash are http://engadget.com 
> >  and http://cnn.com  - both of these 
> > load without any issue on x86 platform though, so the issue seems to be 
> > specific to ppc64le.
> 
> A few suggestions:
> 
> 1. I suppose you are building with disabled JIT, as WebKit does not implement 
> JIT for any PPC variant in official tree. This may introduce subtle 
> differences in behavior, for example I once encountered layout test that was 
> failing only when CSS JIT was disabled. You can try building without JIT on 
> x86_64 and compare.
> 
> 2. It might be miscompilation, as your platform may not be as thoroughly 
> tested as more mainstream ones. You can try to build with -O0, -O1, -O2 
> (default is -O3). Alternatively, try building with different compiler (at 
> least GCC and Clang support ppc64le and are fine for WebKit, xlC may not work 
> though), or try different version of your compiler.
> 
> 3. Note that webkit-qt list is more appropriate for issues specific for 
> QtWebKit. Make sure you are using latest release (technology preview 5 at the 
> moment [1])
> 
> [1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 
> 
> 
> >
> > Thanks,
> > Atul.
> >
> > On Mon, Feb 6, 2017 at 5:56 PM, Yoav Weiss  > > wrote:
> >> Hi Atul,
> >>
> >> I second Alex's suggestion (perhaps followed by HTMLLinkElement::process() 
> >> and other places in that file that refer to `hrefAttr`).
> >> If you have a test case online, I could try to take a look and maybe 
> >> provide more guidance.
> >>
> >> Cheers :)
> >> Yoav
> >>
> >> On Fri, Feb 3, 2017 at 9:19 PM Alex Christensen  >> > wrote:
> >>> I would start looking at HTMLLinkElement::parseAttribute.
> >>> LinkHeader.cpp contains parsers for link headers, which are related.  
> >>> Yoav knows more about those.  Those parsers ought to be united more.
> >>>
>  On Feb 3, 2017, at 1:17 AM, Atul Sowani   > wrote:
>  At present I am focusing on CSSParser::findURI() particularly and 
>  CSSParser::realLex() other related functionality in CSSParser.cpp - hope 
>  I am on right track. ;-)
> 
>  Please let me know if I should be looking at some other functionality as 
>  well to resolve this issue.
> 
>  Thanks!
>  Atul.
> 
>  On Fri, Feb 3, 2017 at 2:

Re: [webkit-dev] Settings and Testing (Settings, RuntimeEnabledFeatures, WebPreferences)

[Simon Fraser]

> On Jan 21, 2017, at 12:56 AM, Ryosuke Niwa  wrote:
> 
> I'd be strongly opposed to adding yet another file that configures how
> tests are run. Even today, it's impossible to reason about whether a
> given test is expected to pass or fail because there are multiple
> TestExpectations in different platform directories and they cascade
> and override with one another.

That's why I added run-webkit-tests --print-expectations

It tells you exactly which TestExpectation lines affect each test.

Simon

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

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Simon Fraser]

> On Jan 10, 2017, at 9:03 PM, Darin Adler  wrote:
> 
> This kind of discussion should be on webkit-dev, not webkit-reviewers. While 
> the reviewers may have more standing to decide about such things, we normally 
> want to discuss them in the open.

Agreed. Moving there.

> If you don’t like “auto”, please first ask yourself first whether it is 
> because of years of experience reading and writing C++ code without it.
> 
> I like auto, auto&, and auto* pretty much everywhere they can be used. (I 
> almost never like const auto& or const auto*.)
> 
> As Brady pointed out, I find that auto* helps make it clear something is a 
> pointer, and I often prefer that to auto when a pointer is involved.
> 
> Without auto, we often convert types unnecessarily, for example, we call a 
> function and put a pointer to a RenderElement into a RenderObject*. Or 
> convert integer types from one integer type to another unnecessarily. Or 
> convert a Ref to a RefPtr even though the function we are calling can never 
> return a null.
> 
> It’s easy to get the illusion that if you don’t use auto you can “see” the 
> types in the program, but this true only in a limited sense. You can’t see 
> the types of expressions and subexpressions, only of variables. And if you 
> use auto, you can see that there is no type conversion. But if you use an 
> explicit type, you can’t see whether the type on the left matches the type on 
> the right, so this actually hides the “no type conversion here” information.
> 
> It’s often irrelevant what the type is to understanding the code, more 
> important to know what a value represents rather than its type. Specific 
> types can be a distraction. For example, if I am iterating a collection and 
> adding together the result of calling the width function on each element, do 
> I need to state what kind of object is in the collection? It both seems 
> unimportant, and can be a distraction. Arguably, the type of the result of 
> the width function is important, but I don’t know a way to make *that* type 
> visible. I can make what type I put the result into visible, but that still 
> doesn’t tell me what the type of the return value of the width function is.
> 
> I agree with Filip it can be good to write out the name of the type when we 
> want to document what the type is. But for me, this almost never comes up in 
> the kind of programming that I do on the project.
> 
> I’d love to see examples where using auto substantially hurts readability so 
> we could debate them.

Some contrary examples in code that I’ve seen/reviewed:

auto countOfThing = getNumberOfThings();
ASSERT(countOfThing >= 0);  // Can’t tell by reading whether the ASSERT is 
assured at compile time if countOfThing is unsigned

auto thingLength = getLengthOfThing();
IntSize size(thingLength, 2); // Can’t tell by reading if thingLength is 
LayoutUnit or float and thus truncated here.

Another common issue in code I’m not familiar with is something like:

auto fancyStyleThing = styleMagic.styleThingForDoohicky()

where it maybe obvious to the author what the type of fancyStyleThing is, but 
without looking at StyleMagic::styleThingForDoohicky() I have no idea what it 
is, and Xocde doesn’t help me. You argue above that maybe I don’t need to know 
the exact type, but often I do if I’m trying to figure out how various 
components relate to each other, rather than studying the logic of one specific 
function.

Simon




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

[webkit-dev] Enabling visual viewports by default

[Simon Fraser]

Hi floks!

I plan to enable visual viewports by default in WK1 and WK2 in the near future.

"visual viewports" is new behavior for position:fixed and sticky elements under 
page zoom; they lay out relative to a "layout viewport" (which is the size of 
the initial containing block), while the user pans around in the "visual 
viewport". When the visual viewport hits the edge of the layout viewport, it 
pushes this around.

This is a better user experience, and also matches Chrome and Firefox behavior 
more closely.

Is there any platform which would object to having this new behavior by 
default? I hope to remove the non-visual-viewport code at some point.

The master bug for this is https://bugs.webkit.org/show_bug.cgi?id=164260 
.

Simon

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

Re: [webkit-dev] What happened to WKR and webkitbot?

[Simon Fraser]

> On Nov 17, 2016, at 10:21 AM, Osztrogonác Csaba  wrote:
> 
> Hi,
> 
> it seems WKR and webkitbot left #webkit IRC channel
> on 4th Nov and we can't see them since then.
> 
> It would be great if somebody could
> find and ask them to come back.

Top people are working on this. We had to do some network reconfiguring on the 
hosts that ran these bots.

Simon

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

Re: [webkit-dev] Proposal: Remove Battery Status API code

[Simon Fraser]

Added to features.json as "Removed".

https://trac.webkit.org/changeset/208303 


People, don't be shy in filling out features.json for things you're working on, 
or know are either done, or have outside interest.

Simon

> On Nov 2, 2016, at 2:11 PM, Brady Eidson  wrote:
> 
> 
>> On Oct 30, 2016, at 8:27 PM, Brady Eidson  wrote:
>> 
>> I filed https://bugs.webkit.org/show_bug.cgi?id=164213 to track the task of 
>> removing.
>> I'll continue to monitor this email thread and comments in that bug, but 
>> assuming no objections come up I'll remove the code later this week.
> 
> Seems like nobody objects to removing this.
> 
> The motion carries.
> 
> ~Brady
> ___
> 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] Proposal: Remove Battery Status API code

[Simon Fraser]

I support the proposal to remove.

Simon

> On Oct 30, 2016, at 5:14 PM, Brady Eidson  wrote:
> 
> 
> There's code in the tree to support the W3C Battery Status API.
> 
> A recent study showed the extent of the risk (discussion and link to study 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.lukaszolejnik.com_battery-2Dstatus-2Dreadout-2Das-2Da-2Dprivacy-2Drisk_&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=gEUmSR3VtC-5Q3Im6T2Js1aXwjJK4RExonGEvDq2twI&m=ZKSbJXtXvUd44zKls9LfZwY1fsH0NRSg8KxOY7clZdI&s=8c9qMq7SAf9mAh8t9oHbJE45_tXRsbZBMid46hd9UXs&e=
>  ) which led to Mozilla first making the API less precise 
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1124127) but then eventually 
> removing it altogether (https://bugzilla.mozilla.org/show_bug.cgi?id=1313580)
> 
> Apple has never enabled this on their ports, one reason being concern for 
> abuse in fingerprinting/tracking. 
> The study seems to be a strong second opinion backing this concern.
> Mozilla's actions demonstrate another vendor not seeing the API being useful 
> enough to outweigh the user concern.
> 
> As one of the voices for Apple's ports I think the above episode further 
> cements our concern in ever enabling the API.
> 
> As one of the voices for WebKit as a whole I think above episode suggests we 
> should just remove the code from the tree altogether.
> 
> What to other Apple folks think? What do port maintainers who enable the API 
> think?
> 
> Thanks,
> ~Brady

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

Re: [webkit-dev] Inactive Committers and Reviewers

[Simon Fraser]

A provisional list of the list of committers and reviewers who will become 
inactive is in https://bugs.webkit.org/show_bug.cgi?id=163318 
<https://bugs.webkit.org/show_bug.cgi?id=163318>

Simon

> On Oct 9, 2016, at 5:57 PM, Simon Fraser  wrote:
> 
> I plan to implement these changes, via additions to contributors.json, in the 
> near future, by making inactive any committer/reviewer who has not exercised 
> their privilege in the past year. There will be a few VIPs who retain their 
> commit and/or review rights.
> 
> I do not intend to email people whose status changes. If someone loses commit 
> access because of these changes, they can request reinstatement by emailing 
> webkit-reviewers.
> 
> Simon
> 
>> On Jul 9, 2014, at 7:31 AM, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote:
>> 
>> Hello WebKittens,
>> 
>> WebKit reviewers recently had a discussion about the large number of 
>> inactive committers and reviewers left after the Blink fork, and we've come 
>> to introduce a new policy to consider committers and reviewers who have not 
>> contributed to the project over one year "inactive".  In addition, any 
>> subversion account that hasn't been used to commit a code change to 
>> svn.webkit.org <http://svn.webkit.org/> over one year is subject to the 
>> deactivation. [1]
>> 
>> The policy change has been enacted as of r170904 
>> <http://trac.webkit.org/r170904> which added the following section to the 
>> WebKit Committers and Reviewer Policy 
>> <http://www.webkit.org/coding/commit-review-policy.html>.
>> 
>> 
>> Inactive Committer or Reviewer Status
>> 
>> A WebKit Committer or Reviewer that has not been active in the project for 
>> over a year is considered inactive. Activity for this purpose is defined as 
>> landing at least one patch in the past year. Reviewers who have reviewed a 
>> patch in the past year will also be considered active.
>> 
>> Inactive Committers can regain Active Committer status by landing (via the 
>> Commit Queue) a non-trivial patch and asking on webkit-reviewers for a 
>> return to Active status.
>> 
>> Inactive Reviewers need to show that they are making an effort to get  
>> familiar with the changes that have happened in the project since they were 
>> last active by landing at least 3 non-trivial patches. Once they have landed 
>> the patches, they need to send an email requesting reactivation to 
>> webkit-reviewers. This request needs the support of 2 Active Reviewers to be 
>> granted.
>>  
>> Note that regardless of a Committer or Reviewer's activity status, any 
>> subversion account that has not been used in the past year will be 
>> deactivated for security purposes. For example, a Reviewer that has reviewed 
>> a patch in the past year but has not committed may have their subversion 
>> account deactivated. To reactivate a deactivated subversion account, an 
>> Active Committer or Active Reviewer can send an email to webkit-reviewers 
>> requesting it.
>> 
>> 
>> - R. Niwa
>> 
>> [1] For the initial mass deactivation, I will send an email to each address 
>> associated with the subversion account and give the account owner an option 
>> to keep it active.
> 
> ___
> 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] Inactive Committers and Reviewers

[Simon Fraser]

I plan to implement these changes, via additions to contributors.json, in the 
near future, by making inactive any committer/reviewer who has not exercised 
their privilege in the past year. There will be a few VIPs who retain their 
commit and/or review rights.

I do not intend to email people whose status changes. If someone loses commit 
access because of these changes, they can request reinstatement by emailing 
webkit-reviewers.

Simon

> On Jul 9, 2014, at 7:31 AM, Ryosuke Niwa  wrote:
> 
> Hello WebKittens,
> 
> WebKit reviewers recently had a discussion about the large number of inactive 
> committers and reviewers left after the Blink fork, and we've come to 
> introduce a new policy to consider committers and reviewers who have not 
> contributed to the project over one year "inactive".  In addition, any 
> subversion account that hasn't been used to commit a code change to 
> svn.webkit.org  over one year is subject to the 
> deactivation. [1]
> 
> The policy change has been enacted as of r170904 
>  which added the following section to the 
> WebKit Committers and Reviewer Policy 
> .
> 
> 
> Inactive Committer or Reviewer Status
> 
> A WebKit Committer or Reviewer that has not been active in the project for 
> over a year is considered inactive. Activity for this purpose is defined as 
> landing at least one patch in the past year. Reviewers who have reviewed a 
> patch in the past year will also be considered active.
> 
> Inactive Committers can regain Active Committer status by landing (via the 
> Commit Queue) a non-trivial patch and asking on webkit-reviewers for a return 
> to Active status.
> 
> Inactive Reviewers need to show that they are making an effort to get  
> familiar with the changes that have happened in the project since they were 
> last active by landing at least 3 non-trivial patches. Once they have landed 
> the patches, they need to send an email requesting reactivation to 
> webkit-reviewers. This request needs the support of 2 Active Reviewers to be 
> granted.
>  
> Note that regardless of a Committer or Reviewer's activity status, any 
> subversion account that has not been used in the past year will be 
> deactivated for security purposes. For example, a Reviewer that has reviewed 
> a patch in the past year but has not committed may have their subversion 
> account deactivated. To reactivate a deactivated subversion account, an 
> Active Committer or Active Reviewer can send an email to webkit-reviewers 
> requesting it.
> 
> 
> - R. Niwa
> 
> [1] For the initial mass deactivation, I will send an email to each address 
> associated with the subversion account and give the account owner an option 
> to keep it active.

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

[webkit-dev] iPad tests are now possible

[Simon Fraser]

With https://trac.webkit.org/changeset/204477 and some earlier groundwork, it's 
now possible to add
iPad-specific tests. Any test in a directory with an "ipad" suffix will be run 
in an iPad Air simulator,
both with DumpRenderTree and WebKitTestRunner.

When combined with "", 
the test will run in
an iPad-sized web view, but this only works in WebKitTestRunner at present.

This is implemented by having webkitpy Ports expose "custom device classes". As 
tests are gathered,
any test in a directory with a suffix that matches a custom device class is 
gathered into a list of tests
that will be run after the rest of the tests, by setting up the testing 
environment for that particular
device class. So any port can specify custom device classes by simply declaring 
a CUSTOM_DEVICE_CLASSES array.

Let me know if you find any issues.

Simon

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

Re: [webkit-dev] Strange result in fast/backgrounds/mask-composite.html

[Simon Fraser]

> On Jul 22, 2016, at 4:20 PM, Konstantin Tokarev  wrote:
> 
> Hello,
> 
> I'm getting attached result for fast/backgrounds/mask-composite.html, while 
> in the tree expected result looks like
> 
> https://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/fast/backgrounds/mask-composite-expected.png
> https://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/fast/backgrounds/mask-composite-expected.png
> 
> Is it a known behavior change?

No, please file a bug.

Simon

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

Re: [webkit-dev] canvas and sRGB

[Simon Fraser]

> On May 2, 2016, at 2:59 PM, Dean Jackson  wrote:
> 
> 
>> On 3 May 2016, at 7:04 AM, Rik Cabanier > <mailto:caban...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, May 2, 2016 at 1:58 PM, Simon Fraser > <mailto:simon.fra...@apple.com>> wrote:
>>> On May 2, 2016, at 1:45 PM, Rik Cabanier >> <mailto:caban...@gmail.com>> wrote:
>>> 
>>> All,
>>> 
>>> with the release of DCI-P3 screen, WebKit began supporting the display of 
>>> high gamut images.
>>> Specifically, if you have an image with a DCI-P3 profile, its pixels render 
>>> untouched on the new displays.
>>> 
>>> However, if you try do do any sort of canvas manipulation, you will see 
>>> that the colors are being compressed to sRGB and you will lose the depth of 
>>> the color.
>>> 
>>> Was it an oversight to always create the canvas imagebuffer in sRGB? [1]
>> 
>> No, this was a deliberate choice. We can't change author expectations for 
>> what getImageData() return.
>> 
>> Now we see different visual output which is also not what an author expects 
>> :-(
> 
> Since there is no way to create a canvas element with pixel data that is 
> interpreted to be in anything other than sRGB, this behaviour seems expected 
> to me. I'm not sure what else could happen? We couldn't magically make all 
> the canvas elements in the page use P3. If we did that, they wouldn't match 
> the CSS content.
> 
> The fix is coming: a way to tag the colorspace of the canvas element.

Also a way to specify that you want deep backing store:
<https://github.com/whatwg/html/issues/299 
<https://github.com/whatwg/html/issues/299>>

Simon


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

Re: [webkit-dev] canvas and sRGB

[Simon Fraser]

> On May 2, 2016, at 1:45 PM, Rik Cabanier  wrote:
> 
> All,
> 
> with the release of DCI-P3 screen, WebKit began supporting the display of 
> high gamut images.
> Specifically, if you have an image with a DCI-P3 profile, its pixels render 
> untouched on the new displays.
> 
> However, if you try do do any sort of canvas manipulation, you will see that 
> the colors are being compressed to sRGB and you will lose the depth of the 
> color.
> 
> Was it an oversight to always create the canvas imagebuffer in sRGB? [1]

No, this was a deliberate choice. We can't change author expectations for what 
getImageData() return.

> If this is as-designed, how can we work around this limitation?

With possible future enhancements to the canvas spec that allow authors to 
request backing store with a different format and/or color profile.
> 
> PS
> I asked the same question on WhatWG. [2]
> 
> 
> 1: 
> https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73
>  
> 
> 2: 
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html 
> 
Simon


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

Re: [webkit-dev] About unprefixing CSS Grid Layout (implementation status summary included)

[Simon Fraser]

> On Apr 27, 2016, at 4:39 AM, Manuel Rego Casasnovas  wrote:
> 
> Hi,
> 
> as announced yesterday it seems that the WebKit prefixing policy has
> been updated [1].
> 
> Right now CSS Grid Layout implementation is prefixed in WebKit and
> behind a compilation flag.
> We'd like to ask about the possibility to unprefix it and put it behind
> a runtime flag (probably removing the compilation flag too).

I approve of this proposal.

Simon

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

Re: [webkit-dev] Memory leak tracking in WebKit

[Simon Fraser]

This sounds like a bug that would affect all WebKit ports. Can you file a 
bugs.webkit.org bug, and continue investigation there?

Simon

> On Jan 5, 2016, at 12:03 PM, Vienneau, Christopher  wrote:
> 
> Hi,
>  
> I’ve resumed the memory leak tracking I was doing last year, I have some more 
> details to share, hopefully you’ll be able to suggest how I might fix it.  
> The source of the leak appears to come from the below callstack.  A cache of 
> animation points is being created in SVGAnimatedProperty(SVGElement* 
> contextElement, const QualifiedName& attributeName, AnimatedPropertyType 
> animatedPropertyType), however the destructor for SVGAnimatedProperty is 
> never called.  The passed in contextElement gains a ref when the 
> SVGAnimatedProperty is created, however I’m not seeing a code path where the 
> animation points should be destroyed.  This effects both svg polyline and 
> polygon, and results in leaking the whole page.
>  
> Thanks for any help you can provide,
>  
> Chris Vienneau
>  
>  
> \WebCore\svg\properties\SVGAnimatedProperty.cpp
> SVGAnimatedProperty::SVGAnimatedProperty(SVGElement* contextElement, const 
> QualifiedName& attributeName, AnimatedPropertyType animatedPropertyType)
> : m_contextElement(contextElement)
> , m_attributeName(attributeName)
> , m_animatedPropertyType(animatedPropertyType)
> , m_isAnimating(false)
> , m_isReadOnly(false)
> {
> }
>  
> > 
> > EAWebKitd.dll!WebCore::SVGAnimatedProperty::SVGAnimatedProperty(WebCore::SVGElement
> >  * contextElement, const WebCore::QualifiedName & attributeName, 
> > WebCore::AnimatedPropertyType animatedPropertyType) Line 29
> > C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::SVGAnimatedListPropertyTearOff(WebCore::SVGElement
>  * contextElement, const WebCore::QualifiedName & attributeName, 
> WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
> values) Line 166 C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::create(WebCore::SVGElement
>  * contextElement, const WebCore::QualifiedName & attributeName, 
> WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
> values) Line 159 C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedProperty::lookupOrCreateWrapper,WebCore::SVGPointList>(WebCore::SVGPolyElement
>  * element, const WebCore::SVGPropertyInfo * info, WebCore::SVGPointList & 
> property) Line 57 C++
>
> EAWebKitd.dll!WebCore::SVGPolyElement::lookupOrCreatePointsWrapper(WebCore::SVGElement
>  * contextElement) Line 117C++
>EAWebKitd.dll!WebCore::SVGPolyElement::animatedPoints() Line 
> 130  C++
>
> EAWebKitd.dll!WebCore::updatePathFromPolylineElement(WebCore::SVGElement * 
> element, WebCore::Path & path) Line 106   C++
>
> EAWebKitd.dll!WebCore::updatePathFromGraphicsElement(WebCore::SVGElement * 
> element, WebCore::Path & path) Line 172   C++
>
> EAWebKitd.dll!WebCore::RenderSVGShape::updateShapeFromElement() Line 84   
> C++
>EAWebKitd.dll!WebCore::RenderSVGPath::updateShapeFromElement() 
> Line 48  C++
>EAWebKitd.dll!WebCore::RenderSVGShape::layout() Line 164   C++
>
> EAWebKitd.dll!WebCore::SVGRenderSupport::layoutChildren(WebCore::RenderElement
>  & start, bool selfNeedsLayout) Line 281   C++
>EAWebKitd.dll!WebCore::RenderSVGRoot::layout() Line 181  
> C++
>EAWebKitd.dll!WebCore::RenderElement::layoutIfNeeded() Line 
> 135C++
>EAWebKitd.dll!WebCore::RenderBlockFlow::layoutLineBoxes(bool 
> relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, 
> WebCore::LayoutUnit & repaintLogicalBottom) Line 1621   C++
>
> EAWebKitd.dll!WebCore::RenderBlockFlow::layoutInlineChildren(bool 
> relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, 
> WebCore::LayoutUnit & repaintLogicalBottom) Line 652C++
>EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlock(bool 
> relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 484C++
>EAWebKitd.dll!WebCore::RenderBlock::layout() Line 930  
> C++
>
> EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & 
> child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit 
> & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) 
> Line 712C++
>
> EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool 
> relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 633   
>  C++
>EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlock(bool 
> relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 488C++
>

Re: [webkit-dev] How to deal with 1-pixel differences in reftests ?

[Simon Fraser]

> On Nov 18, 2015, at 9:04 AM, Darin Adler  wrote:
> 
>> On Nov 18, 2015, at 4:36 AM, Carlos Alberto Lopez Perez  
>> wrote:
>> 
>> Some reference tests give a 1-pixel or very few pixel differences [1].
> 
> Why? We need to understand why.
> 
>> Should we tolerate a few pixel differences for reftests ?
> 
> I don’t think we should. I think we should look more deeply into why these 
> differences exist and consider writing the reference tests differently. We 
> should not add tolerance when we don’t yet know why the results are different.

There are some well-understood reasons why a test might not exactly match its 
reference. One is that the test uses compositing layers to do clipping, but the 
reference just clips with drawing, and these are not expected to give a 
pixel-perfect match.

I proposed a way to allow a test to specify a custom tolerance in 
https://bugs.webkit.org/show_bug.cgi?id=149828. If we had this, it would allow 
me to fix 142258  and 146523 
.

Simon

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

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

[Simon Fraser]

> On Nov 1, 2015, at 7:40 PM, Darin Adler  wrote:
> 
> Hi folks.
> 
> Our engine supports alpha values from 0-255. But when we serialize them, we 
> turn them into floating point values. When we do that, we include way too 
> many digits of precision. For example, the alpha value 127 becomes 0.498039.
> 
> I like the idea of writing the minimum number of digits that are needed to 
> round trip. So 127 would become 0.498 or even maybe 0.49 and 128 would become 
> 0.5.
> 
> Three questions:
> 
> 1) Does the CSS specification allow or encourage this?

As long as the values round-trip, I think it’s OK.

> 2) Do you like this idea?

I would like to know what other browsers do.

Simon

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

Re: [webkit-dev] Improved CrashLog collection in Webkit Tests

[Simon Fraser]

> On Oct 27, 2015, at 3:09 PM, Aakash Jain  wrote:
> 
> Hi All,
> 
> In the webkit test results page, we have added a section "Other Crashes" 
> (through https://bugs.webkit.org/show_bug.cgi?id=150056). After the tests are 
> complete, we go through the crashlog directory on the machine and scan all 
> the crashlogs generated during test run. We then check if these crashes are 
> already associated with any test by webkitpy, if not, we will list them in 
> "Other Crashes" section.
> 
> It would enable us to notice the crashes which were previously being hidden. 
> For e.g. this run shows a backboardd crash:
> https://build.webkit.org/results/Apple%20iOS%209%20Simulator%20Release%20WK2%20(Tests)/r191612%20(645)/results.html
>  
> 

Is it wise to show non-WebKit process crashes on build.webkit.org 
? They can contain symbol names etc. for non-public 
frameworks.

Simon

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

Re: [webkit-dev] WebCore crashes calling layout code on wrong thread (iOS 9 SDK only)

[Simon Fraser]

We’re tracking an issue similar to this internally. Could you please file a bug 
report at bug reporter.apple.com, with a copy of the app and steps to reproduce?

Thanks
Simon

> On Oct 26, 2015, at 11:05 AM, Ian Ragsdale  wrote:
> 
> Hi all, I'm running into a strange crash when I build my application using 
> the iOS 9 SDK (we don't see this crash in prior versions of our app).
> 
> The error we see is "NSInternalInconsistencyException accessing 
> _cachedSystemAnimationFence requires the main thread", and the stack trace is 
> below.
> 
> Any ideas on how I might track this down or avoid it?
> 
> Thanks,
> Ian
> 
> Thread : Fatal Exception: NSInternalInconsistencyException
> 0  CoreFoundation 6527766344 __exceptionPreprocess + 124
> 1  libobjc.A.dylib6878281600 objc_exception_throw + 56
> 2  CoreFoundation 6527766040 +[NSException raise:format:]
> 3  Foundation 6543444508 -[NSAssertionHandler 
> handleFailureInMethod:object:file:lineNumber:description:] + 112
> 4  UIKit  6620261688 -[UIApplication 
> _cachedSystemAnimationFenceCreatingIfNecessary:] + 200
> 5  UIKit  6620261884 -[UIApplication 
> _systemAnimationFenceCreatingIfNecessary:] + 24
> 6  UIKit  6620609076 +[UIWindow 
> _synchronizedDrawingFence] + 116
> 7  UIKit  6625701528 -[_UIRemoteViewController 
> synchronizeAnimationsInActions:] + 124
> 8  UIKit  6625679332 -[_UISizeTrackingView 
> _geometryChanges:forAncestor:] + 540
> 9  UIKit  6620678428 -[UIView 
> _notifyGeometryObserversWithChangeInfo:] + 272
> 10 UIKit  6617880096 -[UIView setCenter:] + 408
> 11 UIKit  6618589764 -[UIView(Geometry) 
> _applyISEngineLayoutValues] + 600
> 12 UIKit  6617592576 -[UIView(Geometry) 
> _resizeWithOldSuperviewSize:] + 136
> 13 CoreFoundation 6526679440 __53-[__NSArrayM 
> enumerateObjectsWithOptions:usingBlock:]_block_invoke + 132
> 14 CoreFoundation 6526679176 -[__NSArrayM 
> enumerateObjectsWithOptions:usingBlock:] + 308
> 15 UIKit  6617521936 -[UIView(Geometry) 
> resizeSubviewsWithOldSize:] + 116
> 16 UIKit  6618590092 
> -[UIView(AdditionalLayoutSupport) _is_layout] + 128
> 17 UIKit  6620696916 -[UIView(Hierarchy) 
> _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 756
> 18 UIKit  6617479084 -[UIView(CALayerDelegate) 
> layoutSublayersOfLayer:] + 644
> 19 QuartzCore 6609087320 -[CALayer layoutSublayers] + 148
> 20 QuartzCore 6609065828 
> CA::Layer::layout_if_needed(CA::Transaction*) + 292
> 21 QuartzCore 6609065508 
> CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 32
> 22 QuartzCore 6609063104 
> CA::Context::commit_transaction(CA::Transaction*) + 252
> 23 QuartzCore 6609062408 CA::Transaction::commit() + 512
> 24 QuartzCore 6609035512 
> CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, 
> void*) + 80
> 25 CoreFoundation 6527466448 
> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
> 26 CoreFoundation 6527457652 __CFRunLoopDoObservers + 372
> 27 CoreFoundation 6526602432 CFRunLoopRunSpecific + 416
> 28 WebCore6827173196 RunWebThread(void*) + 456
> 29 libsystem_pthread.dylib6888979240 _pthread_body + 156
> 30 libsystem_pthread.dylib6888979084 _pthread_body
> 31 libsystem_pthread.dylib6888968232 thread_start + 4
> ___
> 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] New iOS testing functionality

[Simon Fraser]

I’ve recently landed a string of patches which enable new WK2 testing 
functionality, particularly for iOS. These consist of a new function on 
TestRunner, testrunner.runUIScript(), and the creation of a JS context in the 
UI process which runs script that can call into UIScriptController. There is 
documentation here: 
https://trac.webkit.org/wiki/Writing%20Layout%20Tests%20to%20test%20iOS%20UI%20features
 


The basics are now implemented that allow for testing of things like viewport 
sizing and single- and double-tap behaviors. If you are landing a feature or 
bug fix for iOS that is not currently testable, please add functionality to 
this test harness so that you can land a layout test with your patch.

Reviewers, please be on the look-out for such patches, and be willing to r- 
them if a test is lacking.

Simon

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

[webkit-dev] Implementing CSS "will-change"

[Simon Fraser]

I intend to implement the CSS will-change property, as specified here:

http://www.w3.org/TR/css-will-change-1/ 


Since this is already supported unperfected by Firefox and Chrome, I will 
implement it unprefixed, and without an ENABLE flag.

Work will be done via this bug:

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


Simon

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

[webkit-dev] New tool to show class or struct padding

[Simon Fraser]

I just landed a new script called 'dump-class-layout' in 
http://trac.webkit.org/changeset/188350 that shows class and struct padding. 
This script uses lldb Python bindings to collect information about the data 
member layout, which can be used to look for padding holes to reduce class 
size. It points lldb at your built frameworks, and by default uses the last 
configuration built from the command line. Optional parameters can supply a 
build directory and Debug/Release configuration.

Usage is:
dump-class-layout  

for example:
./Tools/Scripts/dump-class-layout WebCore RenderElement

Found 1 types matching "RenderElement" in 
"/Volumes/Data/Development/OSX/webkit/OpenSource/WebKitBuild/Release/WebCore.framework/WebCore"
  +0 { 72} RenderElement
  +0 { 48} WebCore::RenderObject
  +0 {  8} WebCore::CachedImageClient
  +0 {  8} WebCore::CachedResourceClient
  +0 <  8> __vtbl_ptr_type * _vptr;
  +8 <  8> WebCore::Node & m_node;
 +16 <  8> WebCore::RenderElement * m_parent;
 +24 <  8> WebCore::RenderObject * m_previous;
 +32 <  8> WebCore::RenderObject * m_next;
 +40 <  4> WebCore::RenderObject::RenderObjectBitfields m_bitfields;
 +40 <  4> unsigned int:1 m_hasRareData;
 +40 <  4> unsigned int:1 m_beingDestroyed;
 +40 <  4> unsigned int:1 m_needsLayout;
 +40 <  4> unsigned int:1 m_needsPositionedMovementLayout;
 +40 <  4> unsigned int:1 m_normalChildNeedsLayout;
 +40 <  4> unsigned int:1 m_posChildNeedsLayout;
 +40 <  4> unsigned int:1 m_needsSimplifiedNormalFlowLayout;
 +40 <  4> unsigned int:1 m_preferredLogicalWidthsDirty;
 +41 <  4> unsigned int:1 m_floating;
 +41 <  4> unsigned int:1 m_isAnonymous;
 +41 <  4> unsigned int:1 m_isTextOrRenderView;
 +41 <  4> unsigned int:1 m_isBox;
 +41 <  4> unsigned int:1 m_isInline;
 +41 <  4> unsigned int:1 m_isReplaced;
 +41 <  4> unsigned int:1 m_isLineBreak;
 +41 <  4> unsigned int:1 m_horizontalWritingMode;
 +42 <  4> unsigned int:1 m_hasLayer;
 +42 <  4> unsigned int:1 m_hasOverflowClip;
 +42 <  4> unsigned int:1 m_hasTransformRelatedProperty;
 +42 <  4> unsigned int:1 m_unused;
 +42 <  4> unsigned int:1 m_everHadLayout;
 +42 <  4> unsigned int:1 m_childrenInline;
 +42 <  4> unsigned int:2 m_positionedState;
 +43 <  4> unsigned int:3 m_selectionState;
 +43 <  4> unsigned int:2 m_flowThreadState;
 +43 <  4> unsigned int:2 m_boxDecorationState;
 +47 <  1> 
 +44 <  4> unsigned int:6 m_baseTypeFlags;
 +44 <  4> unsigned int:1 m_ancestorLineBoxDirty;
 +44 <  4> unsigned int:1 m_hasInitializedStyle;
 +45 <  4> unsigned int:1 m_renderInlineAlwaysCreatesLineBoxes;
 +45 <  4> unsigned int:1 m_renderBoxNeedsLazyRepaint;
 +45 <  4> unsigned int:1 m_hasPausedImageAnimations;
 +45 <  4> unsigned int:1 m_hasCounterNodeMap;
 +45 <  4> unsigned int:1 m_isCSSAnimating;
 +45 <  4> unsigned int:1 m_hasContinuation;
 +45 <  4> unsigned int:1 m_renderBlockHasMarginBeforeQuirk;
 +45 <  4> unsigned int:1 m_renderBlockHasMarginAfterQuirk;
 +46 <  4> unsigned int:1 
m_renderBlockHasBorderOrPaddingLogicalWidthChanged;
 +46 <  4> unsigned int:1 m_renderBlockFlowHasMarkupTruncation;
 +46 <  4> unsigned int:2 m_renderBlockFlowLineLayoutPath;
 +48 <  8> WebCore::RenderObject * m_firstChild;
 +56 <  8> WebCore::RenderObject * m_lastChild;
 +64 <  8> WTF::Ref m_style;
 +64 <  8> WebCore::RenderStyle * m_ptr;
Total byte size: 72
Total pad bytes: 1
Padding percentage: 1.39 %

Enhancements welcome. The most obvious one I can think of is to target a 
specific architecture.

Simon

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

[webkit-dev] Moving tests out of platform directories

[Simon Fraser]

Starting this week, I plan to move layout tests out of the LayoutTests/platform 
directories. The goal is to have the LayoutTests/platform directories contain 
only results (and TestExpectation files). This avoids the creation of test 
results in directories like platform/mac/platform/mac.

The plan is:
1. Move directories of platform tests out of platform directories into the 
top-level LayoutTests directory (or some subdirectory as appropriate)
2. Skip those tests on non-applicable platforms via TestExpectations
3. Change check-webkit-style to warn about new tests added in platform 
directories
4. Possibly have run-webkit-tests fail with an error when it finds any test in 
a platform directory

Objections?

Simon

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

Re: [webkit-dev] maximalOutlineSize inflate all RenderLayers

[Simon Fraser]

This is a well-known issue. Ideally outline size would be factored into visual 
overflow, but that’s a bit tricky because outline is weird and crosses between 
RenderObjects.

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



> On Jul 6, 2015, at 9:26 PM, Kim, NamHoon  wrote:
> 
> Hi experts,
>  
> While hacking composited layer in WebKit, I realized CSS outline style 
> inflate size of all RenderLayers. Since WebKit has default css of 5px outline 
> for focused element, focusing input in the below sample inflate the cyan box. 
> This can reproduced in WK2 OSX port in r186227.
>  
> 
> .box {
>   position: fixed;
>   top: 50px;
>   width: 100px;
>   height: 30px;
>   border-radius: 10%;
>   background-color: cyan;
> }
> 
>  
> 
> 
>  
> Through investigation, I found `RenderView::m_maximalOutlineSize` value is 
> set in the RenderElement::setStyle() function. And this cause inflation of 
> layers in RenderLayer::localBoundingBox() function. Since setter of 
> `m_maximalOutlineSize` scheduled rebuild of the whole composited layers, all 
> layers inflated by the value.
>  
> Honestly, I don’t know about this value’s purpose. But it seems weird to me 
> that this value does not cleared in the RenderView even after outline style 
> cleared. (i.e. loose focus of the input)
>  
> And this behavior makes several problem in our ports, [EAWebKit][1]. Since we 
> uses composited layers backed by DirectX, this makes paint call requests 
> larger size than texture itself in TextureMapperTile::paint() function. This 
> cause rendering of corrupted memory. Steps follow,
>  
> a. layer inflated by maximalOutlineSize. Let 100x100 layer increased to 
> 110x110.
> b. texture increased in the 
> TextureMapperTiledBackingStore::createOrDestroyTilesIfNeeded() to 110x110.
> c. layer’s texture destroyed then reconstructed by display style change.
> d. while reconstruct of the layer’s texture, this time texture created with 
> the size of 100x100 instead of 110x110.
> e. then painting this texture in TextureMapperTile::paint() request 110x110 
> rect for 100x100 texture.

This sounds like a bug in your port.

> While step d. GraphicsLayerTextureMapper::m_needsDisplayRect intersected with 
> TextureMapperTile::m_rect, makes texture smaller then layer’s size. On the 
> other hand, TextureMapperTile::paint() call in the step e. request whole 
> TextureMapperTile::m_rect for draw request.
>  
> To escape this problem, I overridden default style of :focus to `outline: 
> none`. I wonder better solution for this. Is it some bug of WebKit? Is there 
> some proper way to handle this? If inflation of the layers inevitable, it 
> seems reasonable shrunken back after outline style cleared.

Simon


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

Re: [webkit-dev] Mac EWS failures

[Simon Fraser]

This is my fault; I’ll look at this today.

Simon

> On Jul 1, 2015, at 8:30 AM, svillar  wrote:
> 
> Hi,
> 
> it seems that both Mac EWS and Mac WK2 EWS are reporting this failure
> 
> Regressions: Unexpected image-only failures (1)
>  compositing/masks/compositing-clip-path-origin.html [ ImageOnlyFailure ]
> 
> which is marking every single new patch to be reviewed as cq-. Apparently 
> bots don't complain so perhaps there is some library which was updated or so 
> in the EWS machines?
> 
> BR
> ___
> 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] build.webkit.org issue

[Simon Fraser]

On Jun 8, 2015, at 2:12 AM, Osztrogonác Csaba  wrote:
> it seems build.webkit.org is unavailabe since yesterday 23:13:00 (UTC).
> It would be great if somebody can check what happened. Thanks.

We’re looking into it.

Thanks
Simon

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

Re: [webkit-dev] Content-DPR header

[Simon Fraser]

> On May 29, 2015, at 2:11 PM, Yoav Weiss  wrote:
> 
> On Fri, May 29, 2015 at 8:34 PM, Sam Weinig  > wrote:
> Hi Yoav,
> 
> Can you give a concrete example of when this will be used?  I’m having 
> trouble understanding when an author will want to change an images intrinsic 
> size but not have control of the markup.
> 
> It's not about control over markup, it's about control over style.
> 
> Let's say you're now given the following task: write a script that will go 
> over all your server's HTML files and make your images responsive by adding a 
> `srcset` attribute to all  tags. Since some of the images may change 
> their display dimensions at different viewport sizes (i.e the "variable 
> width" use case 
> ),
>  you want to add multiple resources with `w` descriptors to each . Each 
> one of these resources will be pointed towards your shiny new image server, 
> which has access to the original high-quality image as well as the currently 
> displayed one (the "src image").
> 
> But, since you don't know if all the images have their dimensions defined in 
> CSS (and you suspect that a large chunk of them don't have CSS based 
> dimensions), you want to make sure that the intrinsic dimensions of the 
> displayed images remain the same even when you deliver images of varying 
> "physical" dimensions. How can you achieve that?
> 
> Well, the answer is, you want to modify the intrinsic size of the delivered 
> images to be the same as the "src image"'s intrinsic dimensions. With 
> Content-DPR, that's easy. You simply set it to the value that is the 
> delivered image width divided by the "src image" width.
> That way, the browser takes the Content-DPR into account, scales the 
> delivered image and it ends up with the same intrinsic dimensions as the "src 
> image".
> 
> If you don't have markup control, the same exercise applies, but would 
> require the full-fledged Client-Hints in order to actually deliver resized 
> images.

As others have said, doing this at the transport layer seems wrong.

Why not just invent some new metadata that gets put into the image to describe 
some scaling of the intrinsic size?

Simon


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

Re: [webkit-dev] Clarifying 3D feature defines

[Simon Fraser]

On Apr 24, 2015, at 9:14 PM, Martin Robinson  wrote:

> On Thu, Apr 23, 2015 at 4:48 PM, Simon Fraser  wrote:
>> USE(3D_GRAPHICS) appears to surround WebGL code in general. I don’t see any 
>> non-WebGL bits in a quick search.
> 
> It seems that USE(3D_GRAPHICS) simply enables GraphicsContext3D and
> its helper classes, so I propose that we rename this to
> ENABLE_GRAPHICS_CONTEXT_3D.

Sounds good to me.

Simon

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

Re: [webkit-dev] Clarifying 3D feature defines

[Simon Fraser]

On Apr 23, 2015, at 4:39 PM, Martin Robinson  wrote:
> 
> In the process of cleaning up and dusting off the GTK+ cmake build
> system, we have rediscovered the pair of somewhat confusing feature
> defines WTF_USE_3D_GRAPHICS and ENABLE_3D_RENDERING. From a brief
> audit, it appears that WTF_USE_3D_GRAPHICS is a generic flag for any
> kind of 3D rendering at all (including WebGL), while
> ENABLE_3D_RENDERING refers specifically to perspective
> transformations.
> 
> Would it be worthwhile to clarify these flags slightly? My proposal is
> to rename ENABLE_3D_RENDERING to either ENABLE_3D_TRANSFORMS or
> ENABLE_PERSPECTIVE_TRANSFORMS, though I support any names that reduce
> the possible confusion between these flags.

USE(3D_GRAPHICS) appears to surround WebGL code in general. I don’t see any 
non-WebGL bits in a quick search.

ENABLE(3D_RENDERING) means “turn on the ability to support and render 3D CSS 
transforms)”. I would be OK with  ENABLE_3D_TRANSFORMS, which is more accurate 
than ENABLE_PERSPECTIVE_TRANSFORMS.

Simon

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