Re: [webkit-dev] Request for position on Event Timing

2020-08-06 Thread 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

2020-07-14 Thread 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

2020-06-17 Thread 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

2020-06-08 Thread 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

2020-06-04 Thread 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

2020-04-23 Thread 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?

2020-02-26 Thread 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

2020-02-19 Thread 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

2020-02-19 Thread 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()

2020-02-05 Thread 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()

2020-02-03 Thread 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's really a "frame available" callback. Why not 

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

2020-01-22 Thread 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()

2020-01-21 Thread 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

2019-11-12 Thread 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

2019-11-08 Thread 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

2019-11-08 Thread 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

2019-11-08 Thread 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

2019-10-28 Thread 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

2019-10-28 Thread 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?

2019-09-29 Thread 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

2019-09-28 Thread 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

2019-09-26 Thread 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

2019-04-01 Thread 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

2019-03-20 Thread 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

2019-03-14 Thread 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

2019-02-27 Thread 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?

2019-02-22 Thread 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

2019-02-21 Thread 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

2019-02-20 Thread 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

2019-02-20 Thread 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

2019-02-13 Thread 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"

2018-12-19 Thread 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

2018-11-05 Thread 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

2018-11-05 Thread 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

2018-11-05 Thread 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?

2018-09-20 Thread 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

2018-09-01 Thread 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

2018-08-24 Thread 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

2018-08-08 Thread 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

2017-10-04 Thread 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

2017-09-27 Thread 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)]

2017-08-29 Thread 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

2017-08-15 Thread 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

2017-08-14 Thread Simon Fraser
> On Aug 11, 2017, at 3:31 PM, Simon Fraser <simon.fra...@apple.com> 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


[webkit-dev] Intent to remove: ENABLE_REQUEST_AUTOCOMPLETE

2017-08-11 Thread 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] Intent to remove: ENABLE_PROXIMITY_EVENTS

2017-08-11 Thread 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

2017-05-12 Thread 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

2017-05-11 Thread Simon Fraser
> On May 11, 2017, at 9:30 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> 
> On Tue, May 9, 2017 at 8:27 PM, Simon Fraser <simon.fra...@apple.com> 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] !!Tests for equality comparison

2017-04-27 Thread 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

2017-02-25 Thread 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.

2017-02-09 Thread 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" >:
> > 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 

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

2017-01-21 Thread 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

2017-01-10 Thread 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

2016-12-05 Thread 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?

2016-11-17 Thread 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

2016-11-02 Thread 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

2016-10-30 Thread 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_=CwICAg=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84=gEUmSR3VtC-5Q3Im6T2Js1aXwjJK4RExonGEvDq2twI=ZKSbJXtXvUd44zKls9LfZwY1fsH0NRSg8KxOY7clZdI=8c9qMq7SAf9mAh8t9oHbJE45_tXRsbZBMid46hd9UXs=
>  ) 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

2016-10-11 Thread 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 <simon.fra...@apple.com> 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 <rn...@webkit.org 
>> <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

2016-10-09 Thread 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

2016-08-15 Thread 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

2016-07-22 Thread 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

2016-05-02 Thread Simon Fraser

> On May 2, 2016, at 2:59 PM, Dean Jackson <d...@apple.com> wrote:
> 
> 
>> On 3 May 2016, at 7:04 AM, Rik Cabanier <caban...@gmail.com 
>> <mailto:caban...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, May 2, 2016 at 1:58 PM, Simon Fraser <simon.fra...@apple.com 
>> <mailto:simon.fra...@apple.com>> wrote:
>>> On May 2, 2016, at 1:45 PM, Rik Cabanier <caban...@gmail.com 
>>> <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

2016-05-02 Thread 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)

2016-04-27 Thread 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

2016-01-05 Thread 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::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 
> 

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

2015-11-18 Thread 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

2015-11-02 Thread 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

2015-10-27 Thread 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)

2015-10-26 Thread 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

2015-09-30 Thread 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

2015-08-15 Thread Simon Fraser
I intend to implement the CSS will-change property, as specified here:

http://www.w3.org/TR/css-will-change-1/ 
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 
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

2015-08-12 Thread 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 framework classname

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 PADDING
 +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::RefWebCore::RenderStyle 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

2015-08-03 Thread 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

2015-07-06 Thread 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 
https://bugs.webkit.org/show_bug.cgi?id=106397


 On Jul 6, 2015, at 9:26 PM, Kim, NamHoon na...@ea.com 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.
  
 style
 .box {
   position: fixed;
   top: 50px;
   width: 100px;
   height: 30px;
   border-radius: 10%;
   background-color: cyan;
 }
 /style
  
 input type='text'
 div class='box'/div
  
 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

2015-07-01 Thread Simon Fraser
This is my fault; I’ll look at this today.

Simon

 On Jul 1, 2015, at 8:30 AM, svillar svil...@igalia.com 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

2015-06-08 Thread Simon Fraser
On Jun 8, 2015, at 2:12 AM, Osztrogonác Csaba o...@inf.u-szeged.hu 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

2015-05-29 Thread Simon Fraser

 On May 29, 2015, at 2:11 PM, Yoav Weiss y...@yoav.ws wrote:
 
 On Fri, May 29, 2015 at 8:34 PM, Sam Weinig wei...@apple.com 
 mailto:wei...@apple.com 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 img tags. Since some of the images may change 
 their display dimensions at different viewport sizes (i.e the variable 
 width use case 
 https://dev.opera.com/articles/native-responsive-images/#variable-width-images),
  you want to add multiple resources with `w` descriptors to each img. 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

2015-04-23 Thread Simon Fraser
On Apr 23, 2015, at 4:39 PM, Martin Robinson mrobin...@webkit.org 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


Re: [webkit-dev] run-webkit-tests and run-perf-tests scripts now use WebKitTestRunner by default

2015-04-12 Thread Simon Fraser
On Mar 5, 2015, at 12:14 PM, Chris Dumez cdu...@apple.com wrote:

 Hi,
 
 I just wanted to let you know that run-webkit-tests and run-perf-tests now 
 use WebKitTestRunner by default after [1].
 Passing —webkit-test-runner or -2 to these scripts is no longer needed (and 
 no longer works).
 
 If you wish to run DumpRenderTree, you should pass —dump-render-tree or -1 to 
 these scripts.

I think that now we’ve done this, we should make LayoutTests/platform/mac/ 
contain WK2 results by default, and place
WK1 exceptions in platform/mac-wk1. Same for other platforms.

Thoughts?

Simon


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


Re: [webkit-dev] WebCore/platform standalone library

2015-03-20 Thread Simon Fraser

 On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com wrote:
 
  This almost makes me want to suggest a jokey name for Platform. I can’t 
  off the top of my head think of a good expansion of OMG, though. Or BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object 
  Library. Algorithm Reuse Framework. New Framework for WebCore, New System 
  Framework for WebCore.
 
 Platform Obfuscation Source.
 
 Platform Interface and Testing Abstraction.
 
 General Independent Framework (pronounced jiff, of course).
 
 Low-Level Abstract Platform would also be a logical choice.

Low-level Object Library.

Simon

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


Re: [webkit-dev] WebCore/platform standalone library

2015-03-20 Thread Simon Fraser
On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote:

 On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 
 I am not a pro at this, but here are a few tries: Lower-level Object Library. 
 Algorithm Reuse Framework. New Framework for WebCore, New System Framework 
 for WebCore.

Platform Obfuscation Source.

Simon

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


Re: [webkit-dev] WebKit debugging on OSX and ~/.lldbinit

2015-02-24 Thread Simon Fraser
On Feb 24, 2015, at 3:10 PM, Sylvain Galineau galin...@adobe.com wrote:

 I’ve recently found myself in the following situation while debugging 
 WebKit: the debugger (Xcode) would hit a breakpoint, I would place a new 
 breakpoint in a method up the current call stack, re-run my test and 
 then…nothing. The new breakpoint would never be hit though the original 
 one still was and I could still see that method on the call stack with my 
 breakpoint in it.
 
 For instance, I would set a breakpoint in FontCascade::width(), see 
 RenderSVGText::layout() on the call stack then set a breakpoint in the 
 latter. I’d try my test again and never break into 
 RenderSVGText::layout(). 
 
 I verified I was using a debug build, rebuilt from scratch, tried 
 command-line LLDB, stood on my head, no luck.
 
 Until I added:
 
   settings set target.inline-breakpoint-strategy always
 
 
 in ~/.lldbinit.
 
 I’m glad it works - yay breakpoints - but am not quite sure why this bit 
 of magic is needed. Does anyone else use this/know why it helps?  

This is a known issue (tracked internally as rdar://problem/16829492). It’s
exacerbated by our “all in one” .cpp files (e.g. RenderSVGAllInOne.cpp) which
are required to get around linking size issues iirc.

Simon

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


Re: [webkit-dev] WebKit debugging on OSX and ~/.lldbinit

2015-02-24 Thread Simon Fraser
On Feb 24, 2015, at 3:29 PM, Sylvain Galineau galin...@adobe.com wrote:

 
 From: Simon Fraser
 Date: Tuesday, February 24, 2015 at 3:19 PM
 To: Adobe
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] WebKit debugging on OSX and ~/.lldbinit
 
 On Feb 24, 2015, at 3:10 PM, Sylvain Galineau galin...@adobe.com wrote:
 
 I’ve recently found myself in the following situation while debugging 
 WebKit: the debugger (Xcode) would hit a breakpoint, I would place a 
 new 
 breakpoint in a method up the current call stack, re-run my test and 
 then…nothing. The new breakpoint would never be hit though the original 
 one still was and I could still see that method on the call stack with 
 my 
 breakpoint in it.
 
 For instance, I would set a breakpoint in FontCascade::width(), see 
 RenderSVGText::layout() on the call stack then set a breakpoint in the 
 latter. I’d try my test again and never break into 
 RenderSVGText::layout(). 
 
 I verified I was using a debug build, rebuilt from scratch, tried 
 command-line LLDB, stood on my head, no luck.
 
 Until I added:
 
 settings set target.inline-breakpoint-strategy always
 
 
 in ~/.lldbinit.
 
 I’m glad it works - yay breakpoints - but am not quite sure why this 
 bit 
 of magic is needed. Does anyone else use this/know why it helps?  
 
 This is a known issue (tracked internally as rdar://problem/16829492). 
 It’s
 exacerbated by our “all in one” .cpp files (e.g. RenderSVGAllInOne.cpp) 
 which
 are required to get around linking size issues iirc.
 
 This definitely explains it, thanks!
 
 I don’t mind writing up a small addition to webkit.org’s Debugging WebKit 
 page. Does that work through the same bugzilla-patch upload process as 
 everything else or can I just submit a PR at 
 https://github.com/WebKit/webkit/tree/master/Websites/webkit.org?

Please use bugzilla.

Simon

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


Re: [webkit-dev] run-webkit-tests question; hashes when comparing ref test output

2015-01-23 Thread Simon Fraser
On Jan 23, 2015, at 10:01 AM, Ryosuke Niwa rn...@webkit.org wrote:
 
 
 On Friday, January 23, 2015, Darin Adler da...@apple.com 
 mailto:da...@apple.com wrote:
  On Jan 22, 2015, at 10:36 PM, Alexey Proskuryakov a...@webkit.org 
  javascript:; wrote:
 
  22 янв. 2015 г., в 17:57, Darin Adler da...@apple.com javascript:; 
  написал(а):
 
  What about the test I cited?
 
  svg/css/svg-resource-fragment-identifier-img-src.html
 
  This particular test is buggy - it is a hidpi test, so it dumps results as 
  a 1600x1200 image, but its -expected.html is not hidpi, and is dumped as 
  800x600, so hashes are obviously different. I now filed 
  https://bugs.webkit.org/show_bug.cgi?id=140815 
  https://bugs.webkit.org/show_bug.cgi?id=140815 about this test.
 
  When we compare pixels, we draw both images into bitmaps of the same size, 
  so they become similar enough for ImageDiff to consider them identical.
 
  Earlier today, Simon and I agreed that we should just silence the error 
  message, because it only tells us about minor color differences that are 
  inevitable when comparing compositing vs. non-compositing. Looks like it 
  tells us about more actionable issues, too. Also, I just found 
  https://bugs.webkit.org/show_bug.cgi?id=69444 
  https://bugs.webkit.org/show_bug.cgi?id=69444, and I think that its 
  rationale applies in this case, too.
 
  So we should probably keep this error message. I'm not sure whether we 
  should make it a hard error though.
 
 I think that to improve things we should make an informative message for this 
 particular mistake where the expected file has the wrong size or resolution.
 
 For me, the bad thing about the current message is not simply that it’s a 
 false positive, but that it’s an unclear error message that covers too many 
 different possibilities.
 
 I’m not sure that keeping things as is will be a good strategy. A message 
 that is often expected but sometimes indicates a real problem is not good for 
 the project. The average engineer has no idea whether to ignore these or act 
 on them!

Agreed. The size difference certainly needs to be a failure.

 
 We could add a new test expectation like ImageDiff to suppress these or we 
 could expose a new internals or testRunner methods to mark a test as such.

I don’t think that addresses the issue. Darin’s point is that if a developer 
sees this output (possibly when running tests after making a change), it needs 
to describe something actionable.

Just suppressing this output for existing tests doesn’t help when the output 
crops up unexpectedly.

Simon

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


Re: [webkit-dev] run-webkit-tests question; hashes when comparing ref test output

2015-01-22 Thread Simon Fraser

 On Jan 22, 2015, at 8:44 AM, Darin Adler da...@apple.com wrote:
 
 I noticed that when running tests I get messages like this:
 
svg/css/svg-resource-fragment-identifier-img-src.html - ref test hashes 
 didn't match but diff passed
 
 I understand that we can have hash mismatches in actual checked in images 
 (expected.png files), and there, at least, I believe the fix might be to 
 regenerate the image. But for a ref test I am really unclear on this. And 
 further, I think it’s distracting to get messages like this unless you are 
 specifically working on the testing infrastructure.
 
 Why should the average WebKit engineer care about this? Does this reflect a 
 real performance problem when running tests? If so, who would fix it and what 
 would that person do?

Alexey, Tim and I looked at this yesterday.

This happens when the expected and actual images are very close, but not 
identical. ImageDiff has some built-in rounding that effectively acts as a 
small tolerance, so the hashes are different, but ImageDiff incorrectly says 
the images are the same. For example, some of the tests in question render a 
green box either via CALayers, or by painting, and there’s a slight color 
difference between the two code paths.

My preference for how to fix this would be to fix ImageDiff to remove its 
slight built-in tolerance, and then to expose testRunner API to allow a test to 
set an explicit tolerance. There are many cases where we’d like to use ref 
tests, but are unable to because of slight, justifiable rendering differences, 
and having an explicit tolerance would permit the use of ref tests in these 
cases.

Simon

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


[webkit-dev] Myles Maxfield is now a WebKit reviewer

2015-01-07 Thread Simon Fraser
It is with great pleasure that I announce that Myles Maxfield is now a WebKit 
reviewer!

Myles has been doing stellar work in the text and fonts code, particularly in 
cleaning up SVG fonts and improving our underline rendering, and is quickly 
becoming an expert in more areas. I look forward to him exercising his 
reviewing skills!

Simon

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


Re: [webkit-dev] enhancement - html hole element

2014-09-18 Thread Simon Fraser
On Sep 18, 2014, at 9:22 AM, Julien Isorce j.iso...@samsung.com wrote:
 
 Hi,
 
 A typical scenario when running WebKit in an embedded environment like a TV 
 or STB is to punch through graphics to the video plane.
 
 At Samsung Research UK we have developed a new hole element  that acts much 
 like a canvas to
 
 - Expose a rectangular hole in a web page.
 - Support a mechanism to retrieve the position and size of the hole from 
 JavaScript whenever its dimensions or location change.
 
 We realise that there is currently no W3 specification for this element, but 
 since our solution works we wanted to open the discussion to see if there is 
 any wider interest, and if there is, to start the process of drafting a 
 specification. Some details:
 
 - Principle:
 
 A hole is a rectangular area that behaves pretty much like a canvas, but 
 everything in its area is transparent.
 Every layer behind the hole is transparent in this rectangle.
 In JavaScript you can register a handler which is notified when the hole 
 position or size changes.
 
 - Use case:
 
 On TV this is useful to see the channel displayed behind the browser. 
 Retrieving the hole's position and size
 from JavaScript allows to rescale the TV channel plane to match the hole area 
 whenever the hole changes.
 Assume in JavaScript we have an object to control the TV channel plane.
 This use case applies in many interactive TV applications, so it could be 
 useful for a lot of people.
 
 - Interfaces:
 
 We have defined a new tag hole which  is similar to the canvas tag.
 We have defined a geometrychanged JS event which is sent when the hole 
 dimensions change.
 This event contains the hole width, height and position in screen coordinates.
 
 - Hole in canvas:
 
 A hole tag has been defined to be less intrusive and having the feature in 
 separate places in the code.
 But we now think it may be better to actually put the hole capabilities 
 under the canvas.
 For example canvas style=background:hole;
 
 Note that setting it as transparent is not enough to have a hole as the 
 layers behind the canvas won't be necessarily transparent, and not only in 
 its area.
 The whole point of the hole capability is to make transparent every layers 
 behind the hole and only in a specific rectangle.
 
 - Next steps:
 
 I would be very interested to hear if there are any other developers who need 
 this functionality. If so, let's discuss the best way to share it, or 
 possibly do it a better way.
 
 Comments are welcome.

I don’t think it’s appropriate to add hole to WebKit.

hole is really just adapting to a limitation of the platform’s compositing 
architecture. More powerful hardware like computers and smartphones are able to 
composite video above and below web content, which is achieved in WebCore via 
the accelerated compositing code path. I don’t think it’s appropriate to burden 
the platform with an element that only applies on power-limited hardware.

The right solution for a WebKit implementation would be to solve this via the 
accelerated composting code. Just use a video or object in your markup, 
then implement the hole-punching via the GraphicsLayer subsystem.

Simon

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


Re: [webkit-dev] FFT normalization in RealtimeAnalyser

2014-08-15 Thread Simon Fraser
Please file a bug at bugs.webkit.org.

Simon

On Aug 15, 2014, at 1:56 AM, Info i...@wothke.ch wrote:

 This seems to be a bug... that has been fixed in Chromium: see 
 chromium\src\third_party\WebKit\Source\modules\webaudio
 
 
 Zitat von Info i...@wothke.ch:
 
 In order to understand the idiotic differences between the data ranges of 
 the AnalyzerNode's getFloatFrequencyData() and getByteFrequencyData() APIs I 
 finally found myself analyzing the WebKit sources: 
 https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/webaudio/RealtimeAnalyser.cpp
 
 What surprises me there is the:
const double magnitudeScale = 1.0 / DefaultFFTSize;
 which is used to normalize the FFT results (see 
 RealtimeAnalyser::doFFTAnalysis()).
 
 Should the correct scaling factor not rather be: 2/actualFftSize?

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


Re: [webkit-dev] Comment on the bug email author/reviewer before reverting a patch

2014-07-09 Thread Simon Fraser
On Jul 9, 2014, at 7:43 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Hi all,
 
 This is a friendly remainder that you should
 comment on the associated bug
 email the patch author and the reviewer who reviewed the patch
 before rolling out / reverting a patch.

If you use webkitbot to roll out, is this necessary?

Simon

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


Re: [webkit-dev] Comment on the bug email author/reviewer before reverting a patch

2014-07-09 Thread Simon Fraser
With any waiting period before actually rolling out?

Simon

On Jul 9, 2014, at 11:40 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Yes.  The point is to do these things before telling webkitbot to rollout a 
 patch.
 
 - R. Niwa
 
 
 On Wed, Jul 9, 2014 at 11:07 AM, Simon Fraser simon.fra...@apple.com wrote:
 On Jul 9, 2014, at 7:43 AM, Ryosuke Niwa rn...@webkit.org wrote:
 
 Hi all,
 
 This is a friendly remainder that you should
 comment on the associated bug
 email the patch author and the reviewer who reviewed the patch
 before rolling out / reverting a patch.
 
 If you use webkitbot to roll out, is this necessary?
 
 Simon
 
 

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


Re: [webkit-dev] Comment on the bug email author/reviewer before reverting a patch

2014-07-09 Thread Simon Fraser

On Jul 9, 2014, at 1:15 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Jul 9, 2014 at 1:08 PM, Brady Eidson beid...@apple.com wrote:
 
 On Jul 9, 2014, at 12:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Wed, Jul 9, 2014 at 12:35 PM, Tim Horton timothy_hor...@apple.com wrote:
 
 On Jul 9, 2014, at 12:10 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 Could we teach webkitbot to do an appropriate notification with a waiting 
 period? Either as part of rollout or add a new command to do it.
 
 It already does. The “waiting period” is defined by when the person who 
 asked for the rollout sets the cq+ bit on the rollout patch.
 
 I don't think creating a rollout patch should be the standard method of 
 notifying the author/reviewer.  We should be informing the author/reviewer 
 ahead of the time.
 
 We already have an automated tool that quickly and easily notifies the 
 author/reviewer, and that tool also happens to create the rollout patch.
 
 As Tim points out, the rollout patch is never landed unless a reviewer 
 (usually the person who created the rollout patch) sets the cq+ bit on it.
 
 I don’t see what negative effect the mere existence of the rollout patch has, 
 or why we should codify into the process that a rollout patch is *not* 
 created when notifying the author/reviewer.
 
 When the bug for a rollout is created, the original bug is automatically 
 reopened.
 
 Also, the bot doesn't provide enough information as to what's breaking 
 because it only takes a single line of description on IRC.
 
 It's crucial that whoever reverting a patch provide a detailed explanation on 
 what build or test failed and provide a hyper link to build.webkit.org.  
 Otherwise the original author and the reviewer may have no idea what went 
 wrong.

I think the person who does the rollout should provide sufficient info in the 
rollout bug to justify the rollout. I would prefer this to new policy that 
requires emailing the committer and reviewer.

Simon


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


[webkit-dev] PSA: please sort WebCore.exp.in when you change it

2014-07-07 Thread Simon Fraser
We have a handy script that sorts the export file; please use it whenever you 
modify WebCore.exp.in:

./Tools/Scripts/sort-export-file Source/WebCore/WebCore.exp.in

It’s smart enough to understand #ifdef groupings and everything!

Simon

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


Re: [webkit-dev] CSS values and multiple backgrounds

2014-06-27 Thread Simon Fraser
On Jun 27, 2014, at 11:26 AM, Daniel Weber dan.j.we...@gmail.com wrote:

 I’m running into some trouble developing an app that needs to parse multiple 
 CSS background values. The problem is that WebKit isn’t returning the same 
 number of values for “background-image”, “background-position”, 
 “background-size”, “background-repeat”, and “background-attachment”. If there 
 are 3 background images, I would expect that all of the background properties 
 contain 3 values, separated by commas. But that doesn’t seem to be the case. 
 For example, I parse the following CSS text:
 
 background: url(http://example.com/image.png), linear-gradient(rgb(255,0,0), 
 blue) center top repeat-y scroll, 10px 10px no-repeat scroll;
 
 
 I then call CSSStyleDeclaration.cssText and I get:
 
 background-image: url(http://example.com/image.png), 
 linear-gradient(rgb(255, 0, 0), blue), initial; background-attachment: 
 initial, scroll, scroll; background-origin: initial, initial, initial; 
 background-clip: initial, initial, initial; background-size: initial, 
 initial, initial; background-position: 50% 0%, 10px 10px; background-repeat: 
 repeat-y, no-repeat;
 
 
 Notice that there are 3 values for background-image (a url, a gradient, and 
 “initial” for the last one because it doesn’t specify an image). There are 3 
 values for background-attachment, background-origin, background-clip, and 
 background-size. But the problem is with background-position and 
 background-repeat. They only have 2 values because only 2 of the backgrounds 
 specify these properties. But then how do I know that the first background 
 does not specify a background-position or background-repeat? It seems to me 
 there should be an “initial” placeholder for these properties. Am I missing 
 something?

Assuming other browsers get this right, please file a bug.

Simon

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


[webkit-dev] Zalan Bujtas is now a WebKit reviewer

2014-06-17 Thread Simon Fraser
Hi floks!

It is with great pleasure that I announce that Zalan is now a WebKit reviewer. 
He’s our resident subpixel expert, and in fixing many subpixel issues in layout 
and rendering code, has gained an extensive knowledge of the codebase, which he 
can now apply to reviewing your patches!

Congrats, Zalan!

Simon

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


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

2014-05-16 Thread Simon Fraser
On May 14, 2014, at 4:04 AM, Mészáros Tibor mti...@inf.u-szeged.hu wrote:

 Hi Everyone,
 
 I’d like to propose removing ENABLE(CSS_STICKY_POSITION) guards, because all 
 ports already enabled it by default.
 You can find here the original discussion about it: 
 https://bugs.webkit.org/show_bug.cgi?id=129793
 I prepared a patch which removes the ENABLE(CSS_STICKY_POSITION) guards - 
 https://bugs.webkit.org/show_bug.cgi?id=132676 .
 
 Any objection against the removal?

No objection here, and I reviewed the patch.

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


Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

2014-05-05 Thread Simon Fraser
It allows attackers to know even more about my system, exposing more data for 
fingerprinting.

Do you really want a page to know that you have a  fancy-pants 24-core Mac Pro 
rather than a little Mac mini?

Simon

On May 5, 2014, at 4:58 PM, Filip Pizlo fpi...@apple.com wrote:

 I like this.  Personally, I don't see any downside.
 
 Is there a bug (on bugs.webkit.org), and if not, can you create one? :-)
 
 -Phil
 
 
 On May 5, 2014 at 4:49:35 PM, Rik Cabanier (caban...@gmail.com) wrote:
 
 All,
 
 there's a thread on blink-dev [1] and whatwg [2] to create a new parameter 
 on the navigator object that returns the maximum number of tasks that can 
 run in parallel. [3]
 
 Is this something that WebKit would support?
 
 1: 
 https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4
 2: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-May/254200.html
 3: http://wiki.whatwg.org/wiki/NavigatorCores

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


[webkit-dev] Remove USE_DYNAMIC_ANNOTATIONS?

2014-04-16 Thread Simon Fraser
Does any port define USE_DYNAMIC_ANNOTATIONS? It’s adding header pollution and 
no-one seems to use it.

Simon

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


Re: [webkit-dev] Make accelerated compositing mandatory

2014-02-05 Thread Simon Fraser
There’s nothing in the Accelerated Compositing code path that assumes that you 
are using the GPU. You just have provide a GraphicsLayer implementation.

Simon

On Feb 5, 2014, at 6:41 PM, Chen Zhixiang che...@cn.fujitsu.com wrote:

 I’d been working on enabling 3d perspective transform in software-rendering 
 mode(based on Qt painter or skia), but failed
 I hope the proposed AC mode could work with NON-GPU env. which could made 3d 
 perspective transform possiable?
  
 发件人: webkit-dev-boun...@lists.webkit.org 
 [mailto:webkit-dev-boun...@lists.webkit.org] 代表 Andrei Bucur
 发送时间: 2014年1月28日 18:06
 收件人: webkit-dev@lists.webkit.org
 主题: [webkit-dev] Make accelerated compositing mandatory
  
 Hello webkittens,
  
 Do you happen to know if we still have ports that build WebKit without 
 accelerated compositing? If not, I'd like to write a patch that removes the 
 flag and makes AC mandatory.
  
 From IRC, I've heard that the Haiku port (not upstreamed) disables the AC 
 flag, but they agree they should switch it on in the future.
  
 Thoughts?
 Andrei.
 ___
 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] Make accelerated compositing mandatory

2014-01-28 Thread Simon Fraser
On Jan 28, 2014, at 10:47 AM, Martin Robinson mrobin...@webkit.org wrote:

 On Tue, Jan 28, 2014 at 10:33 AM, Anders Carlsson ander...@apple.com wrote:
 I’m not a layout and rendering person, but I suspect that the burden lies in 
 that part of WebCore. I also don’t think building with accelerated 
 compositing means that it has to be enabled at all; WebKitGTK+ on Windows 
 could probably just have a stub implementation of the relevant GraphicsLayer 
 classes.
 
 A stub implementation disabled at runtime would be fine for us, I believe.

I think it would be fairly trivial to remove most of the #ifdefs but just never 
make any compositing layers on some platforms.

Simon

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


[webkit-dev] Remove the WinCE bot?

2014-01-04 Thread Simon Fraser
The WinCE bot has been dead for almost a month:

http://build.webkit.org/builders/WinCE%20Release%20%28Build%29

I propose we remove it from the waterfall.

WinCairo is also in a pretty bad, non-building state.

Simon

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


  1   2   3   >