Re: [webkit-dev] OWNERS policy

[Maciej Stachowiak]

> On Feb 21, 2018, at 11:06 PM, Carlos Garcia Campos  
> wrote:
> 
> El mié, 21-02-2018 a las 13:49 -0800, Ryosuke Niwa escribió:
>> If there was any confusion, WebKit2 Owner's policy is still active
>> and in effect.
> 
> And maybe it's time to get rid of it? I never liked the idea, but I
> have to admit it made sense at the time it was done. The WebKit2
> development was on fire and wk2 developers couldn't spend time dealing
> with build failures on other ports that would slow down the development
> pace. Nowadays, WebKit2 doesn't really exist, it's WebKit again, and
> the old WebKit is considered legacy. We no longer need a policy.
> Removing the policy doesn't mean not owners will do any kind of
> changes, I think we all know when to ask other developers for a second
> review or approval. The same we have always done in other components
> jsc, WebCore, WTF that don't have an owners policy.

Some of us at Apple have discussed changing it, but nothing to announce yet.

I do think we have problems with people reviewing things that they aren't fully 
qualified to review, but that happens throughout the whole tree. So that 
logically leads to the conclusion of either no OWNERS or OWNERS everywhere.

> 
>> In the case you aren't sure of the right reviewer, you can send a
>> bulk email to all of us. I get cc'ed on every WebKit bug with Mac
>> EWS/CQ failure, and as such, I ignore all WebKit bugs I'm cc'ed
>> unless the bug title is of my interest.
>> 
>> - R. Niwa
>> 
>> On Wed, Feb 21, 2018 at 1:27 PM, youenn fablet 
>> wrote:
>>> Hi Don,
>>> 
>>> I am not sure there is a well defined policy.
>>> If we want to continue with owners, it would indeed be good to make
>>> it clearer and more functional.
>>> 
>>> Here is my current understanding.
>>> The multi-process architecture is now well in place so things like
>>> updating IPC encoders/decoders might no longer require a dedicated
>>> owner scrutiny.
>>> Exposing the right WK2 APIs is more sensitive on the other hand.
>>> 
>>>   Y
>>> 
>>> Le mer. 21 févr. 2018 à 12:52,  a écrit :
 Hi WebKittens,
 
 As you know we're working on getting WinCairo running on modern
 WebKit. We're working through a backlog of patches we have to
 upstream and are sometimes running into issues where we can't
 find reviewers for our code.
 
 Here are some bugs with attachments that have been hanging out
 for over 5 days.
 
 https://bugs.webkit.org/show_bug.cgi?id=182870
 https://bugs.webkit.org/show_bug.cgi?id=182869
 https://bugs.webkit.org/show_bug.cgi?id=182751
 
 One thing we're unclear on is the OWNERS policy. The list itself
 is pretty small and has no guidance on who might be the right
 person(s) to assign a bug to when touching shared code. It feels
 like we're just guessing on reviewers which doesn't seem like it
 helps anything move along.
 
 There also seem to be commits that were reviewed by non-owners
 that are touching common code. We're not sure if unfamiliarity
 with Windows might prevent some owners from looking over a patch
 as we move further along in our implementation.
 
 Basically we'd like to get some clarification here so we can keep
 landing patches for modern WebKit on Windows.
 
 Thanks!
 Sony WebKit Team
 ___
 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

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

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

[Maciej Stachowiak]

> On Jan 8, 2018, at 1:33 PM, Aakash Jain  wrote:
> 
> Hi Everyone,
> 
> I filed the Buildbot bug regarding Waterfall view not displaying steps 
> information by default: https://github.com/buildbot/buildbot/issues/3884 
>  "Waterfall view should 
> display steps information without hovering over".
> 
> I got the response that the issue with displaying all the steps information 
> by default in waterfall view is that it would require a lot of API calls, and 
> so it wouldn't be scalable.
> 
> Can you guys look at the new console and grid view to see if they can serve 
> as an alternative?
> e.g.:
> https://nine.buildbot.net/#/console 
> https://nine.buildbot.net/#/grid 
I wish the bubbles in those showed something more useful than the build ID, 
like revision number and/or number of failures. The build number is not really 
useful for seeing whether a given patch has passed tests, since the person who 
committed won't know the build number to look for and it won't even be the same 
for all bots. Also it doesn't show anything at all useful on hover, you have to 
click through.

It seems like this style of grid and console view would make it very hard to 
answer questions like "has my patch built and passed tests successfully on all 
bots yet", which is my main interest at least out of a build not view.

Console view is close to being good for that, but:
- Doesn't include the revision number on the summary line, you have to click 
through.
- Gives PR number instead a one-liner summary of the patch without expanding.
- Has the mostly-useless build numbers in bubbles.
- Can't tell easily when a build or test step is still pending (some boxes have 
more than one bubble in them, but I don't seee

I'm not totally sure of the use cases for waterfall so I don't know if it would 
be good for that.

> 
> 
> Here is the complete response:
> 
> "I agree the new waterfall is not very useful.
> It is not really a problem of UI change, it is rather a problem of the number 
> of rest API needed to get the information needed. In order to display the old 
> waterfall, you need to get the whole details for every builds (steps, logs), 
> that would be dozens of REST api calls, which would take a lot of time.
> 
> The old waterfall was not very scalable too, on my old buildbot eight at 
> work, we disabled it, because it was stalling the the master for 10s every 
> time one user would look at it.
> 
> The question you have to ask your users is what is the information that is 
> really needed.
> Maybe we can load the steps only for the failed builds?
> 
> We find the console_view and grid_view much more useful? They don't have 
> details of which step failed, but the details of which builder is failing 
> sorted by change, and usually people have been doing one builder per "kind of 
> test"
> 
> You can see the example here, and the categorisation of builders, which I 
> think could be quite useful as a replacement for 
> https://build.webkit.org/waterfall 
> 
> https://nine.buildbot.net/#/console 
> 
> What user might request is probably the reason for failure, which can be done 
> without having to fetch more information (by using the build results_string)
> In the current version you can still click on a build, and have all the 
> information for that build, including tail log of the failing steps (without 
> changing web page)."
> 
> 
> -Aakash
> 
> 
>> On Dec 13, 2017, at 6:51 PM, Aakash Jain > > wrote:
>> 
>> 
>> 
>>> On Dec 11, 2017, at 1:10 AM, Konstantin Tokarev >> > wrote:
>>> 
>>> 
>>> 
>>> 11.12.2017, 02:49, "Carlos Alberto Lopez Perez" >> >:
 On 07/12/17 21:47, Aakash Jain wrote:
>  For people using build.webkit.org  
> >, I would
>  like to know what pages you use most of the time (e.g.: builder page,
>  console view etc.) and what are your primary use-cases (purpose to
>  visit build.webkit.org  
> >). Also if you have
>  any feedback/concern about new Buildbot please let me know.
 
 I use 99% of the time the waterfall view, and I think the new waterfall
 view of buildbot 9 is a step back in terms of usefulness.
 
 More details on about why I think this here:
 https://bugs.webkit.org/show_bug.cgi?id=175056#c1 
 
>>> 
>>> I also use waterfall 99% of time, and new waterfall totally sucks.
>>> 
>>> I wonder if it's possible to get rid of stupid sidebar, if not it's a 
>>> complete
>>> 

Re: [webkit-dev] HSTS user tracking

[Maciej Stachowiak]

Brent Fulgham or John Wilander would know the details.

 - Maciej

> On Jan 5, 2018, at 8:04 AM, Michael Catanzaro  wrote:
> 
> 
> Hi devs,
> 
> Any info about how to mitigate this problem would be appreciated. Thanks!
> 
> Michael
> 
> ___
> webkit-dev 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] Hosting precompiled `jsc` binaries for Linux

[Maciej Stachowiak]

> On Dec 12, 2017, at 12:18 PM, Mathias Bynens <m...@google.com> wrote:
> 
> 
> 
> On Tue, Dec 12, 2017 at 8:52 PM, JF Bastien <j...@chromium.org 
> <mailto:j...@chromium.org>> wrote:
> 
> On Tue, Dec 12, 2017 at 11:42 AM Mathias Bynens <m...@google.com 
> <mailto:m...@google.com>> wrote:
> On Tue, Dec 12, 2017 at 8:38 PM, JF Bastien <j...@chromium.org 
> <mailto:j...@chromium.org>> wrote:
> 
> On Tue, Dec 12, 2017 at 11:27 AM Mathias Bynens <m...@google.com 
> <mailto:m...@google.com>> wrote:
> Ideally, projects such as jsvu wouldn’t have to make such decisions. They 
> would trust the maintainer of the JS engine, in this case Apple, to provide 
> the downloads. 
> 
> If Apple trusts Igalia enough, that’s Apple’s decision. Projects such as jsvu 
> shouldn’t have to duplicate that decision IMHO. The way to do that is to host 
> binaries on an official domain.
> 
> It sounds like our disconnect is on who maintains JSC outside of Apple 
> ecosystems. The GTK port is not maintained by Apple, though we work closely 
> with the maintainers and avoid breakage where we can. 
> 
> JSC is Apple’s JS engine. Who maintains which port of it is a detail that 
> downstream projects should not concern themselves with, IMHO.
> 
> Isn’t that exactly the same as the PPC or S390 versions of V8?
> https://github.com/v8/v8/wiki/Handling-of-Ports 
> <https://github.com/v8/v8/wiki/Handling-of-Ports>
> 
> Or the MIPS version of NaCl?
> 
> I agree this is the same. If I was building an installer that included these 
> ports, I’d prefer to get the downloads through Google/V8 too, if possible.
> 
> On Tue, Dec 12, 2017 at 8:54 PM, Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
> We do not have any Linux binaries blessed, approved or endorsed by Apple, and 
> we never will, regardless of what domain it's hosted on. However, you can get 
> official Linux binaries from parties that own Linux ports.
> 
> If the hosting domain doesn’t matter, would you object to it being webkit.org 
> <http://webkit.org/>? All I meant to say is that this would be my preference.

I would not object. But it's not up to me. It's up to the owners of WebKitGtk 
(or another port that produces a Linux binary), and the people who would have 
to do the engineering and operations work to set it up.

If it comes down to an arbitrary preference for webkit.org <http://webkit.org/> 
over webkitgtk.org <http://webkitgtk.org/>, then you may have to give a better 
reason to convince the people who would actually have to do the work.

Regards,
Maciej

> 
> Just to clarify, I’d be excited to get the downloads at all! I understand who 
> maintains the Linux port, and I appreciate everyone’s hard work on this. 
> ___
> 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] Hosting precompiled `jsc` binaries for Linux

[Maciej Stachowiak]

> On Dec 12, 2017, at 11:42 AM, Mathias Bynens  wrote:
> 
> On Tue, Dec 12, 2017 at 8:38 PM, JF Bastien  > wrote:
> 
> On Tue, Dec 12, 2017 at 11:27 AM Mathias Bynens  > wrote:
> Ideally, projects such as jsvu wouldn’t have to make such decisions. They 
> would trust the maintainer of the JS engine, in this case Apple, to provide 
> the downloads. 
> 
> If Apple trusts Igalia enough, that’s Apple’s decision. Projects such as jsvu 
> shouldn’t have to duplicate that decision IMHO. The way to do that is to host 
> binaries on an official domain.
> 
> It sounds like our disconnect is on who maintains JSC outside of Apple 
> ecosystems. The GTK port is not maintained by Apple, though we work closely 
> with the maintainers and avoid breakage where we can. 
> 
> JSC is Apple’s JS engine. Who maintains which port of it is a detail that 
> downstream projects should not concern themselves with, IMHO.

Hi Matthew,

I think you may be confused about ownership and responsibility. Let me clarify 
who owns what:

* The WebKit Open Source Project ("WebKit") is responsible for the source code 
of WebKit, including the JavaScriptCore JavaScript engine. WebKit does not have 
official releases or official binaries. Apple does much of the engineering work 
for WebKit, but we consider the open source project to be maintained 
collectively by its developers.

* Apple owns the ports for Apple platforms. We ship end-user binary releases of 
the WebKit stack for Apple platforms (macOS, iOS, Apple Windows stack). We also 
ship fortnightly binary preview releases in the form of Safari Technology 
Review. And we provide build archives for our ports, hosted on webkit.org 
.

* Other ports are owned by other entities. The Gtk port is owned by the 
WebKitGTK+ project, with much engineering and support done by Igalia. Non-Linux 
builds can be hosted on webkit.org  too, but that is up to 
port owners.


It sounds like you are asking for Apple-official JSC binaries for Linux, which 
is not something that actually exists. We do not have any Linux binaries 
blessed, approved or endorsed by Apple, and we never will, regardless of what 
domain it's hosted on. However, you can get official Linux binaries from 
parties that own Linux ports.


Regards,
Maciej___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

> On Nov 17, 2017, at 7:53 AM, Frédéric WANG <fred.w...@free.fr> wrote:
> 
> On 17/11/2017 16:26, Maciej Stachowiak wrote:
>> WebKit has a lot of tests that were regression tests for a specific
>> bug fix, not as conformance tests (though they might b useful for that
>> too). In such cases, the association with the bugs.webkit.org bug is
>> more important than the spec URL. That’s particularly the case when
>> the test has been changed multiple times to reflect further WebKit
>> behavior changes. I know that I’ve personally found it very useful to
>> look at revision history of tests, or search for bug numbers or
>> keywords in LayoutTests/ChangeLog to find related tests.
>> Not saying this is the sole purpose of tests, but losing this ability or 
>> making it more awkward would be a downside to deleting tests from the WebKit 
>> repo.
> Well, I think we agree here, that's why "conformance" tests was
> specified in my message. For such tests, connecting the history of tests
> with the development of the specs is actually more important. For
> example I recently noticed that some bugs with WOFF2 (on Apple's ports
> only) and WebVTT have been ignored in WebKit because we don't
> import/sync WPT tests for these specs.

I think importing new test suites is a different question than 
upstreaming/removing tests. In general importing more test suites is probably 
good, but we probably need to tackle the WPT performance problem before we pull 
in too many new WPT suites.

I should also note that pulling in the test suite won't automatically get the 
bugs fixed or prioritized, or even filed in the bug tracker 
necessarily.eratwerATWeRTWAerATWertwAerer

>> Maybe I’m missing something, but isn’t that already how it works in WebKit? 
>> EWS and buildbot run all the tests, but on your own machine you can get 
>> run-webkit-tests to run any subset you want.
> Not everybody has the hardware to produce debug builds of WebKit on all
> existing ports and run a big amount of tests :-)
> 
> AFAIK, EWS run all the builds as well as all the tests on macOS/iOS, you
> don't have options to select a subset of the tests or the ports.
> Buildbots run all the builds & tests on all platforms *after* a patch
> lands in the main repo. So we do too much for WIP patches (extra runtime
> cost I'm mentioning here) and not enough to check the final patch before
> landing (which causes different issues like extra rollout or gardening
> commits or difficult regression bisecting).

I find it super convenient that EWS runs all the tests even on WIP patches. It 
often catches test failures in tests I didn't think to run myself. I think it 
would be great if EWS could run tests on more platforms. Just running release 
regression tests on more platforms would be a big win, if debug builds are the 
gating factor.

I guess it would be kind of neat to have a feature of "run the tests across all 
configurations, but only some of them". But I don't think I would prioritize it 
over having more kinds of tests, or finding ways to make the full test suite 
run faster.

> 
> -- 
> Frédéric Wang - frederic-wang.fr
> 
> 

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

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

[Maciej Stachowiak]

> On Nov 17, 2017, at 7:05 AM, Frédéric WANG  wrote:
> 
> Hi Philip,
> 
> We (at Igalia) are strong supporters of WPT tests and we've appreciated a lot 
> the effort made by Youenn and others to make them possible in WebKit. They 
> are very important for interoperability and make life much easier for 
> developers working on different WebKit ports and different Web engines.
> 
> Ideally, we believe that future conformance tests in WebKit should be written 
> using the WPT format and submitted to web-platform-tests repository (of 
> course there are exceptions when the WPT API is too limited). WPT tests have 
> references to spec URLs and their own git history, so it should always be 
> possible to know why they have been written. This also reduces review cost on 
> WebKit's side, as test review can be done by experts in the relevant specs.

WebKit has a lot of tests that were regression tests for a specific bug fix, 
not as conformance tests (though they might b useful for that too). In such 
cases, the  association with the bugs.webkit.org bug is more important than the 
spec URL. That’s particularly the case when the test has been changed multiple 
times to reflect further WebKit behavior changes. I know that I’ve personally 
found it very useful to look at revision history of tests, or search for bug 
numbers or keywords in LayoutTests/ChangeLog to find related tests.

Not saying this is the sole purpose of tests, but losing this ability or making 
it more awkward would be a downside to deleting tests from the WebKit repo.

> 
> Probably it would be nice to convert old tests to WPT and check duplication 
> to avoid increasing runtime cost but that's indeed going to be a big effort. 
> It could also be possible to improve how the CI tests are executed in the 
> WebKit project, taking inspiration from Chromium or Mozilla projects (i.e. 
> run all tests before a patch lands in the main repo, but allowing devs to run 
> a relevant subset during development).

Maybe I’m missing something, but isn’t that already how it works in WebKit? EWS 
and buildbot run all the tests, but on your own machine you can get 
run-webkit-tests to run any subset you want.

> 
> In any case, Igalia definitely supports this proposal and is happy to help 
> where possible.
> 
> Frédéric, for Igalia's Web Platform Team
> ___
> 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] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

[Maciej Stachowiak]

> On Nov 17, 2017, at 7:15 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 16.11.2017, 20:10, "Alexey Proskuryakov" :
>> Migrating WebKit tests seems undesirable to me, as that would make us lose 
>> all their modification history. As mentioned before, WPT tests are 
>> inherently getting less attention in CI support, largely because of unclear 
>> benefit when there isn't any history for why the particular test was added.
> 
> Possible workaround would be to keep original file path as a comment inside 
> new file. In this case history of ex-WebKit tests can be easily retraced from 
> WebKit repository.

From Apple’s point of view, we are ok with leaving duplicate tests rather than 
removing them, especially when they were created as regression tests for 
specific bugs rather than as broad standards compliance tests.

>> Regression tests are taking an excessive amount of time to run for us (more 
>> than 1.5 hours in a debug build), a very large proportion of which is WPT. I 
>> do not think that the strategy of adopting WPT tests is working well for 
>> WebKit.
> 
> If existing tests are converted to WPT, do they take more time to run? If 
> yes, it's quite unfortunate and needs to be fixed in WPT infrastructure.

I talked to Alexey bout this and he says there is indeed a higher per-test time 
cost, and that it’s a likely fixable problem with the WPT server. If anyone 
fixed this, EWS and buildbot turnaround time would improve significantly.

> 
>> 
>> - Alexey
>> 
>>> 15 нояб. 2017 г., в 2:02, Philip Jägenstedt  
>>> написал(а):
>>> 
>>> Hello webkit-dev! (ecosystem-infra in Bcc)
>>> 
>>> TPAC was last week, and there was much talk about web-platform-tests. Some 
>>> notes are at 
>>> https://lists.w3.org/Archives/Public/public-test-infra/2017OctDec/thread.html
>>>  and in particular https://www.w3.org/2017/11/07-testing-minutes.html.
>>> 
>>> In Blink, we're thinking seriously about what it'd take to upstream large 
>>> parts of LayoutTests into web-platform-tests, and we've realized that there 
>>> are some risks here, beyond just making sure the tests are good and per 
>>> spec. Specifically, one bad outcome would be if Blink successfully 
>>> upstreamed thousands of tests that are also in WebKit, which then begin to 
>>> diverge in small and large ways. That'd leave WebKit with more duplication 
>>> between its own tests and web-platform-tests than any other engine, and a 
>>> headache that grows over time.
>>> 
>>> So, I think this would require close cooperation with the WebKit project. 
>>> Some different ways this might happen:
>>> 
>>> * A Blink developer and WebKit developer work together at the same time to 
>>> move their common tests in some area into web-platform-tests, each removing 
>>> identical tests that were upstreamed by the other and consolidating what 
>>> remains.
>>> * A Blink developer works to first upstream tests from WebKit (using 
>>> WebKit's coming export mechanism), waits for it to be imported into Blink, 
>>> and then removes the tests from Blink.
>>> * The reverse situation.
>>> 
>>> Are there already some areas where the first approach might be doable, 
>>> where the Blink and WebKit folks already know each other and are eager to 
>>> do this? Is LayoutTests/css3/flexbox/ by any chance such a case?
>>> 
>>> I realize it's hard to judge these approaches in the abstract, but am 
>>> curious to hear any enthusiasm or concerns about it.
>>> 
>>> Thanks!
>>> ___
>>> 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
> 
> 
> -- 
> Regards,
> Konstantin
> ___
> 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] Formatting style for inline comments in Python code

[Maciej Stachowiak]

> On Nov 3, 2017, at 8:59 AM, Aakash Jain <aakash_j...@apple.com> wrote:
> 
> 
> 
>> On Nov 2, 2017, at 8:45 PM, Maciej Stachowiak <m...@apple.com 
>> <mailto:m...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Nov 2, 2017, at 5:41 PM, Aakash Jain <aakash_j...@apple.com 
>>> <mailto:aakash_j...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Oct 26, 2017, at 10:21 AM, Maciej Stachowiak <m...@apple.com 
>>>> <mailto:m...@apple.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Oct 26, 2017, at 10:20 AM, Eric Carlson <eric.carl...@apple.com 
>>>>> <mailto:eric.carl...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Oct 26, 2017, at 9:50 AM, Brian Burg <bb...@apple.com 
>>>>>> <mailto:bb...@apple.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 2017/10/26 午前9:21、Alexey Proskuryakov <a...@webkit.org 
>>>>>>> <mailto:a...@webkit.org>>のメール:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> 25 окт. 2017 г., в 18:21, Michael Catanzaro <mcatanz...@igalia.com 
>>>>>>>> <mailto:mcatanz...@igalia.com>> написал(а):
>>>>>>>> 
>>>>>>>> On Wed, Oct 25, 2017 at 4:58 PM, Aakash Jain <aakash_j...@apple.com 
>>>>>>>> <mailto:aakash_j...@apple.com>> wrote:
>>>>>>>>> Does anyone else has any opinion/preference for this?
>>>>>>>> 
>>>>>>>> The number of spaces before a comment really does not matter, but my 
>>>>>>>> $0.02: PEP8 is an extremely common style for Python programs that all 
>>>>>>>> Python developers are familiar with. I would follow that, and forget 
>>>>>>>> about trying to adapt WebKit C++ style to an unrelated language. 
>>>>>>>> Trying to adapt the style checker to ignore particular PEP8 rules 
>>>>>>>> seems like wasted effort.
>>>>>>> 
>>>>>>> 
>>>>>>> There is definitely a number of PEP8 rules that we want to follow. But 
>>>>>>> I don't think that there is anything about the two space before comment 
>>>>>>> rule that makes it particularly fitting for Python.
>>>>>> 
>>>>>> This is entirely subjective, so: why differ from the vast majority of 
>>>>>> all other Python code in existence, just to be different? What's the 
>>>>>> point? PEP8 adherence is nearly universal among projects on PyPi, at 
>>>>>> least among those that run style linters.
>>>>>> 
>>>>>>> I think that we should target WebKit developers with the coding style 
>>>>>>> as much as possible, not Python developers. As we all agree on the one 
>>>>>>> space rule elsewhere, why make a part of the code base uncomfortably 
>>>>>>> different for most WebKit developers?
>>>>>> 
>>>>>> I don't understand the distinction between WebKit developers and Python 
>>>>>> developers. Am I not a C++ developer and web developer as well?
>>>>>> 
>>>>>> If "WebKit developers" want to write Python code, perhaps they should 
>>>>>> learn the Pythonic idioms of the language, just as they would use idioms 
>>>>>> of Perl, JavaScript, and C++. For better or worse, PEP8 encodes many of 
>>>>>> these idioms.
>>>>>> 
>>>>>> If someone already knows Python, they will be tripped up by this 
>>>>>> divergence and waste some minutes trying to satisfy the style checker, 
>>>>>> or just ignore it. If they don't know Python well, then they are being 
>>>>>> conditioned to follow some variant that has no benefit and is different 
>>>>>> from what they would see in any other Python code.
>>>>>> 
>>>>>> I see no value in adding arbitrary barriers to new contributions in 
>>>>>> Python code. The code has enough problems as-is, we don't need to make 
>>>>>> up our own for some pretense of consistency. We import other Python 
>>>>>> projects into the tree, and they follow PEP8, so what was proposed is to 
>>>>>> make the Python code in the tree *less* internally consistent.
>>>>>> 
>>>>> 
>>>>> +1
>>>> 
>>> 
>>> 
>>>> I'm very used to WebKit style for C++, and I agree that we should use PEP8 
>>>> style for Python even where it differs from our C++ style.
>>> 
>>> I personally prefer following PEP8 while writing python.
>>> 
>>> Since people have opinions for both C++ style as well as PEP8 style (and 
>>> comment spacing is anyways a minor thing), I am going to go with Maciej and 
>>> use PEP8 style for Python (which is the style we have already been 
>>> following in webkitpy).
>> 
>> I mean, I agree with this approach, but don't do it just because I said it. 
>> :-) These days, I code less C++ and less Python in WebKit than most people 
>> on this thread.
> 
> I am not doing it only because you said this. I discussed it with Alexey 
> yesterday, and he was fine either way. I personally prefer PEP8. Brian Burg, 
> Michael Catanzaro and Eric Carlson also supported this. That makes most of us 
> (who expressed their opinion) favor this approach.

Sounds good. Do we need to update our style guidelines at all? Maybe just state 
somewhere that for Python our style is PEP8?

 - Maciej

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

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

[Maciej Stachowiak]

> On Nov 2, 2017, at 5:41 PM, Aakash Jain <aakash_j...@apple.com> wrote:
> 
> 
> 
>> On Oct 26, 2017, at 10:21 AM, Maciej Stachowiak <m...@apple.com 
>> <mailto:m...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Oct 26, 2017, at 10:20 AM, Eric Carlson <eric.carl...@apple.com 
>>> <mailto:eric.carl...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Oct 26, 2017, at 9:50 AM, Brian Burg <bb...@apple.com 
>>>> <mailto:bb...@apple.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> 2017/10/26 午前9:21、Alexey Proskuryakov <a...@webkit.org 
>>>>> <mailto:a...@webkit.org>>のメール:
>>>>> 
>>>>> 
>>>>> 
>>>>>> 25 окт. 2017 г., в 18:21, Michael Catanzaro <mcatanz...@igalia.com 
>>>>>> <mailto:mcatanz...@igalia.com>> написал(а):
>>>>>> 
>>>>>> On Wed, Oct 25, 2017 at 4:58 PM, Aakash Jain <aakash_j...@apple.com 
>>>>>> <mailto:aakash_j...@apple.com>> wrote:
>>>>>>> Does anyone else has any opinion/preference for this?
>>>>>> 
>>>>>> The number of spaces before a comment really does not matter, but my 
>>>>>> $0.02: PEP8 is an extremely common style for Python programs that all 
>>>>>> Python developers are familiar with. I would follow that, and forget 
>>>>>> about trying to adapt WebKit C++ style to an unrelated language. Trying 
>>>>>> to adapt the style checker to ignore particular PEP8 rules seems like 
>>>>>> wasted effort.
>>>>> 
>>>>> 
>>>>> There is definitely a number of PEP8 rules that we want to follow. But I 
>>>>> don't think that there is anything about the two space before comment 
>>>>> rule that makes it particularly fitting for Python.
>>>> 
>>>> This is entirely subjective, so: why differ from the vast majority of all 
>>>> other Python code in existence, just to be different? What's the point? 
>>>> PEP8 adherence is nearly universal among projects on PyPi, at least among 
>>>> those that run style linters.
>>>> 
>>>>> I think that we should target WebKit developers with the coding style as 
>>>>> much as possible, not Python developers. As we all agree on the one space 
>>>>> rule elsewhere, why make a part of the code base uncomfortably different 
>>>>> for most WebKit developers?
>>>> 
>>>> I don't understand the distinction between WebKit developers and Python 
>>>> developers. Am I not a C++ developer and web developer as well?
>>>> 
>>>> If "WebKit developers" want to write Python code, perhaps they should 
>>>> learn the Pythonic idioms of the language, just as they would use idioms 
>>>> of Perl, JavaScript, and C++. For better or worse, PEP8 encodes many of 
>>>> these idioms.
>>>> 
>>>> If someone already knows Python, they will be tripped up by this 
>>>> divergence and waste some minutes trying to satisfy the style checker, or 
>>>> just ignore it. If they don't know Python well, then they are being 
>>>> conditioned to follow some variant that has no benefit and is different 
>>>> from what they would see in any other Python code.
>>>> 
>>>> I see no value in adding arbitrary barriers to new contributions in Python 
>>>> code. The code has enough problems as-is, we don't need to make up our own 
>>>> for some pretense of consistency. We import other Python projects into the 
>>>> tree, and they follow PEP8, so what was proposed is to make the Python 
>>>> code in the tree *less* internally consistent.
>>>> 
>>> 
>>> +1
>> 
> 
> 
>> I'm very used to WebKit style for C++, and I agree that we should use PEP8 
>> style for Python even where it differs from our C++ style.
> 
> I personally prefer following PEP8 while writing python.
> 
> Since people have opinions for both C++ style as well as PEP8 style (and 
> comment spacing is anyways a minor thing), I am going to go with Maciej and 
> use PEP8 style for Python (which is the style we have already been following 
> in webkitpy).

I mean, I agree with this approach, but don't do it just because I said it. :-) 
These days, I code less C++ and less Python in WebKit than most people on this 
thread.

Different number of spaces before a same-line comment has never really fazed 
me, the fact that the comment delimiter is different is much more noticeable.


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

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

[Maciej Stachowiak]

> On Oct 26, 2017, at 10:20 AM, Eric Carlson  wrote:
> 
> 
> 
>> On Oct 26, 2017, at 9:50 AM, Brian Burg > > wrote:
>> 
>> 
>> 
>>> 2017/10/26 午前9:21、Alexey Proskuryakov >> >のメール:
>>> 
>>> 
>>> 
 25 окт. 2017 г., в 18:21, Michael Catanzaro > написал(а):
 
 On Wed, Oct 25, 2017 at 4:58 PM, Aakash Jain > wrote:
> Does anyone else has any opinion/preference for this?
 
 The number of spaces before a comment really does not matter, but my 
 $0.02: PEP8 is an extremely common style for Python programs that all 
 Python developers are familiar with. I would follow that, and forget about 
 trying to adapt WebKit C++ style to an unrelated language. Trying to adapt 
 the style checker to ignore particular PEP8 rules seems like wasted effort.
>>> 
>>> 
>>> There is definitely a number of PEP8 rules that we want to follow. But I 
>>> don't think that there is anything about the two space before comment rule 
>>> that makes it particularly fitting for Python.
>> 
>> This is entirely subjective, so: why differ from the vast majority of all 
>> other Python code in existence, just to be different? What's the point? PEP8 
>> adherence is nearly universal among projects on PyPi, at least among those 
>> that run style linters.
>> 
>>> I think that we should target WebKit developers with the coding style as 
>>> much as possible, not Python developers. As we all agree on the one space 
>>> rule elsewhere, why make a part of the code base uncomfortably different 
>>> for most WebKit developers?
>> 
>> I don't understand the distinction between WebKit developers and Python 
>> developers. Am I not a C++ developer and web developer as well?
>> 
>> If "WebKit developers" want to write Python code, perhaps they should learn 
>> the Pythonic idioms of the language, just as they would use idioms of Perl, 
>> JavaScript, and C++. For better or worse, PEP8 encodes many of these idioms.
>> 
>> If someone already knows Python, they will be tripped up by this divergence 
>> and waste some minutes trying to satisfy the style checker, or just ignore 
>> it. If they don't know Python well, then they are being conditioned to 
>> follow some variant that has no benefit and is different from what they 
>> would see in any other Python code.
>> 
>> I see no value in adding arbitrary barriers to new contributions in Python 
>> code. The code has enough problems as-is, we don't need to make up our own 
>> for some pretense of consistency. We import other Python projects into the 
>> tree, and they follow PEP8, so what was proposed is to make the Python code 
>> in the tree *less* internally consistent.
>> 
> 
> +1

I'm very used to WebKit style for C++, and I agree that we should use PEP8 
style for Python even where it differs from our C++ style.

 - Maciej


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

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

[Maciej Stachowiak]

> On Oct 25, 2017, at 1:44 AM, Frédéric WANG <fred.w...@free.fr> wrote:
> 
> On 24/10/2017 18:50, Maciej Stachowiak wrote:
>> I don't have a strong opinion on whether we should support disabling
>> MathML. My point is just that if we support disabling it, it should be
>> a runtime switch, not compile-time.
>> Good reasons to have a compile-time switch would be:
>> - Some ports want the code size savings
>> - It requires back-end code that is not available on all ports
>> 
>> But neither of those is true.
>> 
>> On the other hand, we might still want a runtime switch if some ports would 
>> like to disable the feature for reason of compatibility based on available 
>> fonts. I think it's up to port owners to say whether they want to disable 
>> the feature for this reason.
> Hi,
> 
> I believe it is up to the platform owners to decide whether they want to
> provide math fonts by default ; depending on whether they want to
> privilege disk space or a better user experience.
> 
> However, I still don't see the connection between available fonts and
> enabling MathML support. As I said, some pages with MathML provide the
> necessary WOFF math fonts while others just use basic math (fractions
> etc) where the default text fonts are enough. So the owners would be
> intentionally breaking these pages, just because they don't provide math
> fonts on their platforms ? That sounds weird, to me.

(1) Is it at all common to use MathML with a math font specified as a web font? 
Can you give an example?

(2) Is it at all common to use MathML only to the extent that it's rendered 
fine without a math font?

(3) In the cases above, is there usually an image fallback?

Why don't we wait to hear from port owners whether they would actually want to 
disable MathML for reason of compatibiltiy. Knowing answers to the above 
questions would help.


> 
> Also I think a runtime flag makes sense for the use case of the Tor
> project, but it is a separate use case IMHO and it should not be
> blocking the removal of the compile-time flag.
> 
> So to summarize, I'm happy to submit a patch to remove ENABLE(MATHML) if
> the only reasons were the two points you mention (which as you said are
> not true here). However, if some port owners provide a concrete
> explanation of why they want to keep the option of disabling MathML then
> I don't think I'll have time to check the runtime option right now, so
> I'll just keep the status quo and it will be up to these people to
> submit a patch or to keep fixing the build failures for --no-mathml ;-)
> 
> -- 
> Frédéric Wang - frederic-wang.fr
> 
> 

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

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

[Maciej Stachowiak]

> On Oct 24, 2017, at 12:14 AM, Frédéric WANG <fred.w...@free.fr> wrote:
> 
> On 23/10/2017 18:11, Maciej Stachowiak wrote:
>> 
>> Is there any way we can convert MathML to a runtime switch? It seems
>> like the main consideration is rendering quality given available
>> fonts, rather than code size.
>> 
>> Regards,
>> Maciej
>> 
> @Maciej:
> 
> As I explained, I don't think disabling a HTML5 feature to determine
> which kind of fallback content will be delivered to the user is a good
> idea. Authors can provide Web fonts and for very elementary math (e.g.
> using only simple fractions) you even do not need math fonts at all.

I don't have a strong opinion on whether we should support disabling MathML. My 
point is just that if we support disabling it, it should be a runtime switch, 
not compile-time.

Good reasons to have a compile-time switch would be:
- Some ports want the code size savings
- It requires back-end code that is not available on all ports

But neither of those is true.

On the other hand, we might still want a runtime switch if some ports would 
like to disable the feature for reason of compatibility based on available 
fonts. I think it's up to port owners to say whether they want to disable the 
feature for this reason.


> 
> Anyway, replying to your question the Tor project also added run-time
> preferences for MathML and SVG in Gecko last year:
> 
> https://hg.mozilla.org/mozilla-central/rev/0d48c28cc547
> https://hg.mozilla.org/mozilla-central/rev/7b09464eb767
> 
> IIRC, they basically move the MathML/SVG elements in "unknown"
> namespaces so that the MathML/SVG content and layout classes are not
> used to process them. I believe we could do the same for WebKit. Note
> that their justification is security (users intentionally disable HTML5
> features to "reduce attack surface area") so it's a different use case
> and that one does not make sense to me.

To be clear, I'm not necessarily suggesting a flag exposed to end users. That 
would be weird.

> 
> In any cases, I do not think adding an runtime option for MathML/SVG is
> a prerequisite to remove the build-time option, as the latter was more
> about reducing binary size/dependencies for web engines developers while
> the former was about providing more control to users.
> 
> -- 
> Frédéric Wang - frederic-wang.fr
> 
> 

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

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

[Maciej Stachowiak]

> On Oct 23, 2017, at 9:04 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 23.10.2017, 18:43, "Frédéric WANG"  >:
>> Hi,
>> 
>> There have been some discussions recently on
>> https://bugs.webkit.org/show_bug.cgi?id=177744 regarding the relevance
>> of the compile-time flag for MathML. Discussing with Olivier during the
>> Web Engines Hackfest, it seems he only had disabled MathML in his
>> project because he thought it would reduce binary size. However, he was
>> not really sure this actually had a significant impact. AFAIK, the only
>> dependencies needed for MathML are the font libraries but they are
>> already used for text layout. The implementation is only a few
>> element/rendering files plus some changes here and there.
>> 
>> I'm wondering if other people use the --no-mathml build option and
>> believe they really need it? If not, I'm propose to remove this
>> compile-time flag.
>> 
>> As a comparison, the flag for SVG was removed in
>> https://bugs.webkit.org/show_bug.cgi?id=127991 ; Mozilla also removed
>> compile time option for MathML and SVG a long time ago (
>> https://hg.mozilla.org/mozilla-central/rev/b8664f450508 for the former).
> 
> There is a big difference between SVG and MathML: the first one is entirely 
> self-
> contained, while (AFAIU) MathML requires presence of math fonts on the target
> system for correct rendering (i.e. native MathML will look much worse than 
> image
> fallback that is usually available).
> 
> Imagine embedded system (e.g. of set-top box kind) which has no math fonts on
> the board. Will always-on MathML be progression or regression there?

Is there any way we can convert MathML to a runtime switch? It seems like the 
main consideration is rendering quality given available fonts, rather than code 
size.

Regards,
Maciej

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

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

[Maciej Stachowiak]

> On Sep 13, 2017, at 8:11 AM, JF Bastien  wrote:
> 
> Hello WebCritters,
> 
> I’m moving some code around, and one particular header I have is included 
> everywhere in JSC so I’d like it to be lightweight and include as few other 
> headers as possible. It unfortunately uses WTF::Vector, but it only does so 
> as a pointer:
> 
> void ohNoes(Vector*);
> 
> It seems like something a forward declaration would fix nicely, and oh joy 
> and wonder we have Forward.h just for this! Here’s what it does:
> 
> template minCapacity, typename Malloc> class Vector;
> 
> That’s nice and great for T, but all the other template parameters are SOL 
> because Vector is actually declared with default template parameters:
> 
> template CrashOnOverflow, size_t minCapacity = 16, typename Malloc = FastMalloc>
> class Vector : private VectorBuffer {
> 
> The extra painful thing is that, contrary to what I originally thought, one 
> cannot declare Vector in Forward.h and then define it in Vector.h with the 
> same defaults twice! Ideally the compiler would just yell at a mismatch, but 
> instead it says error: template parameter redefines default argument (thanks 
> clang, that’s exactly what I’m trying to do, just tell me if you catch a 
> mismatch and ODR away otherwise).
> 
> Here’s what I propose:
> 
> Change the forward declaration in Forward.h to contain the default template 
> parameters (and forward-declare CrashOnOverflow).
> Remove these default template parameters from Vector.h.
> Include Forward.h in Vector.h.
> Optionally, if the WebCritters think it useful, leave a comment just above 
> the Vector definition redirecting to Forward.h for defaults (or more fancy, 
> use size_t inlineCapacity /*=0*/ style like LLVM’s codebase does, and have a 
> tool that checks for consistency).
> Optionally, try to fix C++20 so this isn’t A Thing anymore. Note that my 
> hopes are low because of modules (why fix it if modules will magically make 
> this not a thing).
> 
> Alternatively, I could just include Vector.h and be done with it.
> 
> Thoughts?

Is there anything in Forward.h that should not be included everywhere you 
include Vector.h, whether for efficiency or any other reasons? That's the only 
potential thing I can think of that may be wrong with this plan. In that case, 
the simple fix would be to have a separate VectorForward.h which can be 
included by both.

 - Maciej



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

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

[Maciej Stachowiak]

> On Sep 1, 2017, at 10:07 AM, Brady Eidson <beid...@apple.com> wrote:
> 
> 
> 
>> On Sep 1, 2017, at 9:46 AM, Maciej Stachowiak <m...@apple.com> wrote:
>>> 
>>> Does RefPtr do anything for us today that std::optional doesn’t?
>> 
>> The obvious things would be: uses less storage space
> 
> Grumble. If that’s true (which, thinking about it, of course it is true) this 
> is pretty much a nonstarter. So… nevermind.

It might be possible to make a specialization of std::optional that avoids 
the overhead for a separate initialized bool. I'm not sure if it is wise to 
write specializations of standard library template classes though.

Regards,
Maciej


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

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

[Maciej Stachowiak]

> On Aug 30, 2017, at 2:15 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 30.08.2017, 03:01, "Michael Catanzaro" :
>> On Tue, Aug 29, 2017 at 6:20 PM, Alicia Boya García 
>> wrote:
>>>  As long as the sets are generated consistently that approach should be
>>>  equally fine and indeed it would reduce the burden for contributors.
>>>  You
>>>  may need at least a file to write exceptions (files not to be included
>>>  in any bundle) though.
>>> 
>>>  -- Alicia.
>> 
>> I agree, with the style checker to check for naming conflicts within
>> the same directory, and with some help from EWS, automatic generation
>> of bundles should work out fine.
> 
> Note that EWS and webkit-patch run check-webkit-style over *diff* only,
> so it won't be possible to detect such naming conflcts outside of patch
> boundaries with check-webkit-style
> 
> 

To be fully effective, we'd have to have a checker script that looks at the 
source tree too, at least files in the same directory as any touched by the 
patch.

 - Maciej

> 
>> 
>> I'm glad we've discarded the original namespace proposal.
>> 
>> Michael
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> ___
> 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] 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)

[Maciej Stachowiak]

> On Aug 29, 2017, at 6:40 PM, Sam Weinig <wei...@apple.com> wrote:
> 
> 
> 
>> On Aug 29, 2017, at 6:36 PM, Maciej Stachowiak <m...@apple.com 
>> <mailto:m...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Aug 29, 2017, at 5:54 PM, Sam Weinig <wei...@apple.com 
>>> <mailto:wei...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Aug 29, 2017, at 12:46 PM, Geoffrey Garen <gga...@apple.com 
>>>> <mailto:gga...@apple.com>> wrote:
>>>> 
>>>>> This isn’t the scenario I find myself in most often.  A much more common 
>>>>> scenario is working on a change; touch one or two files, and then compile 
>>>>> and test/debug.  Rinse and repeat.
>>>> 
>>>> We’ve already tested this case. The worst case slowdown, if you touch a 
>>>> small file that's in the same bundle as the biggest .cpp file in the 
>>>> project, is 6s => 7s (20%).
>>>> 
>>>> Geoff
>>> 
>>> I see larger than ~6 second build times with this scenario, not measure 
>>> scientifically, but I would approximate it more around 20 - 30 seconds. Do 
>>> you expect the 20% to scale linearly?
>> 
>> Is that just compile time or total build time including build system 
>> overhead? I found that for single-file builds the compile step is less than 
>> half the total time.
> 
> 
> I’m not entirely sure. I usually don’t pay attention to what is happening 
> during the compile.  From doing one right now, it seems to be about 50-50 for 
> one small file.

I've tried to reverse engineer this by comparing compile time after touching 
one file to time after touching two and it seems to support ~50%. Given that, 
I'd estimate the impact to a 20-30 second total time at around 1-2 seconds. 
With more files, your probability of a net win increases. If two files in the 
same AllInOne get changed, you save enough to make up for four singletons 
slowing down.

I agree that the single-file incremental time is already not great but I think 
adopting cmake+ninja as the normal way to build is the only easy way to resolve 
that. Maybe we could even consider making the Xcode project invoke the 
cmake/ninja build instead of doing the Xcode thing at some point, to maximally 
help people who build in the GUI.

 - Maciej

> 
> - Sam
> 
>> 
>> 
>>> 
>>> 
>>> In a completely other direction, what does this mean for use of Xcode? Can 
>>> we still build from Xcode? Debug?
>>> 
>>> - Sam
>>> 
>>> ___
>>> 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] 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)

[Maciej Stachowiak]

> On Aug 29, 2017, at 5:54 PM, Sam Weinig  wrote:
> 
> 
> 
>> On Aug 29, 2017, at 12:46 PM, Geoffrey Garen > > wrote:
>> 
>>> This isn’t the scenario I find myself in most often.  A much more common 
>>> scenario is working on a change; touch one or two files, and then compile 
>>> and test/debug.  Rinse and repeat.
>> 
>> We’ve already tested this case. The worst case slowdown, if you touch a 
>> small file that's in the same bundle as the biggest .cpp file in the 
>> project, is 6s => 7s (20%).
>> 
>> Geoff
> 
> I see larger than ~6 second build times with this scenario, not measure 
> scientifically, but I would approximate it more around 20 - 30 seconds. Do 
> you expect the 20% to scale linearly?

Is that just compile time or total build time including build system overhead? 
I found that for single-file builds the compile step is less than half the 
total time.


> 
> 
> In a completely other direction, what does this mean for use of Xcode? Can we 
> still build from Xcode? Debug?
> 
> - Sam
> 
> ___
> 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] Unified source builds: A new rule for static variables

[Maciej Stachowiak]

> On Aug 29, 2017, at 11:31 AM, Darin Adler  wrote:
> 
> Sent from my iPhone
> 
>> On Aug 29, 2017, at 11:22 AM, Keith Miller  wrote:
>> 
>> I doubt anyone is going to run such a script before they go to upload a 
>> patch to bugzilla. 
> 
> EWS was what I was hoping for; likely to be sufficient. But it could also be 
> integrated into the development process as, say, check-webkit-style is.

check-webkit-style is run by both EWS and webkit-patch upload, in addition to 
being hand-runnable, so that seems like a good place to put this new kind of 
check.

> 
>> So developers will still hit the name collision issue randomly throughout 
>> development.
> 
> Sure.
> 
> But I don’t think that required extensive use of namespaces is the best way 
> to greatly mitigate this. Mistakes will still happen. So I think we shouldn’t 
> go too far in ruining readability of code for something that is not necessary 
> to solve the problem.
> 
> Recommending either namespaces or globally unique names and clarifying that 
> file local scope doesn’t exist are both good.
> 
> But again I think people already handle these problems fine in headers so we 
> don’t need too tight a straitjacket, at least not out of the gate.

I tend to agree with this. I think keeping names of static functions globally 
unique is reasonable, so long as we have an automated way to check. This seems 
better than namespaces. With namespaces, it's still possible to make a mistake, 
such as by having a using at global scope, so we'd need the style checker to 
enforce some kind of rule.
 
If we were to use namespaces, then properly naming them seems better than the 
FILENAME macro.

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

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

[Maciej Stachowiak]

> On Aug 29, 2017, at 9:10 AM, Chris Dumez  wrote:
> 
> I worry about adopting unity build because while it makes clean builds 
> faster, it also slows down incremental builds. As a developer, I rarely do 
> clean builds, I mostly do incremental builds so this would likely make my 
> experience worse?
> Unity builds also require a lot of code churn to resolve naming conflicts and 
> the resulting code does not look as nice.

Given the stats presented, if you're rebuilding at least two files in the same 
slice, you get a speedup. For rebuilding only exactly a single file, you get a 
small slowdown. Your worst case is rebuilding many files but all from a 
separate slice. Not sure how likely this is.

For Apple folks, the penalty would be more than reversed by switching to 
CMake+Ninja as the main building system for engineering builds (which I think 
is the plan?)

 - Maciej

> 
> Finally, the statement that the slow down of incremental build is acceptable 
> because we spend most of our time resolving dependencies seems to assume we 
> keep using make. Using Ninja would speed up incremental builds a lot by not
> re-resolving dependencies so much.
> 
> --
>  Chris Dumez
> 
> 
> 
> 
>> On Aug 29, 2017, at 9:05 AM, Darin Adler > > wrote:
>> 
>>> On Aug 28, 2017, at 8:34 PM, Ryosuke Niwa >> > wrote:
>>> 
 Wherever possible, we are going to want to convert file-static functions
 into private C++ class member functions.
>>> 
>>> I don't think we should make this change. It would mean that whenever
>>> the function signature changes, we'd have to modify the header file,
>>> which in turn triggers rebuild of every cpp file which includes that
>>> header file.
>> 
>> 
>> That was my first thought as well. In fact, I typically ask people to do the 
>> opposite: Whenever a function does not require access to private members, 
>> convert from a member function that has to be in the header file to a 
>> function that is private to the source file.
>> 
>> More recently I have started doing something different for the many 
>> functions that only have to be used on one place; I use lambdas to create 
>> nested functions. This has a couple nice properties: The lambda shares 
>> access to private members and anything else that the surrounding function 
>> has access to. We have the option of capturing rather than passing 
>> arguments, which can be clearer in some cases. It’s not quite as good as a 
>> separate function for visual separation; the lambda is often mashed together 
>> with the rest of the surrounding function.
>> 
>> — 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] 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)

[Maciej Stachowiak]

> On Aug 28, 2017, at 9:20 PM, Daniel Bates  wrote:
> 
> Thank you for looking into speeding up the build.
> 
> How does the speed gain with your proposed "unified source" approach compare 
> to using CMake + Ninja to build currently (I think builder Apple El Capitan 
> CMake Debug does this)?

I think unified sources help in a way that's orthogonal to what CMake+Ninja do, 
so we'd ideally want to apply both to a build of the whole WebKit stack.

Ideally this combination would become the default for engineering builds of the 
macOS and iOS ports.

> Do we know what is the cause(es) for the slow clean builds? I am assuming 
> that much of the speed up from the "unified source" comes from clang being 
> able to use an in-memory #include cache to avoid disk I/O and re-parsing of a 
> seen header. Have we exhausted all efforts (or have we given up?) removing 
> extraneous #includes? Do we think this pursuing this effort would be more 
> time consuming or have results that pale in comparison to the "unified 
> source" approach?

My 2c:

Probably the better long-term solution would be C++ modules once they are ready 
for prime time. In the short term, unified sources seem like a much faster way 
to get a big win than include cleanup. There's also some reason to believe 
unified sources can result in a higher potential win than include pruning, 
since we in fact have many headers that legitimately need to be included in 
lots of files. 


 - Maciej

> 
> 
>> On Aug 28, 2017, at 5:37 PM, Keith Miller  wrote:
>> 
>> Hello fellow Webkittens,
>> 
>> Are you growing tired of long cat naps while waiting 45 minutes for WebKit 
>> to build? (I’ve definitely never done this 蘿!)
>> Do you want WebKit to build up to 3-4x faster on a clean build?*
>> Does seeing your incremental build… stay the same sound good?
>> 
>> You’ll be purring with excitement after you switch to unified source 
>> builds!**
>> 
>> * Building JSC with CMake, including CMake configuration time, went from 
>> ~8m15s to ~2m30s on my MBP using unified sources only on cpp files in 
>> JavaScriptCore. Final results on WebKit may vary. Using unified sources may 
>> cause sudden feelings of euphoria and productivity (or grumpiness from lack 
>> of naps…). Not responsible for any bugs in extra patches produced by using 
>> unified source builds (excluding build system related bugs) except where 
>> required by law (pi...@apple.com).
>> 
>> ** Soon. Unified source builds haven’t been landed yet.
>> 
>> How are things going to change? Great question! Let’s find out!
>> 
>> When you fire off the build script it will automagically paw your source 
>> files into bundles.
> 
> How does this work if you build from Xcode? I am assuming these bundles won't 
> interfere with debugging in Xcode. When debugging in Xcode/lldb/gdb will 
> Xcode/lldb/gdb resolve line information with respect to individual files or 
> the bundles?
> 
>> The size of each bundle is speculatively going to be 8 .cpp files but that’s 
>> up for experimentation. From my testing so far, the compile time for a 
>> bundle is at most 20% (~6s vs ~7s for the Air directory) longer than the 
>> longest file it includes. Given that most of the build time in incremental 
>> builds is scanning dependencies, this change is probably only barely 
>> noticeable.
>> 
>> Bundling happens as part of the CMake configuration process, in the CMake 
>> build. In the Xcode build it’s more complicated since we cannot dynamically 
>> choose the files we are going to compile. The only solution I know of is to 
>> pre-list a bunch of files for the build to dump files into. Occasionally, 
>> we’ll need to add more files to the build list.
>> 
>> When you add or remove a file in the project, the cost is higher. The 
>> current plan to bundle source files is by directory. This means that when a 
>> .cpp file is added or removed you will rebalance the bundles in its 
>> directory, and you will have to rebuild up to the full directory that file 
>> is in. 
>> 
>> My goal is to make all of this invisible to developers as much as possible. 
>> I believe, for the most part, things should operate mostly as they have 
>> before. As the details on unified source builds get finalized, I’m sending 
>> out a separate email documenting any workflow changes. I’ll also do my best 
>> to answer any questions or concerns.
>> 
>> “But Keith, am I going to have to make major changes to the way I develop 
>> WebKit?” Yes and, hopefully, no. There is one major common workflow change 
>> that comes with unified sources, the naming of static variables and 
>> functions.
> 
> I take it you mean any file-level function or definition with internal 
> linkage. That is, this would also affect file-level constants.
> 
>> Since C++ does not have a way to only declare a static function or variable 
>> in some restricted top level scope we are going to need to create some work 
>> around. The choice I’m 

Re: [webkit-dev] CSS Typed OM

[Maciej Stachowiak]

I don't have a strong opinion on the spec itself, but I'd like to encourage you 
to do it using a runtime flag as recommend by the feature policy. 


 - Maciej

> On Aug 18, 2017, at 12:44 PM, Olmstead, Don  wrote:
> 
> Hi,
>  
> I'd like to begin an implementation of CSS Typed OM (CSSOM) and wanted to 
> gauge interest for supporting the feature.
>  
> CSSOM provides typed style access to improve performance by removing the need 
> to do lots of string parsing. Its also the basis of other Houdini 
> specifications so working through it will enable those specifications to be 
> implemented.
>  
> If there's interest I can begin implementation after finishing up some 
> outstanding patches. Any particular pointers on good places to begin are 
> greatly appreciated as this is the first feature we here at Sony have 
> attempted.
>  
> Thanks
> Don
>  
> Spec:
> https://drafts.css-houdini.org/css-typed-om/ 
> 
>  
> WebKit Bugzilla:
> https://bugs.webkit.org/show_bug.cgi?id=175733 
> ___
> 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_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 2, 2017, at 2:18 AM, Ryosuke Niwa  wrote:
> 
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>> Some others I see:
>>> 
>>> ENABLE_GEOLOCATION
>>> ENABLE_INDEXED_DATABASE
>>> ENABLE_CSS_SCROLL_SNAP
>>> ENABLE_WEBGL
>>> ENABLE_WEB_AUDIO
>> 
>> At least these are still not implemented in the Haiku port. I know we
>> are not an upstream port anymore and have little chance of being again
>> as I'm slowly trying to catch up with the lates 1.5 years of
>> development in WebKit. But having to implement all of these would
>> delay my work even more.
>> 
>> As usual, I don't want the Haiku port to pull WebKit backwards, and I
>> do plan to implement some of these at some point. However, being able
>> to disable them at least for some time lets me work on other, more
>> important aspects of the port first.
>> 
>> If the compile time flags are too annoying for that, maybe an
>> alternative would be to provide stub implementations, but then support
>> for these features should still not be advertised to webpages if the
>> port really doesn't support them.
> 
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).

I'm not sure ENABLE_INDEXED_DATABASE quite fits with these other things. It 
doesn't require platform-specific support, the existing back end can use a 
portable storage library. It seems more like the kind of thing that new ports 
should stub out during bring-up than a thing that we might expect to be omitted 
entirely on some ports.

> 
> Perhaps we could merge some build flags though. e.g. we could merge
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
> can only enable both or neither.
> 
> - 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

Re: [webkit-dev] WebVR on WebKit

[Maciej Stachowiak]

Though WebVR is not the most elegant API for VR, it's a least common 
denominator, and it seems like other browsers are on board. So I think it's 
worth at least experimenting with. (Other opinions may vary; this is just my 
personal view not an Official Apple Position or anything).

I'm guessing the hard work here is in implementing the back ends for specific 
platforms and achieving good quality.


Please consider reworking your patch to use a runtime flag instead of a 
compile-time flag. It doesn't seem to meet any of the reasons for using 
compile-time flags that are mentioned in our Feature Policy 
>. Even 
with just the stubs, I think it would fit the guidelines for a default-disabled 
runtime flag. New features should use runtime flags whenever possible IMO.

As an added benefit, if the feature started out runtime switched, it could be 
tested immediately. I bet there's tests that would be relevant even with just 
stubs (at least a simple one of checking what classes and methods are present). 
With runtime flags, you'd be able to have tests in the initial patch.

Regards,
Maciej


> On Aug 2, 2017, at 1:55 PM, Sergio Villar Senin  wrote:
> 
> Hi,
> 
> some weeks ago I uploaded [1] a patch (based on previous work by my
> colleague at Igalia Zan) which basically adds the IDLs for WebVR 1.1
> spec along with the required stubs and the cmake build configuration.
> As Sam Weining perfectly pointed out, this needs some previous
> discussion in the list in order to go ahead.
> 
> WebVR is an API which provides support for exposing virtual reality
> devices (like HMDs) to web apps so that the info coming from those
> devices could be converted into position, orientation and interactions
> with virtual worlds. Note that for a complete VR experience some other
> APIs would be needed as for example de Gamepad API for controller
> support (some extensions were proposed).
> 
> Although the spec[2] mentions that 1.1 is deprecated it is what
> browsers are shipping initially as 2.0 is still in a "do not implement"
> state.
> 
> Regarding interest from other vendors, WebVR is already supported in
> Edge, Firefox nightly and experimental builds of Chromium. Other
> browsers supporting it are Samsung Internet and Oculus Carmel.
> 
> Our main interest is to eventually have some implementation working on
> WebKitGtk and/or WPE on Linux but obviously there is a lot of cross-
> platform work that needs to be done as well. Our initial idea would be
> to use the OpenVR API as Valve released a Linux version of their SDK
> some months ago. Looks like a safe bet as other vendors like Firefox or
> Chromium already include it in their trees as third party.
> 
> WDYT?
> 
> BR
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=174202
> [2] https://w3c.github.io/webvr/spec/1.1/
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Removing support for CSS regions

[Maciej Stachowiak]

> On Aug 2, 2017, at 2:40 AM, Andreas Kling  wrote:
> 
>> 
>> On 2 Aug 2017, at 01:03, Ryosuke Niwa  wrote:
>> 
>> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling  wrote:
>>> Some time has passed, and it seems that adoption of CSS regions on the web 
>>> is not gonna happen.
>>> 
>>> Blink has long since removed their support.
>>> Firefox never supported it AFAIK.
>>> (The new) IE has some amount of support behind a prefix, but no plans to 
>>> unprefix AFAIK.
>>> 
>>> I think it’s time we remove the code from WebKit, and relieve ourselves of 
>>> the maintenance burden.
>>> This should also open up numerous opportunities for clean-up and 
>>> optimization.
>>> 
>>> If you know of any reason to keep the feature, such as a major website or 
>>> WebKit client depending on it, do speak up now!
>> 
>> Since we've been shipping CSS regions for a while, I think the first
>> step we should take would be disabling the feature on trunk, and put
>> that into STP and other ports' releases so that we can easily revert
>> the change if we find out any Web content to be broken when the
>> feature is disabled.
> 
> Hi Ryosuke!
> 
> Unless there is evidence of at least one major site or client depending on 
> CSS regions, I don’t agree that such a slow removal process is necessary.
> 
> IMO doing that would only further increase the maintenance burden incurred by 
> the feature, since we’d have to add tons of runtime checks throughout the 
> codebase.
> 
> I would feel differently if we were pioneering this removal, but since we’ve 
> already seen it succeed in Blink I’m far less concerned.

If we wanted to use extra caution, I think the more useful thing to do would be 
to add telemetry to an STP build instead of doing a test disable and waiting 
for bugs. That's likely to get as an answer much sooner. (It won't tell us 
about content for non-browser apps, but disabling in STP can't tell us that 
either.)

 - Maciej


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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 1, 2017, at 6:55 PM, Adrian Perez de Castro <ape...@igalia.com> wrote:
> 
> Hello,
> 
> On Tue, 01 Aug 2017 18:11:53 -0400, Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
> 
>>> On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>>> 
>>> 02.08.2017, 00:49, "Sam Weinig" <wei...@apple.com>:
>>>>> On Aug 1, 2017, at 6:57 AM, Dean Jackson <d...@apple.com> wrote:
>>>>> 
>>>>>> On 24 Jul 2017, at 22:44, Brian Burg <bb...@apple.com> wrote:
>>>>>> 
>>>>>> Hi WebKittens,
>>>>>> 
>>>>>> In WebKit, the various web-exposed timing APIs–Resource Timing, User 
>>>>>> Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING 
>>>>>> feature flag.
>>>>>> 
>>>>>> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>>>>>> systems by default, and we have not experienced any fallout from 
>>>>>> shipping these features in Safari Technology Preview. I think it’s time 
>>>>>> to remove the feature flag. Are there any objections? Is there a port 
>>>>>> in-tree that’s compiling without this feature?
>>>>>> 
>>>>>> If I don’t hear anything, the flag’s removal will be tracked in 
>>>>>> <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>>>>> 
>>>>> In general I think we should be more enthusiastic about removing feature 
>>>>> flags that are guarding core parts of the Web platform. Web Timing is a 
>>>>> great example.
> 
> In general I agree that build-time feature flags should go away once all ports
> can have the feature enabled by default.
> 
>>>>> Some others I see:
>>>>> 
>>>>> ENABLE_CANVAS_PATH
>>>>> ENABLE_CSS_COMPOSITING
>>>>> ENABLE_CSS_SELECTORS_LEVEL4
>>>>> ENABLE_FETCH_API
>>>>> ENABLE_GEOLOCATION
>>>>> ENABLE_INDEXED_DATABASE
>>>>> ENABLE_STREAMS_API
>>>>> ENABLE_CSS_SCROLL_SNAP
>>>>> ENABLE_WEBGL
>>>>> ENABLE_WEB_AUDIO
>>>>> ENABLE_WEB_SOCKETS
>>>> 
>>>> I think WebGL is still not supported on Windows in WebKitLegacy, so we may 
>>>> need to keep that one.
>>>> 
>>>> I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
>>>> platform, and how many other features depend on it.
>>> 
>>> I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
>>> lots of non-browser applications that need HTML renderer (document viewers, 
>>> mail clients, instant messengers, RSS readers, etc.) which don't need 
>>> video, but also because it greatly raises the bar for implementing new 
>>> ports (e.g. recently announced Android port didn't implement video at that 
>>> time)
>> 
>> I think all of the clients you mentioned actually do need video (or at least 
>> benefit from it). In any case, most clients like that don't usually bundle 
>> their own WebKit. They use a shared copy. Usually a copy that is also used 
>> by a web browser. So if they really want to disable video, they need a 
>> runtime flag, not a compile-time flag.
> 
> Many embedded applications (embedded == not a browser, and the device does
> not have a general-purpose one) ship their own build of WebKit, almost always
> tailored to fit.
> 
> A good example of an use-case that benefits from supporting ENABLE_VIDEO=OFF
> are signage panels (typically some kind of info screens in a public space),
> which most of the time show imagery and textual content, but no video or audio
> at all, running on small embedded computers where on-disk size and memory
> usage matter. For this kind of application it also makes sense to support
> ENABLE_WEB_AUDIO=OFF, as the hardware usually does not even have speakers
> nor any other kind of sound output.
> 
> Moreover, for the WebKitGTK+ disabling both ENABLE_VIDEO and ENABLE_WEB_AUDIO
> does not need GStreamer at all, which further reduces disk and memory usage.
> For example Buildroot includes a WebKitGTK+ recipe which can disable both [1]
> precisely for this reason. So I would also keep ENABLE_WEB_AUDIO.

That sound somewhat more compelling to me than apps for desktop platforms that 
bundle their own WebKit.

Regards,
Maciej

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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 1, 2017, at 6:32 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 02.08.2017, 01:12, "Maciej Stachowiak" <m...@apple.com 
> <mailto:m...@apple.com>>:
>>>  On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>>> 
>>>  02.08.2017, 00:49, "Sam Weinig" <wei...@apple.com>:
>>>>>   On Aug 1, 2017, at 6:57 AM, Dean Jackson <d...@apple.com> wrote:
>>>>> 
>>>>>>   On 24 Jul 2017, at 22:44, Brian Burg <bb...@apple.com> wrote:
>>>>>> 
>>>>>>   Hi WebKittens,
>>>>>> 
>>>>>>   In WebKit, the various web-exposed timing APIs–Resource Timing, User 
>>>>>> Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING 
>>>>>> feature flag.
>>>>>> 
>>>>>>   It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>>>>>> systems by default, and we have not experienced any fallout from 
>>>>>> shipping these features in Safari Technology Preview. I think it’s time 
>>>>>> to remove the feature flag. Are there any objections? Is there a port 
>>>>>> in-tree that’s compiling without this feature?
>>>>>> 
>>>>>>   If I don’t hear anything, the flag’s removal will be tracked in 
>>>>>> <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>>>>> 
>>>>>   In general I think we should be more enthusiastic about removing 
>>>>> feature flags that are guarding core parts of the Web platform. Web 
>>>>> Timing is a great example.
>>>>> 
>>>>>   Some others I see:
>>>>> 
>>>>>   ENABLE_CANVAS_PATH
>>>>>   ENABLE_CSS_COMPOSITING
>>>>>   ENABLE_CSS_SELECTORS_LEVEL4
>>>>>   ENABLE_FETCH_API
>>>>>   ENABLE_GEOLOCATION
>>>>>   ENABLE_INDEXED_DATABASE
>>>>>   ENABLE_STREAMS_API
>>>>>   ENABLE_CSS_SCROLL_SNAP
>>>>>   ENABLE_WEBGL
>>>>>   ENABLE_WEB_AUDIO
>>>>>   ENABLE_WEB_SOCKETS
>>>> 
>>>>  I think WebGL is still not supported on Windows in WebKitLegacy, so we 
>>>> may need to keep that one.
>>>> 
>>>>  I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
>>>> platform, and how many other features depend on it.
>>> 
>>>  I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
>>> lots of non-browser applications that need HTML renderer (document viewers, 
>>> mail clients, instant messengers, RSS readers, etc.) which don't need 
>>> video, but also because it greatly raises the bar for implementing new 
>>> ports (e.g. recently announced Android port didn't implement video at that 
>>> time)
>> 
>> I think all of the clients you mentioned actually do need video (or at least 
>> benefit from it). In any case, most clients like that don't usually bundle 
>> their own WebKit. They use a shared copy. 
> 
> That's not true for Windows, where each application is shipping its own 
> libraries, and is also not true for macOS in case port other than Mac is 
> used. And such "small" applications surely benefit from reduced size and 
> reduced dependencies. 

Chromium Embedded Framework is an obvious comparison project for use cases like 
that. CEF is arguably more popular as a bundled engine than WebKit, so we 
probably don't need more flexibility than they provide. Does CEF let you 
compile out video support?

Regards,
Maciej

> 
>> Usually a copy that is also used by a web browser. So if they really want to 
>> disable video, they need a runtime flag, not a compile-time flag.
>> 
>> The port argument is potentially more compelling. It would carry more weight 
>> if there are platforms that can't supply the required back end at all, or 
>> where support is not expected any time soon. It's ok for new ports to be 
>> initially incomplete, using stubs or extra ifdefs that we wouldn't want 
>> upstream.
>> 
>> Regards,
>> Maciej
>> 
>>>>  - Sam
>>>> 
>>>>  ___
>>>>  webkit-dev mailing list
>>>>  webkit-dev@lists.webkit.org
>>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> 
>>>  --
>>>  Regards,
>>>  Konstantin
>>>  ___
>>>  webkit-dev mailing list
>>>  webkit-dev@lists.webkit.org
>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin

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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 02.08.2017, 00:49, "Sam Weinig" :
>>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson  wrote:
>>> 
  On 24 Jul 2017, at 22:44, Brian Burg  wrote:
 
  Hi WebKittens,
 
  In WebKit, the various web-exposed timing APIs–Resource Timing, User 
 Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature 
 flag.
 
  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
 systems by default, and we have not experienced any fallout from shipping 
 these features in Safari Technology Preview. I think it’s time to remove 
 the feature flag. Are there any objections? Is there a port in-tree that’s 
 compiling without this feature?
 
  If I don’t hear anything, the flag’s removal will be tracked in 
 .
>>> 
>>>  In general I think we should be more enthusiastic about removing feature 
>>> flags that are guarding core parts of the Web platform. Web Timing is a 
>>> great example.
>>> 
>>>  Some others I see:
>>> 
>>>  ENABLE_CANVAS_PATH
>>>  ENABLE_CSS_COMPOSITING
>>>  ENABLE_CSS_SELECTORS_LEVEL4
>>>  ENABLE_FETCH_API
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_STREAMS_API
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>>  ENABLE_WEB_SOCKETS
>> 
>> I think WebGL is still not supported on Windows in WebKitLegacy, so we may 
>> need to keep that one.
>> 
>> I’d like to add ENABLE_VIDEO to that list, given how core it is to the 
>> platform, and how many other features depend on it.
> 
> I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are 
> lots of non-browser applications that need HTML renderer (document viewers, 
> mail clients, instant messengers, RSS readers, etc.) which don't need video, 
> but also because it greatly raises the bar for implementing new ports (e.g. 
> recently announced Android port didn't implement video at that time)

I think all of the clients you mentioned actually do need video (or at least 
benefit from it). In any case, most clients like that don't usually bundle 
their own WebKit. They use a shared copy. Usually a copy that is also used by a 
web browser. So if they really want to disable video, they need a runtime flag, 
not a compile-time flag.

The port argument is potentially more compelling. It would carry more weight if 
there are platforms that can't supply the required back end at all, or where 
support is not expected any time soon. It's ok for new ports to be initially 
incomplete, using stubs or extra ifdefs that we wouldn't want upstream.

Regards,
Maciej



> 
>> 
>> - Sam
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> ___
> 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_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 1, 2017, at 9:57 AM, Dean Jackson  wrote:
> 
> 
> 
>> On 24 Jul 2017, at 22:44, Brian Burg  wrote:
>> 
>> Hi WebKittens,
>> 
>> In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, 
>> and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>> 
>> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
>> systems by default, and we have not experienced any fallout from shipping 
>> these features in Safari Technology Preview. I think it’s time to remove the 
>> feature flag. Are there any objections? Is there a port in-tree that’s 
>> compiling without this feature?
>> 
>> If I don’t hear anything, the flag’s removal will be tracked in 
>> .
> 
> In general I think we should be more enthusiastic about removing feature 
> flags that are guarding core parts of the Web platform. Web Timing is a great 
> example. 

I agree with this sentiment. I think a lot of these should never have been 
compile time flags. They should have been runtime (or at this point not flags 
at all).

Our Feature Policy addresses this: https://webkit.org/feature-policy/ 


"In some cases, compile time flags should be used in addition to or instead of 
runtime flags:
• When merely compiling a feature in significantly impacts the 
hackability or livability of trunk.
• When a feature requires a platform-specific back end that is not 
available on all platforms.
• When some ports or platforms have resource constraints which require 
the ability to remove the feature completely from builds.
• When a feature is otherwise only relevant to some ports or platforms.

That said, runtime flags are preferred whenever feasible."

Most of the flags listed below don't meet any of these conditions, and never 
did. It sounds like a few, like WebGL, might satisfy "When a feature requires a 
platform-specific backend that is not available on all platforms".

For any new features, we should strongly consider using runtime flags whenever 
possible. For many older features, it would be great to convert them to runtime 
flags even if they aren't ready to be enabled everywhere yet. Death to 
compile-time feature flags!

> Some others I see:
> 
> ENABLE_CANVAS_PATH
> ENABLE_CSS_COMPOSITING
> ENABLE_CSS_SELECTORS_LEVEL4
> ENABLE_FETCH_API
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE
> ENABLE_STREAMS_API

For Streams API, I think we're ready for Read Streams to be default on 
everywhere, but not yet Write Streams. I think Write Streams should be compiled 
in but runtime switched off by default until it's up to spec and fully 
qualified. (I don't remember how this maps to the flags exactly).

> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO
> ENABLE_WEB_SOCKETS


Regards,
Maciej




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

Re: [webkit-dev] What's the rationale for not including config.h in any header files?

[Maciej Stachowiak]

> On Jul 31, 2017, at 5:04 PM, Michael Catanzaro  wrote:
> 
> On Mon, Jul 31, 2017 at 9:27 PM, Darin Adler  wrote:
>> I don’t think we should add lots of includes of “config.h”, though. I think 
>> we can come up with something better.
> 
> Like what? The only alternative is to pass defines as preprocessor flags via 
> -D. Our command lines are already hard enough to read as it is. Or, well, we 
> could include config.h in Platform.h, where the ENABLE/USE series of macros 
> are defined.
> 
> I'm curious as to why including config.h in the header file would break 
> Autotools builds. I don't see why that would be the case. As far as I know, 
> it just happens to be common practice to include config.h only in source 
> files. It's special: you always include it first in source files to avoid 
> extremely confusing bugs that can result from not doing so, and therefore it 
> seems redundant to put it in header files.
> 
> I wonder how other projects (and other IDEs, e.g. XCode) handle this 
> situation. Anyway, I don't have a strong opinion either way

I think "config.h" as the first body include, and never in headers, is mostly 
just a stylistic choice in projects that use autotools.

However, here are some specific issues to consider:
(1) Public API headers (or installed private interfaces) should not include 
config.h, and should not rely on any macros defined there.
(2) It's probably ok to include it in non-API headers, at least any that use 
macros defined by config.h.
(3) Implementation files may need to still include config.h. They might not 
include any headers that include config.h, or they might currently but don't 
want to rely on it. config.h may also define macros that affect the behavior of 
system headers and therefore should be included before any of them, so it needs 
to go first.
(4) Given combo of (2) and (3), some includes of config.h in headers may be 
redundant. I am not sure if this causes any practical problems though.

 - Maciej

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

Re: [webkit-dev] Using "auto <function()> -> returnType" breaks prepare-ChangeLog

[Maciej Stachowiak]

> On Jul 28, 2017, at 10:58 AM, Sam Weinig  wrote:
> 
> 
> 
>> On Jul 28, 2017, at 10:31 AM, JF Bastien > > wrote:
>> 
>> 
>> 
>>> On Jul 28, 2017, at 10:29, Sam Weinig >> > wrote:
>>> 
>>> For some generic programming, this form can be dramatically shorter:
>>> 
>>> e.g. 
>>> 
>>> template>> KeyTraitsArg, typename MappedTraitsArg>
>>> template
>>> ALWAYS_INLINE auto HashMap>> MappedTraitsArg>::inlineAdd(K&& key, V&& value) -> AddResult
>>> {
>>> return m_impl.template add>> HashFunctions>>(std::forward(key), std::forward(value));
>>> }
>>> 
>>> vs.
>>> 
>>> template>> KeyTraitsArg, typename MappedTraitsArg>
>>> template
>>> ALWAYS_INLINE typename HashMap>> MappedTraitsArg>::AddResult HashMap>> KeyTraitsArg, MappedTraitsArg>::inlineAdd(K&& key, V&& value)
>>> {
>>> return m_impl.template add>> HashFunctions>>(std::forward(key), std::forward(value));
>>> }
>>> 
>>> It is also the only format available for lambdas, so people are probably 
>>> getting used to it.
>>> 
>>> Not sure it’s worth it to avoid it.
>> 
>> Agreed.
>> 
>> That being said, I’m not volunteering to fix the parser’s handling of 
>> lambdas. At that point we should really consider using clang’s AST.
> 
> I absolutely agree. For this and the style checker, it’s probably time to 
> migrate to clang tooling.

Using a real parser is probably a good idea at some point.

But I am not sure it's necessary for prepare-ChangeLog to know about the 
boundaries for lambdas. It's goal is to list all named functions that the local 
changes have modified. For modifications to the body or signature of a lambda, 
naming the function that contains the lambda is probably the most useful 
option. I think that already works as expected.

Regards,
Maciej



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

Re: [webkit-dev] NPAPI support to remain?

[Maciej Stachowiak]

> On Jul 13, 2017, at 6:23 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> It seems WebKit is the last modern web engine still supporting NPAPI. Is 
> Apple planning to continue supporting NPAPI and WebKitPluginProcess for the 
> foreseeable future? Or is it something that might be removed?
> 
> I am not foolish enough to recommend that anyone use NPAPI, but I am curious 
> about its future in WebKit.

On iOS, we've never supported plugins and don't plan to.

On macOS, Safari has been adding escalating plugin restrictions. Safari hasn't 
announced any plans to ban most or all plugins. It seems like many other 
browsers are moving in the direction of Flash-only. I don't think we'd want to 
run a non-NPAPI Flash, so we could not be able to remove the code unless we 
entirely removed support for all plugins, including Flash.

I personally (and I think also other WebKit folks at Apple) would be against 
implementing any alternative plugin APIs, such as PPAPI. Replacing NPAPI with 
PPAPI would not be a win.

Regards,
Maciej'
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Service workers

[Maciej Stachowiak]

> On Jul 13, 2017, at 6:19 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> We've noticed that service worker support has more than once been a 
> consideration for embedded device manufacturers when choosing between WebKit 
> and Chromium for their products. I see the feature status for service workers 
> is currently listed as "under consideration." Are there technical concerns 
> with this spec? Is it something that would be desirable for WebKit?

Apple engineers from the WebKit team have been heavily involved in 
ServiceWorkers spec discussions over the past few years. Many of our concerns 
with the spec have been addressed, especially for Fetch service workers which 
generally don't run beyond the scope of pages that use them. While we have not 
done any implementation work, the "under consideration" in this case is meant 
literally. We actually are considering it.

More info about who's asking for it and what their use cases are would be 
useful, if you're free to share.

Regards,
Maciej

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

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Maciej Stachowiak]

> On Jun 15, 2017, at 8:01 PM, Brady Eidson <beid...@apple.com> wrote:
> 
> Slight reordering.
> 
>> On Jun 15, 2017, at 5:27 PM, Maciej Stachowiak <m...@apple.com> wrote:
>> 
>> 
>> This is slightly tangential, but a comment on the model: it doesn't seem 
>> like there's a way for clients to check what range of icons are available 
>> and only then choose which to load. Even though Safari may not have needed 
>> this to move over, if you wanted to do something rigorous like load the 
>> closest available size to what you need or else a scalable format, there's 
>> no way to do that without potentially loading icons you don't need. While 
>> Safari hasn't done this, it might be useful if Safari's various places that 
>> display icons are ever made more consistent and coherent.
> 
> This was discussed when implementing the model for Safari, which was 
> admittedly done quickly.
> 
> While Safari didn't need what you suggest right now, they agreed they might 
> need it in the future. Since the load decision request has a completion 
> callback, and since it's a known implementation detail that they will all 
> come in quick succession, it was accepted that the current model could work 
> for "choosing the right icon of all choices" in a pinch.

How are you supposed to do this? Save all the completion handlers indefinitely? 
I can sort of see how that could work, but if the completion handler is 
intended to be used at a possibly later time than the 
shouldLoadIconWithParameters: method, it's kind of weird that it's a callback 
at all.

> 
>> I can see that there needs to be some per-icon notification, since  
>> elements can be added after the fact, and also incremental parsing is a 
>> thing. So one notification that tells you all icons wouldn't cut it.
> 
> Right - The "just one icon" notification was the bare minimum because of this 
> need.
> We can definitely add a greater API surface to deliver a bulk "here's all the 
> icons in the " in addition to the individual icon notification.
> 
>> Another minor comment: it seems like this new API returns raw data. It seems 
>> like the native way to use this would result in running untrusted data from 
>> the network through image decoders outside the Web Process sandbox. Do we 
>> have a way to avoid that?
> 
> This came up while implementing it for Safari, too. In practice we didn't 
> decode icons out-of-process before so this model was not a regression. I see 
> value in offering this, but it's also something conscientious clients can do 
> on their own with the raw data.

It's not that easy for an arbitrary macOS app to make their own tightly 
sandboxed service for this, and probably impossible on iOS. So if we made this 
interface into public API, there wouldn't be a way for most clients to do the 
right thing.

> 
> Also...
> 
>> But separating the loading mechanism from the notification, plus adding a 
>> notification that the  section is done parsing, could allow avoidance 
>> of unnecessary loads. In addition, there could be other useful future uses 
>> of a mechanism to properly load a resource as if it was being loaded by the 
>> page. So it would be nice to decouple this from the notification of 
>> discovering an icon link.
> 
> That's the full-on tangent!
> 
> As you know, "load an arbitrary subresource in the context of the page" has 
> come up plenty of times over the history of the WK API, so it does seem like 
> there's value here. 
> Offering that, however, does seem to make the "decode the icon image out of 
> process" less of a fit with a general purpose API.

Yeah, we'd either have to provide a generic image decoding service or make a 
generic loading facility that's capable of vending decoded image data instead 
of raw data, which both seem a bit inelegant.

>> Asking these questions because if this is to be the One True Model of icon 
>> loading going forward, we should try to make sure the design is future-proof.
> 
> Yes, these are all great questions to ask. 
> 
> Everything that's been brought up so far only really touches the API surface 
> (Do we batch together icon load decision requests? Do we give an 
> out-of-process decoded image instead of raw data? Do we offer an API for 
> loading arbitrary subresource?)
> 
> Speaking with understanding of what's implemented today and what would be 
> necessary to make any or all of these changes, I know that the current 
> mechanism is a solid base on which these ideas can easily be built.

OK, as long as we still have room to address these issues before it becomes 
locked in as public API, then I am fine with not addressing these issues for 
now.

Regards,
Maciej



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

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Maciej Stachowiak]

This is slightly tangential, but a comment on the model: it doesn't seem like 
there's a way for clients to check what range of icons are available and only 
then choose which to load. Even though Safari may not have needed this to move 
over, if you wanted to do something rigorous like load the closest available 
size to what you need or else a scalable format, there's no way to do that 
without potentially loading icons you don't need. While Safari hasn't done 
this, it might be useful if Safari's various places that display icons are ever 
made more consistent and coherent.

I can see that there needs to be some per-icon notification, since  
elements can be added after the fact, and also incremental parsing is a thing. 
So one notification that tells you all icons wouldn't cut it.

But separating the loading mechanism from the notification, plus adding a 
notification that the  section is done parsing, could allow avoidance of 
unnecessary loads. In addition, there could be other useful future uses of a 
mechanism to properly load a resource as if it was being loaded by the page. So 
it would be nice to decouple this from the notification of discovering an icon 
link.


Another minor comment: it seems like this new API returns raw data. It seems 
like the native way to use this would result in running untrusted data from the 
network through image decoders outside the Web Process sandbox. Do we have a 
way to avoid that?


Asking these questions because if this is to be the One True Model of icon 
loading going forward, we should try to make sure the design is future-proof.


Regards,
Maciej


> On Jun 15, 2017, at 5:11 PM, Brady Eidson  wrote:
> 
> Hi all,
> 
> The IconDatabase in WebCore is the source of crashes, spins, and complexity. 
> Additionally it’s not flexible enough to acknowledge that there’s multiple 
> types of site icons in use on the modern web, nor to adapt to the embedding 
> client’s need for customization.
> 
> I recently introduced the “_WKIconLoadingDelegate” model to WebKit2Cocoa.
> 
> WebCore gathers all of the candidate icon URLs and asks the embedding app for 
> each one whether or not it wants to load them.
> If the app says yes, the icon will be loaded as a subresource in the current 
> document and the data will be handed off to the client.
> 
> From Apple’s perspective:
> 
> The new model is powerful and flexible enough that Safari has adopted it.
> In WebKit1, the “WebIconDatabase” class was never API and is currently unused.
> In WebKit2, the C-API support was never API and is currently unused.
> 
> Therefore we intend to remove the current WebCore IconDatabase from the 
> project soon.
> 
> Starting in on this task, I of course noticed GTK’s API has exposed 
> “WebKitFaviconDatabase”
> 
> Is that something that’s published API and that is used?
> If not, I can get rid of it right now
> 
> If so, then I need a GTK maintainer to come up with a plan soon.
> 
> The icon load delegate mechanism is powerful enough to rebuild an 
> IconDatabase on top of, so if GTK needs to keep this API functional they can 
> do so - maintaining the actual IconDatabase code themselves up in their API 
> layer.
> 
> Thanks,
> ~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] Should we ever use std::function instead of WTF::Function?

[Maciej Stachowiak]

In case it turns out not to be possible to reduce the number of concepts 
(besides eliminating std::function), maybe it would help to change the names 
and behaviors of these classes to match better. Function, SharedFunction and 
ScopedFunction would have a much more obvious relationship to each other than 
Function, SharedTask and ScopedLambda. 

(I'm not sure if the direct assignment from a lambda is an incidental 
difference or one that's required by the different ownership semantics.)

 - Maciej

> On Jun 13, 2017, at 9:34 AM, Filip Pizlo  wrote:
> 
> We should have a better story here.  Right now the story is too complicated.  
> We have:
> 
> - ScopedLambda or ScopedLambdaRef if you have a stack-allocated function that 
> outlives its user
> - SharedTask if you have a heap-allocated function that you want to share and 
> ref-count
> - WTF::Function if you have a heap-allocated function that you want to 
> transfer ownership (move yes, copy no)
> - std::function if you have a heap-alloated function that you want to pass by 
> copy
> 
> Only std::function and WTF::Function do the magic that lets you say:
> 
> std::function f = 
> 
> Also, std::function has the benefit that it does copying.  None of the others 
> do that.
> 
> ScopedLambda serves a specific purpose: it avoids allocation.  Probably we 
> want to keep that one even if we merge the others.
> 
> IMO SharedTask has the nicest semantics.  I don’t ever want the activation of 
> the function to be copied.  In my experience I always want sharing if more 
> than one reference to the function exists.  I think that what we really want 
> in most places is a WTF::Function that has sharing semantics like SharedTask. 
>  That would let us get rid of std::function and SharedTask.
> 
> In the current status quo, it’s not always correct to convert std::function 
> to the others because:
> 
> - Unlike ScopedLambda and SharedTask, std::function has the magic constructor 
> that allows you to just assign a lambda to it.
> - Unlike ScopedLambda, std::function is safe if the use is not scoped.
> - Unlike WTF::Function, std::function can be copied.
> 
> -Filip
> 
> 
>> On Jun 13, 2017, at 9:24 AM, Darin Adler  wrote:
>> 
>> I’ve noticed many patches switching us from std::function to WTF::Function 
>> recently, to fix problems with copying and thread safety.
>> 
>> Does std::function have any advantages over WTF::Function? Should we ever 
>> prefer std::function, or should we use WTF::Function everywhere in WebKit 
>> where we would otherwise use std::function?
>> 
>> — 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] "ReflectOnly" IDL equivalent

[Maciej Stachowiak]

> On Jun 9, 2017, at 10:08 PM, Chris Dumez  wrote:
> 
> 
>>> On Jun 9, 2017, at 11:47 AM, Sam Weinig  wrote:
>>> 
>>> 
>>> 
>>> On Jun 2, 2017, at 11:32 AM, Ryosuke Niwa  wrote:
>>> 
 On Fri, Jun 2, 2017 at 9:18 AM, Chris Dumez  wrote:
 Hi,
 
 No, I do not believe WebKit supports ReflectOnly and this is not standard
 IDL either.
 
 The way to do it in WebKit would be to use a regular DOMString attribute, 
 as
 in the specification and implement this logic in the c++ getter for this
 attribute. See HTMLElement::dir() for an example.
 
 We could also consider adding support for something like ReflectOnly in our
 bindings generator considering that this seems to be used quite a bit in 
 the
 HTML specification and it would decrease code complexity a little.
 I’d actually be in favor of that.
>>> 
>>> I'd suggest other names like "ReflectEnum" or even "Reflect"
>>> where EnumType is the name of enum that defines the list of values.
>>> 
>>> "ReflectOnly" doesn't tell us on what "only" applies. If I didn't know
>>> the context, it sounds like something that does less work than regular
>>> "Reflect”.
>> 
>> 
>> I don’t see a good reason to complicate the bindings until this becomes more 
>> common place.  For now, I would just implement HTMLLinkElement::as() to 
>> behave as you want and leave the IDL unannotated, and we can revisit it at a 
>> later time.
> 
> As I said, this is already used in quite a few places in the HTML spec:
> - https://html.spec.whatwg.org/#dom-dir
> - https://html.spec.whatwg.org/#dom-link-as
> - https://html.spec.whatwg.org/#dom-link-referrerpolicy
> - https://html.spec.whatwg.org/#dom-link-updateviacache
> - https://html.spec.whatwg.org/#dom-a-referrerpolicy
> - https://html.spec.whatwg.org/#dom-img-referrerpolicy
> - https://html.spec.whatwg.org/#dom-iframe-referrerpolicy
> - https://html.spec.whatwg.org/#dom-track-kind
> - https://html.spec.whatwg.org/#dom-media-preload
> - https://html.spec.whatwg.org/#dom-area-referrerpolicy
> - https://html.spec.whatwg.org/#dom-th-scope
> - https://html.spec.whatwg.org/#dom-form-autocomplete
> - https://html.spec.whatwg.org/#dom-input-type
> - https://html.spec.whatwg.org/#dom-input-inputmode
> - https://html.spec.whatwg.org/#dom-button-type
> - https://html.spec.whatwg.org/#dom-textarea-inputmode
> - https://html.spec.whatwg.org/#dom-fs-method
> - https://html.spec.whatwg.org/#dom-fs-enctype
> - https://html.spec.whatwg.org/#dom-fs-formenctype
> - https://html.spec.whatwg.org/#dom-fs-formmethod
> 
> Having a per-standard implementation in the bindings would likely be better 
> than many potentially non-compliant ones.

The HTML spec's name for this concept, "limited to only known values" is really 
clear and better than "only" or "enum". I wonder if we could make a name based 
on this, such as

ReflectLimitedToKnownValues
ReflectOnlyKnownValues
ReflectKnownValues
ReflectLimited

(The last of this might be too vague.)

> 
> --
>  Chris Dumez
> 
> ___
> 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] Where do we put WPT tests to be exported

[Maciej Stachowiak]

> On May 18, 2017, at 2:08 PM, Philip Jägenstedt  wrote:
> 
> On Tue, May 16, 2017 at 5:38 PM youenn fablet  > wrote:
> 
> There was a suggestion that LayoutTests/imported/w3c/web-platform-tests be 
> moved to a shorter path like LayoutTests/web-platform-tests. That would also 
> make it clear that this folder is not only about one-way-sync.
> 
> In Blink we renamed it to LayoutTests/external/wpt/ to avoid the "read only" 
> implications of the old name.

If we go forward with two-way sync, I think this is a good name.

Regards,
Maciej


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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

> On May 16, 2017, at 1:16 AM, Ryosuke Niwa  wrote:
> 
> On Mon, May 15, 2017 at 11:57 PM, Anne van Kesteren  wrote:
>> On Tue, May 16, 2017 at 7:29 AM, Ryosuke Niwa  wrote:
>>> Given we're talking about how these tests are ran inside WebKit,
>>> whether there is an agreement about this or not is sort of irrelevant.
>>> If a test doesn't run as expected, we can run it inside a HTTP server.
>> 
>> I was just trying to help clarify why what makes sense for WebKit,
>> might not make sense for tests designed to run on all engines. If
>> that's not desired here, I'll stop.
> 
> Sure, I don't think we're interested in changing the way tests are ran
> elsewhere.
> 
> It would be great if upstream web-platform-tests could use relative
> paths whenever possible or allowed annotation (e.g. we'd add such
> annotation) as to which tests could be ran locally via file URL.
> 
> However, that's more or less a secondary concern (nice-to-have)
> whereas how web-platform-tests are imported and ran in WebKit are a
> lot more important to us due to the impact it has on our development
> process, tooling, as well as the maintenance cost.

I agree with Ryosuke. We don't want to impose on others, but these two changes 
would be convenient for WebKit's use. Perhaps somewhere in WPT space (a GitHub 
issue?) would be the appropriate venue to discuss it. I am assuming here the 
tradeoff is just the maintenance burden of keeping the relative paths up to 
date, but maybe there is some deeper reason not to do it.

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

Re: [webkit-dev] Where do we put WPT tests to be exported

[Maciej Stachowiak]

> On May 15, 2017, at 9:08 PM, youenn fablet  wrote:
> 
> I see two main cases:
> - Writer of the patch is making sure to upstream WPT test changes at WebKit 
> landing time. It is ok to make the changes directly in 
> LayoutTests/imported/w3c/web-platform-tests/
> - Writer plans to upstream WPT test changes at some point but wants more 
> time. It is better to develop the tests in LayoutTests/http/wpt and then 
> migrate them later on.

My proposal was different from either of these, it was to have a directory 
specifically for tests meant to be upstreamed (LayoutTests/http/wpt should 
contain only tests not meant

I think adding new tests directly to 
LayoutTests/imported/w3c/web-platform-tests/ is needlessly messy. Most stuff in 
the imported/ directory is an exact copy of an upstream test suite, so if you 
run only a specific directory of tests, you know you are running an official 
conformance suite. With this proposal, it might also contain random tests that 
will hopefully be upstreamed but maybe not, or might be changed before the PR 
lands upstream, or might get renamed, or whatever. There's no guarantee that 
updating from the official version will ever fully resolve the delta. 

I think it would be more elegant to have a parallel directory 
(LayoutTests/for-export/w3c/web-platform-tests). Then when something is 
actually upstreamed and then pulled back down, we could delete the staged 
version. Directly modifying our local copy seems like it could easily lead to 
long-term divergences slipping through the cracks.

Of course, people could always go run the official copy from w3c-test.org 
 . But we usually leave imported conformance test suites 
unmodified except the minimum necessary to make them run.

> I would start with an experimental phase with some of us making direct 
> changes in LayoutTests/imported/w3c/web-platform-tests/.
> When we are happy with the tools and think the risk for issues is low enough 
> (or when the bots can handle most of it for us), hacking 
> LayoutTests/imported/w3c/web-platform-tests/ could be the default.

I think the problem with this plan is not tools risk, it's the fact that a 
directory of imported tests can no longer be trusted to actually just be 
imported tests. So a smaller number of people doing it to start would not 
address my concern. It might be that other people don't care about this. My 
opinion counts no more than anyone else's, and I'd be interested in hearing 
from others.

Regards,
Maciej

> 
> Le lun. 15 mai 2017 à 21:02, Ryosuke Niwa  > a écrit :
> Hi all,
> 
> Youenn is working on a patch to automatically create a GitHub PR to
> export tests from a WebKit patch which includes changes to
> web-platform-tests [1].
> 
> That raises a question as to where we should put new tests or modified
> tests intended to be exported to web-platform-tests from WebKit.
> 
> I think the most obvious option is to use
> LayoutTests/imported/w3c/web-platform-tests/.  However, in the other
> thread about adopting testharness.js (titled Another WPT bite), Maciej
> briefly expressed the preference for creating a new directory:
> https://lists.webkit.org/pipermail/webkit-dev/2017-May/029022.html 
> 
> 
> Do other people have strong opinions about this?
> 
> - R. Niwa
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=169462 
> 
> ___
> 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] Another WPT bite

[Maciej Stachowiak]

> On May 13, 2017, at 5:26 PM, Michael[tm] Smith <m...@w3.org> wrote:
> 
> Maciej Stachowiak <m...@apple.com>, 2017-05-13 14:58 -0700:
>> ... From what I gather, there are a lot of tests where only the paths to
>> the test harness end up requiring the server.
> 
> Yeah that’s the case for the vast majority of tests. Relatively few — less 
> than
> 5% altogether, I’d estimate — actually rely on any special server behavior.
> 
> Of the ones needing special server behavior, I think even there by far most 
> are
> just cases of an accompanying foo.html.headers file in the tree along with the
> foo.html test, to specify that the server send particular response headers.
> 
> Out of ~50,000 test files in WPT, there are less than 1000 with a .headers 
> file.
> 
> I think the next-most-common case that require special server behavior are 
> cases
> where the server is doing some parsing and substitution of special parameters.
> In those cases the test file itself will be named in the pattern foo.sub.html,
> or one of its JS assets in the pattern foo.sub.js.
> 
> Out of ~50,000 test files in WPT, less than 300 are *.sub.* files.
> 
> So those two cases take together amount to only 3% of the total. So even with
> whatever else I’m missing added to that I’d estimate the number of tests that
> don’t rely on special server behavior is on the order of 95%.
> 
> So those ~95% all only need the “/resources/testharness.js” path to the test
> harness to resolve and then they’ll just work.
> 
>> Doing the fixup on import seems bad to me, since it seems safer and
>> cleaner for our WPT checkout to match WPT. But we could follow the
>> practice of using relative URLs for self-created tests, and perhaps not
>> even run them under the server when they don't need it.
>> 
>> For upstream, perhaps we could advocate with WPT to use relative paths to
>> load the harness
> 
> Given that a specific problem case Alexey mentioned was linking to tests 
> within
> the WebKit Trac and having them run as expected, I wonder if at least y’all
> could find a way to just make https://trac.webkit.org/resources/testharness.js
> work — I guess by making it redirect to some place where you have a current 
> WPT
> checkout. That’d at least solve things for the main specific case that’s been
> brought up so far being a real problem.

Alexey mentioned trac because it's something we couldn't easily solve with a 
command-line tool. The far more common case is engineers loading individual 
test cases to debug them. As you mentioned ~95% of test cases would load fine 
as a local file, except for the path where they expect testharness.js.

For the engineer use case, we can make a command-line tool to launch the server 
and load the test. But it's kind of sad that in ~95% of cases, the only value 
provided by the server is resolving the path to testharness.js. If tests 
referenced testharness.js via relative path, then most of the time they could 
be loaded as local files just fine, which would be more convenient (as well as, 
I believe, solving the "external trac link" issue).


>> (and perhaps make sure that tests that absolutely require the server fail in 
>> a
>> way that clearly indicates this for the tests that truly do need networking 
>> or
>> some other facility of the WPT server).
> 
> Yeah that would be good to make happen in general regardless. But I think 
> right
> now that maybe can mostly be (programatically) determined by (1) checking if 
> the
> name of the test file itself is in the *.sub.* pattern, or (2) checking to see
> if there’s an accompanying *.headers file for the test.

It would only be relevant for tests to give better diagnostics if they were set 
up to run outside the WPT server at all, which they aren't. This suggestion is 
somewhat conditional on consideration of that other suggestion (which is 
basically to load required static resources via relative path).

Regards,
Maciej

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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

> On May 12, 2017, at 7:49 PM, a...@webkit.org wrote:
> 
> 
>> 12 мая 2017 г., в 19:38, Brian Burg > > написал(а):
>> 
>>> I think that I explained it very clearly, but let me try again.
>>> 
>>> When there is a test failure that I need to communicate to others, I say 
>>> something "please open 
>>> >>  
>>> >
>>>  in Safari to reproduce". That's very easy to do, and makes it very easy 
>>> for others to work on the issue.
>>> If your test requires complex setup, like WPT does, then I may not have the 
>>> time to write up complicated steps to reproduce, or the person who gets the 
>>> bug may not have the time to follow them. Those people don't have a WebKit 
>>> checkout, so scripts won't help. This makes the test less effective, as 
>>> problems that it finds are less likely to be addressed.
>> 
>> If the person works on WebKit, then it seems unreasonable that they would do 
>> work without a checkout.
> 
> It is correct that people who work on WebKit usually have a checkout. So I 
> was taking about people who don't work on WebKit.
> 
>> If they don’t work on WebKit, then you could run wptserve on a machine 
>> somewhere and link to that copy. We have several servers that exist solely 
>> to host test content, it doesn’t seem like a big deal to make one of them 
>> update regularly and relaunch wptserve to pick up test harness changes.
> 
> Yes, there is a number of things one could do. Those things would work in 
> some cases but not in others - I mentioned linking to a stable version that 
> won't change, which is something that trac gives us for free, and it would be 
> non-trivial to implement otherwise.
> 
> In practice, the best approach would be to reduce the test to a minimum that 
> doesn't use complex harnesses before ending it over. Everyone likes minimal 
> test cases.

I think WPT is becoming enough of a broad community norm that it's not 
unreasonable to point to a WPT server. It does seem regrettable that tests 
become dependent on being run through the server even when in principle they 
could run as local files. From what I gather, there are a lot of tests where 
only the paths to the test harness end up requiring the server. Doing the fixup 
on import seems bad to me, since it seems safer and cleaner for our WPT 
checkout to match WPT. But we could follow the practice of using relative URLs 
for self-created tests, and perhaps not even run them under the server when 
they don't need it.

For upstream, perhaps we could advocate with WPT to use relative paths to load 
the harness (and perhaps make sure that tests that absolutely require the 
server fail in a way that clearly indicates this for the tests that truly do 
need networking or some other facility of the WPT server).

Regards,
Maciej

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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

> On May 12, 2017, at 2:39 PM, Ryosuke Niwa  wrote:
> 
> On Fri, 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.
> 
> This is absolutely not how I operate at all. Since almost all custom
> elements and shadow DOM API tests I wrote are written using
> testharness.js and upstreamed to web-platform-tests, they have been
> deleted from LayoutTests/fast/shadow-dom &
> LayoutTests/fast/custom-elements.
> 
> As such, if any new shadow DOM or custom elements tests under
> LayoutTests/imported/ start to fail, then we must fix them since we
> idon'thave any other test coverage.

Our normal approach to imported conformance test suites is to treat them as 
seriously as any other test. Even when a test was originally written along with 
a specific bug report, we don't necessarily think about that when prioritizing 
its importance, since it often fails in a way that does not make clear whether 
the exact origins bug is back.

It seems like there's two unusual things about WPT:
- We pull from upstream more often, and upstream is evolving at a good pace. So 
it's more of a moving target than something like the old W3C DOM test suite.
- At least according to Alexey, WPT tests are somewhat prone to flakiness in 
Safari.

It seems like the first issue is something we need to adapt to, to get the best 
value from WPT. But the second issue is something that has to be resolved 
within WPT (perhaps with our help). We can't have a lot of our testing depend 
on a flaky process.


This is separate from the issues about ease of running those tests. On that, I 
agree with Sam:

> On May 12, 2017, at 2:38 PM, Sam Weinig  wrote:
> 
> I regret piling on here, as I think this thread has diverged from it’s 
> original purpose, but…I understand this frustration. That said, perhaps this 
> is something we can solve with some tooling. For instance, a 
> run-test-in-safari (as a parallel to run-safari) script could be made which 
> starts the server, and then loads the test with the right URL in your built 
> Safari (or MiniBrowser, or whatever).  


I think the pain can be reduced with tooling. The right tools might need to be 
a bit more subtle. You might want to reload the test repeatedly in the same 
Safari instance, or perhaps load it into already-running Safari. So maybe 
load-test-in-safari (that ensures the server is running or launches it, then 
loads the right URL for a test, and maybe even does the right thing for http, 
web sockets or plain-file tests) would be closer to the mark. It may still be a 
little inconvenient but it seems like we can make it significantly better.

Regards,
Maciej

[webkit-dev] Also in the tradition of massive renames

[Maciej Stachowiak]

I'd like to propose the following directory renames for consideration:

Source/WebKit --> Source/WebKitLegacy (or alternately, LegacyWebKit for 
autocomplete happiness, but maybe not if we keep the LayoutTests name)
Source/WebKit2 --> Source/WebKit

Reasons:
- Matches the current names of the build products of these directories in 
Apple's ports
- Most non-Apple ports are based on WebKit2 but produce libraries that are just 
called WebKit

I've discussed this with folks internally at Apple to make sure there are no 
blockers. We believe we could execute this change sometime in the next few 
months, if there was general agreement. We believe SVN and git will be able to 
follow history across the move.

Regards,
Maciej


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

Re: [webkit-dev] Rename LayoutTests

[Maciej Stachowiak]

> On May 10, 2017, at 2:51 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 10.05.2017, 12:42, "Ryosuke Niwa" <rn...@webkit.org 
> <mailto:rn...@webkit.org>>:
>   On Wed, May 
> 10, 2017 at 2:14 AM, Ryosuke Niwa < 
> rn...@webkit.org <mailto:rn...@webkit.org>> 
> wrote:
>>>  On Wed, May 10, 2017 at 12:02 AM, Maciej Stachowiak <m...@apple.com 
>>> <mailto:m...@apple.com>> wrote:
>>>>  IntegrationTests doesn't distinguish them from performance tests, or API
>>>>  tests. And most test integration only incidentally. FunctionalTests 
>>>> doesn't
>>>>  distinguish them from any of the other kinds of tests besides performance
>>>>  tests.
>>>>  I think just plain Tests is better than calling out a characteristic that
>>>>  isn't actually unique. It's by far the most common type of test we have, 
>>>> so
>>>>  it's ok for it to be the unmarked category.
>>>  The problem with Tests is that it competes with Tools.
>>>  (Renaming Tools is a lot harder not to mention it's a pretty
>>>  descriptive name already).
>>>  How about CorrectnessTests or CoreTests then?
>> I guess another name along this line would be RegressionTests.
> 
>> On Wed, May 10, 2017 at 2:14 AM, Ryosuke Niwa <rn...@webkit.org 
>> <mailto:rn...@webkit.org>> wrote:
>>>  On Wed, May 10, 2017 at 12:02 AM, Maciej Stachowiak <m...@apple.com 
>>> <mailto:m...@apple.com>> wrote:
>>>>  IntegrationTests doesn't distinguish them from performance tests, or API
>>>>  tests. And most test integration only incidentally. FunctionalTests 
>>>> doesn't
>>>>  distinguish them from any of the other kinds of tests besides performance
>>>>  tests.
>>>> 
>>>>  I think just plain Tests is better than calling out a characteristic that
>>>>  isn't actually unique. It's by far the most common type of test we have, 
>>>> so
>>>>  it's ok for it to be the unmarked category.
>>> 
>>>  The problem with Tests is that it competes with Tools.
>>>  (Renaming Tools is a lot harder not to mention it's a pretty
>>>  descriptive name already).

It has a two-letter disambiguation at least, which is better than what you get 
for WebCore / WebKit / WebKit2.

>>> 
>>>  How about CorrectnessTests or CoreTests then?
>> 
>> I guess another name along this line would be RegressionTests.

Most of our other tests are also regression tests.

> 
> Why not just keep historical name, so nobody is confused what is what?

CoreTests is brief and descriptive IMO. But I agree that LayoutTests is ok, 
even though it's not quite accurate any more.

> 
>> 
>>>>  I think the only names that are both accurate and unique are likely to be
>>>>  bad for autocomplete (WebTests, WebContentTests, etc).
>>> 
>>>  I guess we can also move WebKit.xcworkspace into Source, and rename
>>>  WebKitLibraries to SystemInterfaceLibraries (and maybe move into
>>>  Source), and then move Websites into Tools.
>>> 
>>>  - R. Niwa
>> 
>> ___
>> 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>
> 
> -- 
> Regards,
> Konstantin

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

Re: [webkit-dev] Rename LayoutTests

[Maciej Stachowiak]

A few more coats of paint for the bike shed:

> On May 9, 2017, at 10:45 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> 
> On Tue, May 9, 2017 at 10:23 PM, Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
>
> On May 9, 2017, at 9:07 PM, Michael Catanzaro 
> < mcatanz...@igalia.com 
> <mailto:mcatanz...@igalia.com>> wrote:
>>> On Tue, May 9, 2017 at 11:01 PM, Maciej Stachowiak <m...@apple.com 
>>> <mailto:m...@apple.com>> wrote:
>>>> How about just Tests?
>>>> Or alternately, RegressionTests. But I like just plain Tests.
>>> Then we should move ManualTests
>> I'd be in favor of burying this somewhere deeper. As it is, people are still 
>> adding tests here, which is kind of a disaster. These tests are very rarely 
>> run, so a manual test is often barely better than no test at all. We should 
>> also put a file in this directory strongly discouraging the addition of new 
>> manual tests IMO.
>>> , PerformanceTests,
>> Could be renamed Benchmarks.
> 
>> 
>> 
>>> On May 9, 2017, at 9:07 PM, Michael Catanzaro <mcatanz...@igalia.com 
>>> <mailto:mcatanz...@igalia.com>> wrote:
>> 
>>> , PerformanceTests,
>> 
>> Could be renamed Benchmarks.
> 
> I'm not sure benchmarks would be a good description given that
> directory also contains perf tests that are written to test specific
> feature like line layout and DOM bindings.

Those are still benchmarks (albeit microbenchmarks). But I think it would be OK 
to still call it "PerformanceTests", since unqualified "Tests" connotes 
functional tests. But "benchmark" and "performance test" are basically synonyms.

> 
> I find it much nicer to have a separate test directory under which the
> source code structure is mirrored such as UnitTests/WTFTests/,
> UnitTests/WebCoreTests/, etc...

Having UnitTests and APITests directories at top level might be better than 
having them under Tools/TestWebKitAPI/Tests.


>> If we did add any special directories to Tests with different semantics, 
>> they could just be special directories that are peers to the others, much 
>> like the http/ directory.
>> 
>> What are now called LayoutTests have the distinction (along with 
>> PerformanceTests) of being tests that can cover things up and down the 
>> stack. Most other tests could be assigned to one of the subdirectories of 
>> Source.
> 
> This is why I think IntegrationTests or FunctionalTests most
> accurately describe these tests.

IntegrationTests doesn't distinguish them from performance tests, or API tests. 
And most test integration only incidentally. FunctionalTests doesn't 
distinguish them from any of the other kinds of tests besides performance tests.

I think just plain Tests is better than calling out a characteristic that isn't 
actually unique. It's by far the most common type of test we have, so it's ok 
for it to be the unmarked category.

I also think LayoutTests is ok; it's not totally accurate but it's a historical 
name that most people understand at this point.

I think the only names that are both accurate and unique are likely to be bad 
for autocomplete (WebTests, WebContentTests, etc).

Regards,
Maciej

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

Re: [webkit-dev] Rename LayoutTests

[Maciej Stachowiak]

> On May 9, 2017, at 10:43 PM, Dan Bernstein <m...@apple.com> wrote:
> 
> 
>> On May 9, 2017, at 10:23 PM, Maciej Stachowiak <m...@apple.com 
>> <mailto:m...@apple.com>> wrote:
>> 
>>> JSTests, and
>> 
>> Could go under JavaScriptCore, since these by design don't test anything 
>> outside of JavaScriptCore.
> 
> There is an advantage to Apple’s internal production build system in keeping 
> large amounts of test content out of projects’ source directories (which is 
> why we moved it out of JavaScriptCore in 
> https://bugs.webkit.org/show_bug.cgi?id=160180 
> <https://bugs.webkit.org/show_bug.cgi?id=160180>), but if that’s the 
> preferred directory layout, then we can make some project changes to 
> accommodate the aforementioned build system.

My first preference would be to leave these tests in JSTests, even if we 
renamed the main tests directory to Tests.

 - Maciej

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

Re: [webkit-dev] Rename LayoutTests

[Maciej Stachowiak]

> On May 9, 2017, at 9:07 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
> On Tue, May 9, 2017 at 11:01 PM, Maciej Stachowiak <m...@apple.com> wrote:
>> How about just Tests?
>> Or alternately, RegressionTests. But I like just plain Tests.
> 
> Then we should move ManualTests

I'd be in favor of burying this somewhere deeper. As it is, people are still 
adding tests here, which is kind of a disaster. These tests are very rarely 
run, so a manual test is often barely better than no test at all. We should 
also put a file in this directory strongly discouraging the addition of new 
manual tests IMO.

> , PerformanceTests,

Could be renamed Benchmarks.

> JSTests, and

Could go under JavaScriptCore, since these by design don't test anything 
outside of JavaScriptCore. But I also think having Tests, JSTests and 
Benchmarks at top level would be totally understandable.

> TestWebKitAPI

That might be reasonable for TestWebKitAPI/Tests but probably not TestWebKitAPI 
itself, since the part other than the tests is a harness like WebKitTestRunner. 
And I'm not sure it's practical to move just the tests. It's probably easier to 
have them contained inside the tool in the source tree.

Also this is a weird mix of native code tests of public APIs for different 
frameworks, and native code unit tests for some internal classes (mostly 
low-level data structures).

If these didn't need to be linked into a single tool, I might suggest that each 
framework should contain its own units and API tests.

> underneath it, because it would be weird to have tests outside of the Tests 
> directory. Right?
> 
> And then we would probably want to move all the layout tests to a new 
> subdirectory, to separate them from the ManualTests, PerformanceTests, 
> JSTests, and API tests. Then we have to find a name that subdirectory

If we did add any special directories to Tests with different semantics, they 
could just be special directories that are peers to the others, much like the 
http/ directory.

What are now called LayoutTests have the distinction (along with 
PerformanceTests) of being tests that can cover things up and down the stack. 
Most other tests could be assigned to one of the subdirectories of Source. But 
I'd also be ok with having special subdirectories under Source.

BTW we also have:
 bindings tests (under WebCore/bindings/scripts/tests)
 perl tests (under Tools)
 python tests (under Tools)
 builtins-generator-tests (not sure what or where these are)
 dashboard-tests (also not sure what or where these are)

In general, I think it's good for more specific kinds of tests like this to be 
next to their relevant code.

Regards,
MAciej

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

Re: [webkit-dev] Rename LayoutTests

[Maciej Stachowiak]

How about just Tests?

Or alternately, RegressionTests. But I like just plain Tests.

> On May 9, 2017, at 8:51 PM, Michael Catanzaro  wrote:
> 
>> On Tue, May 9, 2017 at 9:23 PM, Ryosuke Niwa  wrote:
>> AutomatedTests - As opposed to ManualTests.
> 
> The API tests under Tools/TestWebKitAPI (which never seemed to me like a good 
> location for tests) are also automated, so this doesn't seem like the best 
> name unless we want to move the API tests there too.
> 
> ___
> 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] Idiom for functions with all return values in a switch case

[Maciej Stachowiak]

> On May 9, 2017, at 12:05 PM, Alfonso Guerra  wrote:
> 
> 
> 
> On May 9, 2017 2:07 PM, "Michael Catanzaro"  > wrote:
> Hi,
> 
> Consider this function:
> 
>        static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>        {
>            switch (event) {
>            case 
> WebCore::AutoplayEvent::DidEndMediaPlaybackWithoutUserInterference:
>                return 
> kWKAutoplayEventDidEndMediaPlaybackWithoutUserInterference;
>            case WebCore::AutoplayEvent::DidPlayMediaPreventedFromPlaying:
>                return kWKAutoplayEventDidPlayMediaPreventedFromAutoplaying;
>            case WebCore::AutoplayEvent::DidPreventMediaFromPlaying:
>                return kWKAutoplayEventDidPreventFromAutoplaying;
>            case WebCore::AutoplayEvent::UserDidInterfereWithPlayback:
>                return kWKAutoplayEventUserDidInterfereWithPlayback;
>            case 
> WebCore::AutoplayEvent::UserNeverPlayedMediaPreventedFromPlaying:
>                return 
> kWKAutoplayEventUserNeverPlayedMediaPreventedFromPlaying;
>            }
>        }
>  
> Hi,
> 
> Consider this function:
> 
>static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>{
>switch (event) {
>case 
> WebCore::AutoplayEvent::DidEndMediaPlaybackWithoutUserInterference:
>return 
> kWKAutoplayEventDidEndMediaPlaybackWithoutUserInterference;
>case WebCore::AutoplayEvent::DidPlayMediaPreventedFromPlaying:
>return kWKAutoplayEventDidPlayMediaPreventedFromAutoplaying;
>case WebCore::AutoplayEvent::DidPreventMediaFromPlaying:
>return kWKAutoplayEventDidPreventFromAutoplaying;
>case WebCore::AutoplayEvent::UserDidInterfereWithPlayback:
>return kWKAutoplayEventUserDidInterfereWithPlayback;
>case 
> WebCore::AutoplayEvent::UserNeverPlayedMediaPreventedFromPlaying:
>return 
> kWKAutoplayEventUserNeverPlayedMediaPreventedFromPlaying;
>}
>}
> 
> 
> Out of curiosity, why is using a switch statement better than defining an 
> array to hold the return values?

Some possible reasons:

- The compiler can likely turn the switch statement into simple arithmetic 
(maybe even just a move if the enum values happen to match).
- A lookup table array would require an explicit range check to avoid out of 
bounds reads.
- The lookup table approach doesn't give you a compiler warning if you miss one 
of the enum values.

> 
> 
> 
> 
> Alfonso Guerra
> Founder/CEO
> Apokalypse Software Corp
> @Huperniketes
> (626) 667-4285
> 
> It will trigger this GCC warning:
> 
> [3490/4357] Building CXX object 
> Source...bKit2.dir/UIProcess/API/C/WKPage.cpp.o
> ../../Source/WebKit2/UIProcess/API/C/WKPage.cpp: In static member function 
> ‘static WKAutoplayEvent WKPageSetPageUIClient(WKPageRef, const 
> WKPageUIClientBase*)::UIClient::toWKAutoplayEvent(WebCore::AutoplayEvent)’:
> ../../Source/WebKit2/UIProcess/API/C/WKPage.cpp:2277:9: warning: control 
> reaches end of non-void function [-Wreturn-type]
> }
> ^
> 
> Such functions are very common in WebKit. What should be our preferred idiom 
> for suppressing this warning?
> 
> https://bugs.webkit.org/show_bug.cgi?id=171851 
>  suggests this approach:
> 
>static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>{
>switch (event) {
>// ...
>}
> 
>ASSERT_NOT_REACHED();
>return 0;
>}
> 
> That works for the cases in that bug, but it won't work in this case, because 
> the return value here is an enum, so a cast would be needed.
> 
> I've been putting a RELEASE_ASSERT_NOT_REACHED() in the default case:
> 
>static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>{
>switch (event) {
>// ...
>default:
>RELEASE_ASSERT_NOT_REACHED();
>}
>}
> 
> Of course, that would work just as well coming after the switch. This is more 
> general as it works for enums, but RELEASE_ASSERT_NOT_REACHED() is a bunch of 
> typing. I've seen CRASH() used frequently as well, but what's the point of 
> having RELEASE_ASSERT_NOT_REACHED() at all if we are using CRASH() directly?
> 
> Opinions?
> 
> Bugs to close once we've decided how to handle this:
> 
> https://bugs.webkit.org/show_bug.cgi?id=171851 
> 
> https://bugs.webkit.org/show_bug.cgi?id=171866 
> 
> https://bugs.webkit.org/show_bug.cgi?id=171867 
> 
> 
> Michael
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 

Re: [webkit-dev] Idiom for functions with all return values in a switch case

[Maciej Stachowiak]

> On May 9, 2017, at 11:35 AM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
> On Tue, May 9, 2017 at 1:13 PM, Maciej Stachowiak <m...@apple.com> wrote:
>> I think this second option may suppress the warning when you have forgotten 
>> to list one of the enum values, since there is now a default case. I believe 
>> that's the reason for the recommended option.
> 
> Ah, good point. Normally we do want a warning when a new enum value has been 
> introduced. That could be avoided by this variant:
> 
>  static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>  {
>  switch (event) {
>  // ...
>  }
> 
>  RELEASE_ASSERT_NOT_REACHED();
>  }
> 
> That seems nicer than this:
> 
>  static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>  {
>  switch (event) {
>  // ...
>  }
> 
>  ASSERT_NOT_REACHED();
>  return static_cast(0);
>  }
> 
> Andy suggests returning one of the enumeration values directly, then we can 
> use ASSERT_NOT_REACHED() instead of RELEASE_ASSERT_NOT_REACHED(). That would 
> work too, though it forces me to think about which one to pick.

The RELEASE_ASSERT_NOT_REACHED case puts in more code that we believe will be 
unreached. I agree the other case is more verbose. If it's likely to come up 
often, we could make a macro for it, something like 
ASSERT_RETURN_NOT_REACHED(WKAutoplayEvent) which could do a 0 cast or a 
default-constructed value, whichever seems more useful. That still seems a bit 
verbose though.

Regards,
Maciej

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

Re: [webkit-dev] Idiom for functions with all return values in a switch case

[Maciej Stachowiak]

> On May 9, 2017, at 11:06 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> Consider this function:
> 
>   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>   {
>   switch (event) {
>   case 
> WebCore::AutoplayEvent::DidEndMediaPlaybackWithoutUserInterference:
>   return 
> kWKAutoplayEventDidEndMediaPlaybackWithoutUserInterference;
>   case WebCore::AutoplayEvent::DidPlayMediaPreventedFromPlaying:
>   return kWKAutoplayEventDidPlayMediaPreventedFromAutoplaying;
>   case WebCore::AutoplayEvent::DidPreventMediaFromPlaying:
>   return kWKAutoplayEventDidPreventFromAutoplaying;
>   case WebCore::AutoplayEvent::UserDidInterfereWithPlayback:
>   return kWKAutoplayEventUserDidInterfereWithPlayback;
>   case 
> WebCore::AutoplayEvent::UserNeverPlayedMediaPreventedFromPlaying:
>   return kWKAutoplayEventUserNeverPlayedMediaPreventedFromPlaying;
>   }
>   }
> 
> It will trigger this GCC warning:
> 
> [3490/4357] Building CXX object 
> Source...bKit2.dir/UIProcess/API/C/WKPage.cpp.o
> ../../Source/WebKit2/UIProcess/API/C/WKPage.cpp: In static member function 
> ‘static WKAutoplayEvent WKPageSetPageUIClient(WKPageRef, const 
> WKPageUIClientBase*)::UIClient::toWKAutoplayEvent(WebCore::AutoplayEvent)’:
> ../../Source/WebKit2/UIProcess/API/C/WKPage.cpp:2277:9: warning: control 
> reaches end of non-void function [-Wreturn-type]
>}
>^
> 
> Such functions are very common in WebKit. What should be our preferred idiom 
> for suppressing this warning?
> 
> https://bugs.webkit.org/show_bug.cgi?id=171851 suggests this approach:
> 
>   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>   {
>   switch (event) {
>   // ...
>   }
> 
>   ASSERT_NOT_REACHED();
>   return 0;
>   }
> 
> That works for the cases in that bug, but it won't work in this case, because 
> the return value here is an enum, so a cast would be needed.
> 
> I've been putting a RELEASE_ASSERT_NOT_REACHED() in the default case:
> 
>   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>   {
>   switch (event) {
>   // ...
>   default:
>   RELEASE_ASSERT_NOT_REACHED();
>   }
>   }

I think this second option may suppress the warning when you have forgotten to 
list one of the enum values, since there is now a default case. I believe 
that's the reason for the recommended option.

> 
> Of course, that would work just as well coming after the switch. This is more 
> general as it works for enums, but RELEASE_ASSERT_NOT_REACHED() is a bunch of 
> typing. I've seen CRASH() used frequently as well, but what's the point of 
> having RELEASE_ASSERT_NOT_REACHED() at all if we are using CRASH() directly?
> 
> Opinions?
> 
> Bugs to close once we've decided how to handle this:
> 
> https://bugs.webkit.org/show_bug.cgi?id=171851
> https://bugs.webkit.org/show_bug.cgi?id=171866
> https://bugs.webkit.org/show_bug.cgi?id=171867
> 
> 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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

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

I don't think that's an "also", not an "instead". My understanding is that they 
do two-way sync with the web-platform-tests GitHub, so there's a process for 
downloading tests and upstreaming tests authored by their team. But they still 
have their own copy.

Regards,
Maciej

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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

> On May 9, 2017, at 8:44 AM, youenn fablet  wrote:
> 
> 
> Besides other issues mentioned, testharness tends to result in more verbose 
> tests compared to js-test, at least for simple cases.
> 
> For synchronous tests, I am not sure there is any big difference one way or 
> the other.
> With asynchronous tests, it might be true, but using 
> testharness.js/promise_test usually improves things there.
>  I personally find it easier to not wrap code-to-be-tested into quotes.

It seems like it's a matter of personal preference to some extent. So I am not 
sure we should recommend one or the other (besides for tests that are intended 
to be contributed to web-platform-tests).

> 
> Another concern is the lack of verbose output which reduces the ability to 
> debug failing tests.
> This can be partially fixed by authoring tests with that issue in mind.
> For instance, having a big promise_test to handle the asynchronous aspect of 
> a test and nested test() inside it.

I don't think we've ever had a problem with debugging js-test.js tests when 
they fail.

> 
>> The thing I specifically asked Youenn to ask is, whether we should
>> place a test inside LayoutTests/wpt like LayoutTests/http/tests when
>> we want to write a test using testharness.js which requires some sort
>> of network code.
>> 
>> Since people have had some opinions about directory structures in the past.
> 
> 
> It seems like we need a few different directories, here are my opinions on 
> them:
> 
> (1) Imported web platform tests that don't need a server
> Currently LayoutTests/imported/w3c/web-platform-tests, which seems fine.
> 
> All WPT tests are expected to run behind the WPT server.
> That is the way tests are authored and tested elsewhere.
> If we have an issue with that, it is best to bring that and fix that directly 
> in WPT.
> I encountered several times small issues due to file:// based origins which 
> makes me think defaulting to http is a safe choice.
> 
> One concern is efficiency. We should study that and improve on that.
> Another concern is the ease of running tests for developers: drag 
> tests into a browser instead of running a server.
> We can partially accommodate this by rewriting 
> testharness.js/testharnessreport.js urls.
> A significant and growing amount of wpt tests will not behave as expected 
> (other resources loaded, origins, need for specific headers, need for 
> https...)
> 
> (2) Imported web platform tests that do need a server
> Probably should be under LayoutTests/imported/w3c/ somewhere, or maybe 
> under http/tests/ per point (4)
> 
> I don't think this will work, web-platform-tests is organized in terms of 
> features.
> There is no clear separation between file based compatible tests and http 
> based tests like in WebKit.

If we run all the w3c-imported web platform tests under a web server, then 
obviously we only need one directory. My understanding is that we don't run 
them under a server at all. So it seems like one part of this proposal is "run 
everything under LayoutTests/imported/w3c/ from a web server".

> 
> (3) Custom testharness.js tests that don't need a server 
> Probably these should just go in their normal topic-specific directories 
> and should not need a special directory
> 
> Right.
> The only case where it might make sense to put such tests in a specific 
> WPT-enabled directory is if the plan is to upstream these tests at some point.
> Such tests could be added in imported/w3c/web-platform-tests directly but 
> this requires coordination with resyncing tests at the moment.
> In a not-too-far-future, I hope such tests would directly be authored in 
> imported/w3c/web-platform-tests.

I think it would be cleaner to have a separate directory of tests intended for 
import, separate from imported tests. It could be right next to 
imported/w3c/web-platform-tests. I think mixing tests that are imported from 
upstream and tests intended for eventual upstreaming is more confusing than 
helpful.

>  
> (4) Custom testharness.js tests that do need a server
> Can these just be a subdirectory of http/tests/? We have websocket and 
> ssl/tls tests in there too. Would be nice to not need a separate directory 
> for networking tests that to use a particular test framework.
> 
> I do not have strong feelings there, http/wpt might make sense if it is found 
> easier to understand to everybody.
> I'll update the patch accordingly and will land it sometimes this week if 
> there is no additional feedback.

One question I have is whether web platform tests can run under a regular HTTP 
server (maybe with appropriate configuration) or do we need something special? 
Is the WPT server more than just a web server with specific configuration 
settings?

Regards,
Maciej


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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

> On May 8, 2017, at 11:15 PM, Ryosuke Niwa  wrote:
> 
> On Mon, May 8, 2017 at 11:01 PM, Brady Eidson  > wrote:
>
> On May 8, 2017, at 10:44 PM, Ryosuke Niwa < 
> rn...@webkit.org > 
> wrote:
>>> On Mon, May 8, 2017 at 10:17 PM, Brady Eidson >> > wrote:
 But now talking about testharness.js directly, I object on the grounds of 
 "a
 file:// regression test is dirt easy to hack on and work with, whereas
 anything that requires me to have an httpd running is a PITA"
>>> I think whether we use file:// or http:// is orthogonal point to using
>>> testharness.js.  Many of the tests Chris and I have written using
>>> testharness.js are checked into regular LayoutTests/ directories, and
>>> they work just fine.
>> Yes, I misunderstood this in Youenn's original message. Good to know!
 I just object to making it the "recommended way" of writing tests.
>>> Would you equally object to making js-test.js / js-test-pre.js the
>>> recommended way of writing tests?
>> Yes.
>>> If not, why?
>> N/A
>>> What we're suggesting is to give preferential treatments to
>>> testharness.js over js-test.js / js-test-pre.js when you were already
>>> planning to write a test with the latter two scripts.
>> "It's okay to write your test however you'd like. If you were considering 
>> using js-test, maybe you should consider using testharness instead."
>> Is that's what's being proposed?
> 
>> 
>>> On May 8, 2017, at 10:44 PM, Ryosuke Niwa >> > wrote:
>>> 
>>> On Mon, May 8, 2017 at 10:17 PM, Brady Eidson >> > wrote:
>>> 
 But now talking about testharness.js directly, I object on the grounds of 
 "a
 file:// regression test is dirt easy to hack on and work with, whereas
 anything that requires me to have an httpd running is a PITA"
>>> 
>>> I think whether we use file:// or http:// is orthogonal point to using
>>> testharness.js.  Many of the tests Chris and I have written using
>>> testharness.js are checked into regular LayoutTests/ directories, and
>>> they work just fine.
>> 
>> Yes, I misunderstood this in Youenn's original message. Good to know!
>>> 
 I just object to making it the "recommended way" of writing tests.
>>> 
>>> Would you equally object to making js-test.js / js-test-pre.js the
>>> recommended way of writing tests?
>> 
>> Yes.
>> 
>>> If not, why?
>> 
>> N/A
>> 
>>> What we're suggesting is to give preferential treatments to
>>> testharness.js over js-test.js / js-test-pre.js when you were already
>>> planning to write a test with the latter two scripts.
>> 
>> "It's okay to write your test however you'd like. If you were considering 
>> using js-test, maybe you should consider using testharness instead."
>> 
>> Is that's what's being proposed?

Besides other issues mentioned, testharness tends to result in more verbose 
tests compared to js-test, at least for simple cases.

> 
> The thing I specifically asked Youenn to ask is, whether we should
> place a test inside LayoutTests/wpt like LayoutTests/http/tests when
> we want to write a test using testharness.js which requires some sort
> of network code.
> 
> Since people have had some opinions about directory structures in the past.

It seems like we need a few different directories, here are my opinions on them:

(1) Imported web platform tests that don't need a server
Currently LayoutTests/imported/w3c/web-platform-tests, which seems fine.
(2) Imported web platform tests that do need a server
Probably should be under LayoutTests/imported/w3c/ somewhere, or maybe 
under http/tests/ per point (4)
(3) Custom testharness.js tests that don't need a server 
Probably these should just go in their normal topic-specific directories 
and should not need a special directory
(4) Custom testharness.js tests that do need a server
Can these just be a subdirectory of http/tests/? We have websocket and 
ssl/tls tests in there too. Would be nice to not need a separate directory for 
networking tests that to use a particular test framework.

Regards,
Maciej

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

Re: [webkit-dev] Clang tidy

[Maciej Stachowiak]

> On May 8, 2017, at 9:09 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> 
> On Wed, May 3, 2017 at 8:31 PM, Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
>   On May 3, 
> 2017, at 6:31 PM, Olmstead, Don < 
> don.olmst...@sony.com 
> <mailto:don.olmst...@sony.com>> wrote:
>> I took some time today to see how clang-tidy can be run on WebKit code and
>> openedhttps://bugs.webkit.org/show_bug.cgi?id=171632 
>> <openedhttps://bugs.webkit.org/show_bug.cgi?id=171632> with some examples on
>> how to run things. I also attached some output from the modernizer fixes
>> that can be applied.
>> I was thinking of running any code we move from WebCore/platform through
>> clang-tidy during the process of moving it to PAL. Documentation for the
>> checks can be found at
>> http://clang.llvm.org/extra/clang-tidy/checks/list.htmlif 
>> <http://clang.llvm.org/extra/clang-tidy/checks/list.htmlif> anyone wants to
>> take a look at what should potentially be run.
>> I think moving code should be done with the bare minimum changes needed to
>> do the move (file paths, etc). Any code cleanup script should be done
>> separately. Any change can break things (though we hope both moving files
>> and running clang-tidy would have no behavioral effect). Therefore it's best
>> not to mix unrelated changes, so if a regression occurs, it's easier to see
>> what caused it.
> 
>> 
>> 
>> On May 3, 2017, at 6:31 PM, Olmstead, Don <don.olmst...@sony.com 
>> <mailto:don.olmst...@sony.com>> wrote:
>> 
>> I took some time today to see how clang-tidy can be run on WebKit code and
>> openedhttps://bugs.webkit.org/show_bug.cgi?id=171632 
>> <openedhttps://bugs.webkit.org/show_bug.cgi?id=171632> with some examples on
>> how to run things. I also attached some output from the modernizer fixes
>> that can be applied.
>> 
>> I was thinking of running any code we move from WebCore/platform through
>> clang-tidy during the process of moving it to PAL. Documentation for the
>> checks can be found at
>> http://clang.llvm.org/extra/clang-tidy/checks/list.htmlif 
>> <http://clang.llvm.org/extra/clang-tidy/checks/list.htmlif> anyone wants to
>> take a look at what should potentially be run.
>> 
>> 
>> I think moving code should be done with the bare minimum changes needed to
>> do the move (file paths, etc). Any code cleanup script should be done
>> separately. Any change can break things (though we hope both moving files
>> and running clang-tidy would have no behavioral effect). Therefore it's best
>> not to mix unrelated changes, so if a regression occurs, it's easier to see
>> what caused it.
> 
> I agree with Maciej and Konstantin that these code changes should be
> made separately due to the risk of inadvertently introducing
> regressions.
> 
> In addition, I don't really like code churns like this (as they make
> SVN/Git blame less useful) unless we're fixing violations of WebKit
> code style guideline: https://webkit.org/code-style-guidelines/ 
> <https://webkit.org/code-style-guidelines/>
> 
> Many of the changes made in the aforementioned bug appear to be more
> of nits that aren't explicitly called out in our guideline.

We could add entries to our style guideline for some of these things if we 
think they are better. Then at least new code can get them.

Not sure all these things are an improvement though. I'm personally not a fan 
of including  instead of  and we historically haven't 
done it that way.

 - Maciej


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

Re: [webkit-dev] User agent woes

[Maciej Stachowiak]

> On May 8, 2017, at 1:30 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
> On Mon, May 8, 2017 at 3:13 PM, Maciej Stachowiak <m...@apple.com> wrote:
>> The ideal scenario would be for Google Hangouts to correctly handle WebKit 
>> UA strings on X11 platforms. It seems like Safari claiming to be Mac Firefox 
>> would be a move in the wrong direction. (It might also cause Hangouts to try 
>> to use features that are unsupported in Mac Safari.)
>> What happens on Google Hangouts if you use your normal UA string?
> 
> I think it works just fine with our normal UA string, as it does with our 
> current Firefox quirk, actually. We could try adding url.host() != 
> talkgadget.google.com and url.host != hangouts.google.com checks to the 
> urlRequiresFirefoxBrowser function, but I don't see any need to do so. I only 
> mentioned Hangouts here to note that it prevents us from using a macOS quirk 
> for Google unless we're able to target a specific subdomain, which is not 
> always possible (e.g. maps.google.com is now just a redirect to 
> google.com/maps). If we try sending different quirks based on the URL path, 
> then getting the quirk to work becomes quite tricky because it requires 
> figuring out the right set of subresources on the page for which to receive 
> the quirk. So far, I've managed to avoid that mess.

I see, so your Google UA string is a tricky balancing act between the weird 
needs of many sites.

> 
> By the way, the icing on the cake is that X11 is only in the user agent for 
> compatibility purposes... Fedora has replaced X11 with Wayland now, and 
> Ubuntu will too in its next release this October. But removing X11 breaks 
> some websites (including Google Calendar), so it's going to have stay forever.

We have seriously considered freezing our UA string forever because even 
smaller changes than this can cause compat issues.

Regards,
Maciej

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

Re: [webkit-dev] User agent woes

[Maciej Stachowiak]

> On May 7, 2017, at 8:11 PM, Michael Catanzaro  wrote:
> 
> Hi Maciej,
> 
> I agree with basically everything you wrote, except I recommend not using OS 
> X as the operating system string in the default user agent except when 
> actually running on macOS. We tried this for about a year and got tons of 
> complaints. It breaks more than it fixes: many websites decide to present 
> only macOS versions of downloads and offer no recourse to get the right 
> version of the download (like Hangouts), and other times it's just annoying, 
> e.g. the OS field on Bugzilla defaults to OS X, which a substantial subset of 
> bug reporters feel the need to complain about. So instead, we now add OS X 
> quirks for websites when needed.
> 
>> You mentioned that for some sites, that wouldn't work. I think it's 
>> reasonable to have more specific exceptions just for those, and we can 
>> review them together. Specifically, for Google Hangouts, you mention that 
>> claiming to be Mac Safari will offer a non-working plugin. However, it looks 
>> like WebKitGTK+ pretends to be Linux Firefox for Google sites instead. It 
>> seems very likely that a Linux Firefox UA string would break Google Hangouts 
>> in Mac Safari for pretty much the same reason.
> 
> Yes, you definitely can't send a Linux+Firefox UA string, as that would 
> definitely break Hangouts for Safari users.
> 
> But I bet you could send a macOS+Firefox UA string, until such time that 
> Google fixes its websites to stop sending inferior pages to other WebKit 
> browsers. That way, next time they decide to make a change based on UA that's 
> going to cause other WebKit browsers to break, Safari should break as well 
> and Google should notice before deploying the change if they test it at all. 
> (Of course, this is only really needed if evangelism fails.)

The ideal scenario would be for Google Hangouts to correctly handle WebKit UA 
strings on X11 platforms. It seems like Safari claiming to be Mac Firefox would 
be a move in the wrong direction. (It might also cause Hangouts to try to use 
features that are unsupported in Mac Safari.) 

What happens on Google Hangouts if you use your normal UA string?

> 
>> It's not clear to me what the issues are with typekit or slack, or why you 
>> claim to be Chrome instead of Mac Safari on those.
> 
> I don't remember exactly why I came up with the Chrome quirk for these sites, 
> but I usually try our macOS quirk first and use the Chrome quirk next if that 
> fails. The macOS quirk is much safer as it does not encourage websites to try 
> to use Chrome-specific JS.
> 
> The issue with Typekit is that lots of websites use Typekit for web fonts, 
> but Typekit disables itself unless it recognizes the user agent. Then users 
> complain that fonts are wrong on a bunch of different websites. See 
> https://bugs.webkit.org/show_bug.cgi?id=147296.
> 
> Slack just doesn't work at all with our default UA, it displays only an 
> unsupported browser page. It works perfectly fine with the UA changed.
> 
>> Maybe claiming to be Mac Safari would reduce future breakage. Or if not, it 
>> would be interesting to know what the issue is.
>> We may also be able to reach out to some of the problem websites or help you 
>> get contact info.
> 
> This would be wonderful. I don't think it's worthwhile to reach out to 
> websites like Slack and Whatsapp that are clearly intentionally trying to 
> block our users: I'd rather them not realize that we are sending UA quirks at 
> all, as they might try harder to block our users if so. But in other cases, 
> like with Google, we would really appreciate your help with evangelism. Let's 
> continue this line of discussion via private mail.

Sure, let's continue offline.

Regards,
Maciej

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

Re: [webkit-dev] User agent woes

[Maciej Stachowiak]

> On May 6, 2017, at 5:19 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> You're probably aware that WebKitGTK+ has user agent quirks to make various 
> popular websites work, most notably google.com.  For our list of quirks, see:
> 
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/UserAgentQuirks.cpp
> 
> Recently we had two major bugs caused by these quirks:
> 
> https://bugs.webkit.org/show_bug.cgi?id=171603 (New YouTube displays only 
> white page)
> https://bugs.webkit.org/show_bug.cgi?id=171770 (Google login fails on white 
> page)
> 
> In the case of the YouTube bug, I decided to just remove the quirk. This case 
> was pretty much a nightmare scenario, because Google decided that a random 
> subset of users would receive the new version of YouTube long in advance of 
> the rest of us. This means that we had a portion of our users complaining 
> that YouTube was "broken" for weeks when we were unable to reproduce the 
> issue (and had no way to do so; how could we have guessed it was some trial 
> program?).
> 
> Anyway, removing the quirk is not a good option for the generic google.com 
> quirk in the second bug. If we use a standard user agent, we receive a crap 
> unusable 1990s version of Google Calendar, a high source of user complaints, 
> and also the awesome 3D earth mode in Google Maps that our users expect is 
> unavailable. This makes users think that WebKit is bad. I found a solution, 
> but I know it's temporary; give it a few more months and Google will break us 
> again, no doubt.
> 
> User agent is an extremely demotivating, never-ending game, and it's by far 
> our biggest web compatibility problem. It almost feels as if Google is 
> deliberately trying to break WebKit, which I know is not true as they don't 
> care either way about us... but they do know full well that basing logic off 
> of user agent checks serves to harm less-popular browsers, so it's hardly 
> unintentional. I cannot think of any aspect of WebKit development less 
> gratifying than maintaining our user agent quirk list, nor any bigger user 
> agent offender than Google.
> 
> For a while I thought there was nothing we could do, but now I have an idea: 
> Safari could adopt the same (or lightly-adapted) user agent quirks that we 
> use for WebKitGTK+. Of course, only the small handful of websites to which we 
> currently need to send user agent quirks would be affected by this change: 
> Google, Yahoo, Slack, Whatsapp, Typekit, and some Chinese site Taobao. Now, 
> this would do no good for Safari, but it would be a huge help to us as it 
> would ensure that if these user agent offenders attempt to degrade 
> functionality for browsers not on their lists, they will have to at least 
> treat all WebKit browsers equally. Presumably they test to make sure their 
> websites work in Safari, so that should make this situation much better for 
> other ports. And if we run into problems, we at least know the change is 
> limited to this small set of websites.
> 
> I think the existing quirks would be fine for Safari with minimal changes. We 
> would definitely need to add some #if OS(UNIX) && !PLATFORM(COCOA) guards 
> inside urlRequiresLinuxDesktopPlatform(), and put if !PLATFORM(IOS) around 
> the quirks that are designed to turn off mobile versions of websites. This 
> would only be a small amount of work to set up, and it would only affect the 
> handful of websites that we have identified as problematic. Would Apple be 
> willing to allow this?
> 
> Alternatively, we could use the nuclear option and add a Chrome version 
> component, similar to how Chrome includes a Safari version in its user agent. 
> (Bonus: that will shut up Google's "switch to Chrome" ads for a couple weeks 
> until they figure it out.) Edge already includes a Chrome version. This would 
> undoubtedly be better for the web as a whole, but it would surely also 
> introduce serious short-term compatibility problems, as an unknown number of 
> websites would likely break horribly in Safari (and some known websites, e.g. 
> YouTube and Google Hangouts), so that's a pretty tough ask. Making it more 
> difficult for websites to send us crap versions of web pages would be good 
> for WebKit in the long term, but it's way safer to start only on quirks for 
> specific sites.
> 
> What do you think?

It's unlikely that we'll change the user agent that Safari (or other macOS or 
iOS WebKit clients) send for websites that already work correctly in Safari. I 
can think of at least four reasons:

(1) In general we'll only add site-specific hacks for prominent websites that 
are actively broken in Safari, and we do evangelism in parallel to be able 
remove them.
(2) We don't want the UA string environment observed by sites to become even 
more complicated.
(3) Changing the UA string is high risk. Even updating our own version number 
is a risky proposition. To the point that we've seriously considered 
permanently 

Re: [webkit-dev] Clang tidy

[Maciej Stachowiak]

> On May 3, 2017, at 6:31 PM, Olmstead, Don  wrote:
> 
> I took some time today to see how clang-tidy can be run on WebKit code and 
> openedhttps://bugs.webkit.org/show_bug.cgi?id=171632 
>  with some examples on how to 
> run things. I also attached some output from the modernizer fixes that can be 
> applied.
>  
> I was thinking of running any code we move from WebCore/platform through 
> clang-tidy during the process of moving it to PAL. Documentation for the 
> checks can be found at 
> http://clang.llvm.org/extra/clang-tidy/checks/list.html 
> if anyone wants to 
> take a look at what should potentially be run.

I think moving code should be done with the bare minimum changes needed to do 
the move (file paths, etc). Any code cleanup script should be done separately. 
Any change can break things (though we hope both moving files and running 
clang-tidy would have no behavioral effect). Therefore it's best not to mix 
unrelated changes, so if a regression occurs, it's easier to see what caused it.

Probably there should also be a discussion of whether we want these particular 
changes. People tend to dislike churn, and we'd also need to make sure the 
newer style works on all toolchains that people use, and that stylistically we 
like #include  in place of #include  and using in place 
of typedef. I don't think we have style rules calling for those things, so it 
would be jumping the gun a bit to start applying them. This is an additional 
reason to separate style changes from moving code to PAL (which I believe has 
been discussed and is not controversial).

Regards,
Maciej

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

Re: [webkit-dev] Heads up: ICU source compatibility breakage in 59.1 release

[Maciej Stachowiak]

I agree, better to add private cast macros (which are no-ops on the appropriate 
version of ICU) to convert incoming/outgoing public API types, and leave the 
actual public API types alone.

> On May 2, 2017, at 10:40 AM, Myles C. Maxfield  wrote:
> 
> The fact that we use ICU is an implementation detail. It seems wrong to let 
> this affect our public API.
> 
> —Myles
> 
>> On May 2, 2017, at 10:31 AM, Konstantin Tokarev  wrote:
>> 
>> Hello,
>> 
>> ICU 59.1 release came out recently, featuring major source compatibility 
>> break. Notably, they've changed type of UChar to be char16_t, which does not 
>> allow automatic type conversion from unsigned short in C++ code.
>> 
>> Possible compilation fix is patch [1], however it changes definitions of 
>> JSChar and WKChar in public headers. Another problem is keeping 
>> compatibility with older ICU releases, that requires ICU version check in 
>> public headers.
>> 
>> Any thoughts how should it be resolved?
>> 
>> [1] 
>> https://git.archlinux.org/svntogit/packages.git/tree/trunk/icu59.patch?h=packages/webkit2gtk
>> 
>> -- 
>> Regards,
>> Konstantin
>> ___
>> 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] PAL Strategy

[Maciej Stachowiak]

> On May 1, 2017, at 1:48 PM, Brady Eidson  wrote:
> 
> 
>> On May 1, 2017, at 12:41 PM, Michael Catanzaro  wrote:
>> 
>> I thought the original intent for PAL was to replace WebCore/platform, so I 
>> assume the criterion would be "stuff currently in WebCore/platform." If not, 
>> then I'd question the value of having PAL at all, as we really don't need a 
>> separate PAL on top of the platform abstraction library we already have 
>> under in Source/WebCore/platform.

I don't think anyone proposed that PAL should be on top of WebCore/platform. 
Instead, the question is if some things should be moved to WTF instead of to 
PAL. PAL is allowed to depend on WTF. JavaScriptCore is allowed to depend on 
WTF but not on PAL. This means that some things might be ok to put in either 
WTF or PAL.

>> 
>> The stuff that moved to WTF was needed in JSC. If we want to keep stuff like 
>> UUID from moving to WTF, then we'd need to allow JSC to depend on PAL, 
>> rather than vice-versa.
> 
> I think everything in WebCore/platform should be moved to PAL.
> 
> WTF should only be for things JSC needs, which is nothing inside 
> WebCore/platform.
> 
> If JSC later needs something that is in PAL, we can move it from PAL to WTF 
> as needed.


My 2c:

Things with no additional dependencies beyond what WTF has already might be ok 
to move to WTF, but it's not required to do so. For example, WTF has most of 
our implementations of container types, so more like those would be ok. I think 
it already has some that are only used in WebCore not in JSC.

Things that introduce new dependencies probably should not be moved. I think 
FileSystem would imply new dependencies on file operations which I don't think 
are currently used in WTF. The exception would be if JSC needs it for some 
reason.

Dependency on GUI toolkits would definitely be a hard no for WTF, since we want 
JSC to be independent of that.

Regards,
Maciej



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

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

[Maciej Stachowiak]

Sent from my iPhone

> On Apr 28, 2017, at 1:00 PM, JF Bastien <jfbast...@apple.com> wrote:
> 
> 
>> On Apr 28, 2017, at 12:12, Maciej Stachowiak <m...@apple.com> wrote:
>> 
>> 
>> Here's some comments in the other direction:
>> 
>> - If there are times we recommend x != 0 instead of !x, it should maybe be 
>> based on whether the condition is better expressed as "not zero" or "false". 
>> In the numTestsForEqualityComparison, that's clearly a "not zero" check 
>> given the naming of the variable. This could be addressed by removing 
>> zero/non-zero from the list with true/false and null/non-null instead of 
>> making a carve-out based on type.
>> 
>> - Allowing both forms for zero/non-zero comparisons would be unfortunate. We 
>> have style guidelines to avoid tiny inconsistencies like this. So if the 
>> guideline changes, it should be to *require* == 0 or != 0 for numeric 
>> comparisons to 0, not merely allow it. Proliferating both styles would be 
>> sad.
>> 
>> - If we adopted the new rule, it would be slightly sad that a bunch of old 
>> code doesn't follow it. Changing it all at once would be needless churn, but 
>> we'll end up with a lot of code in both styles, partly defeating the 
>> consistency benefits of having a style guideline at all. This is sort of a 
>> general issue with any change to the coding style guidelines. If we change 
>> the guideline for a frequently used construct, the benefit has to be really 
>> high to account for the fact that we'll have many years of inconsistency. 
>> Note that the guidelines are mainly for the benefit of people reading the 
>> code, not writing, and inconsistent style may be worse than consistently 
>> using a slightly worse form.
>> 
>> - The style checker wouldn't be able to check the rule since it's not smart 
>> enough to tell if you are doing a null check, a false check or a zero check. 
>> (I am not sure if it enforces the current rule.)
> 
> That’s kind of a sad reason though. If we think it’s really worth it, we can 
> move to a clang-based approach. It’ll definitely be way more powerful than 
> regular expressions. I really liked how That Other Browser did this (hook 
> into clang for extra diagnostics, and you also get rewriting tools for Free™).

I listed that reason last intentionally. I don't think it's the most important. 
That said, I like the idea of a smarter style checker based on clang.

> 
> 
>> I don't actually have a strong opinion on the substance of the rule, either 
>> version seems fine to me if we were starting from a blank slate. I'm not 
>> entirely sure why the rule ended up that way in the first place. But I 
>> wanted to note these as things to think about.
>> 
>> Regards,
>> Maciej
>> 
>>> On Apr 28, 2017, at 1:00 AM, Keith Miller <keith_mil...@apple.com> wrote:
>>> 
>>> Is there any opposition to relaxing this rule? Speak now or forever hold 
>>> your piece! (not really but I would be curious to hear opposition). 
>>> 
>>> Cheers,
>>> Keith
>>> 
>>>> On Apr 27, 2017, at 10:32 PM, Carlos Garcia Campos <carlo...@webkit.org> 
>>>> wrote:
>>>> 
>>>> El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:
>>>>> 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 sa

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

[Maciej Stachowiak]

I think allowing both forms is worse than mandating one form. It's true that in 
different situations one or the other may read better, but it's distracting to 
have differences that are matters of author taste rather than conveying 
meaningful information. "This is a numeric check, not a boolean or null check" 
is info, but "this kinda feels numbery to whoever wrote the code" is not.

 - Maciej 

> On Apr 28, 2017, at 6:02 AM, Antti Koivisto  wrote:
> 
> This is a good change as long as we are just relaxing the rule rather than 
> mandating ==. I think ! makes a lot of sense when testing for emptiness: 
> 
> if (!container.size())
>...
> 
> if (!count)
>...
> 
> but == should be used for testing things where 0 is just another number, like 
> indexes:
> 
> if (index == 0)
>...
> 
> 
>antti
> 
> 
> On Fri, Apr 28, 2017 at 11:00 AM, Keith Miller  > wrote:
> Is there any opposition to relaxing this rule? Speak now or forever hold your 
> piece! (not really but I would be curious to hear opposition). 
> 
> Cheers,
> Keith
> 
>> On Apr 27, 2017, at 10:32 PM, Carlos Garcia Campos > > wrote:
>> 
>> El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:
>>> 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.
>> 
>> I agree, it's also quite confusing when using strcmp, because !strcmp
>> means the strings are equal. It's not only more difficult to read, I've
>> seen patches with wrong strcmp checks because of that.
> 
> I also think this could be solved by #defining a success a C call positive 
> result that is 0 (e.g. CCallSuccess), regardless of the choice we make here.
> 
>> 
>>> 
>>> !!Thanks (i.e. many thanks),
>>> 
>>> JF
>>> 
>>> p.s.: With you I am, fans of Yoda comparison, but for another day
>>> this will be.
>>> ___
>>> 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

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

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

[Maciej Stachowiak]

Here's some comments in the other direction:

- If there are times we recommend x != 0 instead of !x, it should maybe be 
based on whether the condition is better expressed as "not zero" or "false". In 
the numTestsForEqualityComparison, that's clearly a "not zero" check given the 
naming of the variable. This could be addressed by removing zero/non-zero from 
the list with true/false and null/non-null instead of making a carve-out based 
on type.

- Allowing both forms for zero/non-zero comparisons would be unfortunate. We 
have style guidelines to avoid tiny inconsistencies like this. So if the 
guideline changes, it should be to *require* == 0 or != 0 for numeric 
comparisons to 0, not merely allow it. Proliferating both styles would be sad.

- If we adopted the new rule, it would be slightly sad that a bunch of old code 
doesn't follow it. Changing it all at once would be needless churn, but we'll 
end up with a lot of code in both styles, partly defeating the consistency 
benefits of having a style guideline at all. This is sort of a general issue 
with any change to the coding style guidelines. If we change the guideline for 
a frequently used construct, the benefit has to be really high to account for 
the fact that we'll have many years of inconsistency. Note that the guidelines 
are mainly for the benefit of people reading the code, not writing, and 
inconsistent style may be worse than consistently using a slightly worse form.

- The style checker wouldn't be able to check the rule since it's not smart 
enough to tell if you are doing a null check, a false check or a zero check. (I 
am not sure if it enforces the current rule.)

I don't actually have a strong opinion on the substance of the rule, either 
version seems fine to me if we were starting from a blank slate. I'm not 
entirely sure why the rule ended up that way in the first place. But I wanted 
to note these as things to think about.

Regards,
Maciej

> On Apr 28, 2017, at 1:00 AM, Keith Miller  wrote:
> 
> Is there any opposition to relaxing this rule? Speak now or forever hold your 
> piece! (not really but I would be curious to hear opposition). 
> 
> Cheers,
> Keith
> 
>> On Apr 27, 2017, at 10:32 PM, Carlos Garcia Campos > > wrote:
>> 
>> El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:
>>> 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.
>> 
>> I agree, it's also quite confusing when using strcmp, because !strcmp
>> means the strings are equal. It's not only more difficult to read, I've
>> seen patches with wrong strcmp checks because of that.
> 
> I also think this could be solved by #defining a success a C call positive 
> result that is 0 (e.g. CCallSuccess), regardless of the choice we make here.
> 
>> 
>>> 
>>> !!Thanks (i.e. many thanks),
>>> 
>>> JF
>>> 
>>> p.s.: With you I am, fans of Yoda comparison, but for another day
>>> this will be.
>>> ___
>>> 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] Compile time increase over time

[Maciej Stachowiak]

For the macOS and iOS ports, we have the additional problem of overhead from 
the build system. Our make+xcodebuild based system takes a surprisingly long 
time even for a no-op build, or for a small incremental "just changed this one 
implementation file" build.

There's also some indication that newer versions of clang may have gotten 
slower at compiling the same code, perhaps due to more aggressive optimizations.

 - Maciej

> On Apr 24, 2017, at 11:10 AM, Alex Christensen  wrote:
> 
> Thanks for the data, Carlos! This is a growing problem that is hurting 
> productivity.  We’ve discussed it a bit and haven’t done enough about it.  
> Here are some of the ideas I’ve heard:
> 
> 1) Reduce #includes by doing more forward declaring and less inlining.  We 
> would probably need link time optimization to not lose performance benefits 
> of inlining functions in headers.
> 2) Use distributed build tools and caches to cover up the problem.  WebKit 
> would still be prohibitively hard to compile for people without lots of 
> expensive computers, but we could greatly improve the productivity of large 
> teams.
> 3) Use C++ modules
> 4) Put more commonly included headers into precompiled headers
> 5) I remember somebody claiming a few years ago that replacing #include 
> “Something.h” with #include “path/to/Something.h” reduced compile times 
> because it required fewer include paths, but I don’t think anybody has 
> measured the improvement recently.
> 6) Optimize the compilers we use
> 
> We should look into all of these and more.  Compiling WebKit also uses a lot 
> of memory, and our binary size continues to increase.
> ___
> 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: upstream the WPE port

[Maciej Stachowiak]

The GTK+ port has been a good WebKit citizen. And Igalia has a strong track 
record of WebKit contributions. So I am generally supportive of upstreaming the 
WPE port, as I expect it to be a net positive for the project.

I can see we will need to work out issues around the API that is exposed. In 
the early days of WebKit2 (or what we now call "Modern WebKit" or just plain 
"WebKit"), we hoped the WebKit2 C API could be a generic cross-port public API. 
But it seems that it hasn't worked out, and some aspects of it are regrettable 
legacy.

Regards,
Maciej


> On Apr 21, 2017, at 4:48 AM, z...@falconsigh.net wrote:
> 
> Hi,
> 
> the WebKit team at Igalia would like to propose upstreaming the WPE port
> of WebKit, taking on the duty to maintain it alongside the GTK+ port.
> 
> The WPE port started in 2014 as the 'WebKit for Wayland' project inside
> Igalia [1].  The port was derived from the GTK+ port, but avoided
> dependency on any GUI toolkit.  It relied on the Wayland display
> protocol for on-screen presentation.  That dependency was later dropped
> in favor of using generic interfaces to adapt to different
> platform-specific presentation systems.  This allows any vendor to
> simply provide the necessary backend implementations that are tailored
> to their platform.
> 
> The port is intended to be the Web platform engine of choice for
> embedded Linux systems.  Since late 2014 Igalia has been sponsored by
> Metrological to further develop the WPE port, targeting primarily
> various set-top box platforms.  Miguel Gomez blogged about this effort
> back in December [2].  The port can also address other embedded use
> cases, for instance in-vehicle infotainment or digital signage.
> 
> The GTK+ and WPE ports mostly have the same dependencies except for the
> GTK+ toolkit library.  That enables the two ports to already share a lot
> of code.  The biggest difference between the two is that the WPE port
> exposes the WebKit2 C API, while the GTK+ port exposes a GObject-based
> API.  Apart from that, the maintainers' plan is to further align the two
> ports as much as possible, ideally simply stacking the GTK+ port on top
> of WPE, with only a few additional tweaks for GTK+ integration.  This
> would lessen the maintenance burden for both ports and the project as a
> whole.
> 
> The WebKit team at Igalia thinks this port is on stable footing and has
> solid prospects for the future.  That's why we'd like to join the
> upstream community and continue our work there.
> 
> The patch with the port changes is in bug #171110 [3].  We have existing
> x86_64 buildbot configurations [4] that we would have to port over to
> the webkit.org build master.  We're planning further builder and tester
> configurations for ARM architectures in the future.  Layout test
> baselines would be landed separately.  (Those too would be subject to
> alignment with the GTK+ port.)
> 
> We're happy to address any questions or considerations.
> 
> Regards,
> Zan
> 
> [1]
> https://lists.webkit.org/pipermail/webkit-dev/2014-December/027087.html
> [2]
> https://blogs.igalia.com/magomez/2016/12/19/wpe-web-platform-for-embedded/
> [3] https://bugs.webkit.org/show_bug.cgi?id=171110
> [4] https://build-webkit.igalia.com/waterfall?category=WPE
> ___
> 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 to limit the size of the captured exception stack

[Maciej Stachowiak]

> On Mar 17, 2017, at 11:09 AM, Mark Lam  wrote:
> 
> Thanks for the reminder to back observations up with data.  I was previously 
> running some tests that throws StackOverflowErrors a lot (which tainted my 
> perspective), and I made a hasty conclusion which isn’t good.  Anyway, here’s 
> the data using an instrumented VM to take some measurements and a simple test 
> program that recurses forever to throw a StackOverflowError (run on a MacPro):
> 
> 1. For a release build of jsc shell:
> Time to capture exception stack = 0.002807 sec
> Number of stack frames captured = 31722
> sizeof StackFrame = 24
> total memory consumed = ~761328 bytes.
> 
> 2. For a debug build of jsc shell:
> Time to capture exception stack = 0.052107 sec
> Number of stack frames captured = 31688
> sizeof StackFrame = 24
> total memory consumed = ~760512 bytes.
> 
> So, regarding performance, I was wrong.  The amount of time taken to capture 
> the entire JS stack each time is insignificant.
> Regarding memory usage, ~760K is not so good, but maybe it’s acceptable.
> 
> Comparing browsers with their respective inspectors open:
> 
> 1. Chrome
> number of frames captured: 10
> length of e.stack string: 824 chars
> time to console.log e.stack: 0.27 seconds
> 
> 2. Firefox
> number of frames captured: 129
> length of e.stack string: 8831 chars
> time to console.log e.stack: 0.93 seconds
> 
> 3. Safari
> number of frames captured: 31722
> length of e.stack string: 218821 chars
> time to console.log e.stack: 50.8 seconds
> 
> 4. Safari (with error.stack shrunk to 201 frames at time of capture to 
> simulate my proposal)
> number of frames captured: 201
> length of e.stack string: 13868 chars
> time to console.log e.stack: 1 second
> 
> With my proposal, the experience of printing Error.stack drops from 50.8 
> seconds to about 1 second.  The memory used for capturing the stack also 
> drops from ~760K to 5K.
> 
> I wasn’t aware of the Error.stackTraceLimit, but that does sound like a 
> better solution than my proposal since it gives developers the ability to 
> capture more stack frames if they need it.  Chrome’s default 
> Error.stackTraceLimit appears to be 10.  MS appears to support it as well and 
> defaults to 10 
> (https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript
>  
> ).
>   Firefox does now.

Out of curiosity: Why does Firefox capture 129 frames instead of 31722 in this 
case? Do they have a hardcoded limit?

 - Maciej

> 
> Does anyone object to us adopting Error.stackTraceLimit and setting the 
> default to 10 to match Chrome?
> 
> Mark
> 
> 
> 
>> On Mar 16, 2017, at 11:29 PM, Geoffrey Garen > > wrote:
>> 
>> Can you be more specific about the motivation here?
>> 
>> Do we have any motivating examples that will tell us wether time+memory were 
>> unacceptable before this change, or are acceptable after this change?
>> 
>> In our motivating examples, does Safari use more time+memory than other 
>> browsers? If so, how large of a stack do other browsers capture?
>> 
>> We already limit the size of the JavaScript stack to avoid performance 
>> problems like the ones you mention in many other contexts. Why is that limit 
>> not sufficient?
>> 
>> Did you consider implementing Chrome’s Error.stackTraceLimit behavior?
>> 
>> Geoff
>> 
>>> On Mar 16, 2017, at 10:09 PM, Mark Lam >> > wrote:
>>> 
>>> Hi folks,
>>> 
>>> Currently, if we have an exception stack that is incredibly deep 
>>> (especially for a StackOverflowError), JSC may end up thrashing memory just 
>>> to capture the large stack trace in memory.This is bad for many reasons:
>>> 
>>> 1. the captured stack will take a lot of memory.
>>> 2. capturing the stack may take a long time (due to memory thrashing) and 
>>> makes for a bad user experience.
>>> 3. if memory availability is low, capturing such a large stack may result 
>>> in an OutOfMemoryError being thrown in its place.
>>>   The OutOfMemoryError thrown there will also have the same problem with 
>>> capturing such a large stack.
>>> 4. most of the time, no one will look at the captured Error.stack anyway.
>>> 
>>> Since there isn’t a standard on what we really need to capture for 
>>> Error.stack, I propose that we limit how much stack we capture to a 
>>> practical size.  How about an Error.stack that consists of (1) the top N 
>>> frames, (2) an ellipses, and (3) the bottom M frames?  If the number of 
>>> frames on the stack at the time of capture  is less or equal to than N + M 
>>> frames, then Error.stack will just show the whole stack with no ellipses.  
>>> For example, if N is 4 and M is 2, the captured stack will look something 
>>> like this:

Re: [webkit-dev] Port For Android

[Maciej Stachowiak]

Android is not a supported platforms for current WebKit and has not been in a 
while. You will not be able to build for Android without a major porting effort.

Android WebKit was originally a fork of an old version that may not have even 
been fully merged back before we purged it. Recent versions may be based on 
Blink under the covers. Current versions definitely do not come from the WebKit 
repository in any case.

Regards,
Maciej

> On Mar 7, 2017, at 5:07 PM, Patrick Wright  wrote:
> 
> Thanks, I saw that Webkit source from github came with an angle 
> implementation of android window that I assume would host a browser. it was 
> implemented in angle. Which to me just means the ability to host openGL ES on 
> Linux, Mac, etc.  I know that angle can be ported to Android. I guess that 
> may be one way to get my own browser window on Android. 
> 
> However, in the source code of android. There is an implementation of Webkit 
> show here: 
> https://developer.android.com/reference/android/webkit/package-summary.html 
>  
> . it is just very slow and restrictive. 
> 
> 
> If i wanted to get my own browser window and not use stock android webkit 
> implementation. That was super fast to load. What would you recommend if i 
> may ask?
>  
> 
> On Mar 7, 2017 7:45 PM, "Michael Catanzaro"  > wrote:
> On Tue, 2017-03-07 at 18:35 -0500, Patrick Wright wrote:
> > Is there a webkit port for Android that is readily available?  
> 
> No, sorry. This is actually the first time I've heard any interest in
> WebKit for Android.
> 
> > That comes with the minibrowser option that normal GTK webkit has.  I
> > want the mini browser for android but don't want to use angle if
> > possible.  
> 
> For better or for worse, all WebKit ports require ANGLE.
> 
> 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

Re: [webkit-dev] VM::setExclusiveThread()

[Maciej Stachowiak]

Good news that it doesn't affect Speedometer. Does this have any effect on pure 
JS benchmarks running in the browser (e.g. JetStream)?

 - Maciej

> On Feb 28, 2017, at 10:48 AM, Filip Pizlo  wrote:
> 
> Sounds good!
> 
> I agree that a 20% regression on a microbenchmark of the exclusive JSLock is 
> not a problem, since that's not how WebCore usually behaves and Speedometer 
> doesn't seem to care.
> 
> -Filip
> 
> 
>> On Feb 28, 2017, at 10:38 AM, Mark Lam  wrote:
>> 
>> I’ve run Speedometer many times on a quiet 13” MacBookPro: removing the use 
>> of exclusive thread status does not appear to impact performance in any 
>> measurable way.  I also did some measurements on a microbenchmark locking 
>> and unlocking the JSLock using a JSLockHolder in a loop.  The microbenchmark 
>> shows that removing exclusive thread status results in the locking and 
>> unlocking operation increasing by up to 20%.
>> 
>> Given that locking and unlocking the JSLock is a very small fraction of the 
>> work done in a webpage, it’s not surprising that the 20% increase in time 
>> for the lock and unlock operation is not measurable in Speedometer.  Note 
>> also that the 20% only impacts WebCore which uses the exclusive thread 
>> status.  For all other clients of JSC (which never uses exclusive thread 
>> status), it may actually be faster to have exclusive thread checks removed 
>> (simply due to that code doing less work).
>> 
>> I’ll put up a patch to remove the use of exclusive thread status.  This will 
>> simplify the code and make it easier to move forward with new features.
>> 
>> Mark
>> 
>> 
>>> On Feb 24, 2017, at 9:01 PM, Filip Pizlo  wrote:
>>> 
>>> Seems like if the relevant benchmarks (speedometer) are ok with it then we 
>>> should just do this. 
>>> 
>>> -Filip
>>> 
 On Feb 24, 2017, at 20:50, Mark Lam  wrote:
 
 The JSC VM has this method setExclusiveThread().  Some details:
 1. setExclusiveThread() is only used to forego actually locking/unlocking 
 the underlying lock inside JSLock.
 2. setExclusiveThread() is only used by WebCore where we can guarantee 
 that the VM will only ever be used exclusively on one thread.
 3. the underlying lock inside JSLock used to be a slow system lock.
 
 Now that we have fast locking, I propose that we simplify the JSLock code 
 by removing the concept of the exclusiveThread and always lock/unlock the 
 underlying lock.  This also give us the ability to tryLock the JSLock 
 (something I would like to be able to do for something new I’m working on).
 
 Does anyone see a reason why we can’t remove the concept of the 
 exclusiveThread?
 
 Thanks.
 
 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

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

Re: [webkit-dev] Upstreaming Tests from WebKit to Web Platform Tests

[Maciej Stachowiak]

> On Feb 6, 2017, at 5:15 PM, Alexey Proskuryakov  wrote:
> 
> 
>> 6 февр. 2017 г., в 12:28, Ryosuke Niwa > > написал(а):
>> 
>> The concern I've heard about is not how run-webkit-tests run the tests. It's 
>> about how a test is opened inside a browser, DRT, WTR while debugging.
> 
> +1
> 
> I think that making web platform tests more practical for engineers to work 
> with should be a pre-requisite for deeper integration.
> 
> From tools perspective, cleaning up the way we get supporting scripts for web 
> platform tests would be quite beneficial too. It is very hard to reason about 
> what happens in a merge that just updates .tar.gz files or a SHA hash.

I think the potential of more automated sync and two-way sync with Web Platform 
Tests is great.

I also agree with Alexey and Ryosuke. It needs to be easy to run this type of 
test, including loading it in the browser. And managing the merge should not 
impose extra burdens on the person developing a patch. Our regression test 
requirement already imposes a significant (but important!) burden and we 
shouldn't make it worse.

The extra work should be done either by an automated system or by a person who 
is focused on doing periodic merges.

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

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

[Maciej Stachowiak]

> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield  wrote:
> 
> Here’s a quick rundown of where we stand. Please correct me if any of this is 
> inaccurate.
> 
> There are a few separate issues:
> Path on disk of PAL folder: Sounds like everyone more-or-less agrees that 
> this should belong in Source/, not in Source/WebCore/. However, I believe 
> this is currently incompatible with Apple’s internal build infrastructure. If 
> that’s true, then this issue is decided.

While there are extra steps required, we can resolve this for PAL the same as 
was done for WTF. Or at least, I don't know of any issues that apply to PAL 
which did not apply to WTF at the time we moved it out. If you think you know 
of a reason and it's stuff we shouldn't talk about here, I'd be glad to discuss 
off-list.

> Namespace of PAL symbols: Sounds like everyone agrees there should just be a 
> top-level namespace PAL (and not WebCore::PAL).
> #include style of PAL headers: Sounds like everyone agrees this should be the 
>  style. There are two ways to achieve this:
> Add WebCore/ to the search path, and put PAL files in WebCore/pal/. This has 
> a problem where it is easy to include other files inside WebCore but outside 
> of PAL, since they are in the search path. This is the approach Don and I 
> took in our patch, and solved this problem by using the Python script to 
> check the #include lines.
> Put PAL files in WebCore/PAL/pal/, and add WebCore/PAL/ to the search path. 
> This has the same problem WTF has where there is a nested folder with the 
> same name.

Don't we have these same two choices if the include style is ? 
However, this concern is moot if PAL becomes a top-level item under Source, or 
at least is planned to go there even if not immediately.

> Presence of an Xcode project: Sounds like this is possible and the best way 
> forward. Does this work back to the earliest OS we build on?
> Static library or shared library: I was under the impression that using a 
> shared library could potentially have performance problems, which would not 
> occur with a static library. However, a shared library would enforce layering 
> naturally, whereas a static library would need either
> An application to link to it and not to WebCore, such as a unit test suite, or
> Some out-of-band layering enforcement, like a Python script.
>   I’m a little hesitant to rely on a testing application to 
> enforce layering in shipping code because some ports may choose not to build 
> those tests.

WTF works fine as a static library that's layered under JavaScriptCore, and it 
doesn't have any kind of out-of-band enforcement tool. As far as I know, this 
works fine and has never led to a layering violation or other problem. The only 
enforcement is that WTF builds as a separate static library in a separate 
project, and doesn't include JavaScriptCore headers.

Once again I would suggest that "do what WTF does" is likely to be a good 
solution.

> 
> 
> 
> 
> So, here are the items which need to be solved:
> Do Xcode cross-project references work going back to the oldest Xcode we 
> build on?
> Regarding issue #2 above, should I put source files in WebCore/pal or 
> WebCore/PAL/pal?

I prefer the latter because: (a) it's more forward-looking if we eventually 
move PAL out to its own top level; and (b) it won't accidentally allow includes 
of other WebCore headers through an overly-broad include path.

> How do people feel about relying on a non-shipping application to enforce 
> laying in shipping code?

It seems unnecessary. Being a separate module under source (or setting 
everything up as if it were that way already until we can move it) is 
sufficient for this kind of thing, as demonstrated by WTF.

> 
> 
> Also (note to self): I need to figure out the ForwardingHeaders story.
> 
> —Myles
> 
>> On Jan 14, 2017, at 10:47 AM, Konstantin Tokarev > > wrote:
>> 
>> 
>> 
>> 14.01.2017, 17:16, "Fujii Hironori" > >:
>>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev >> > wrote:
  Static library is just an (indexed) archive of object files, symbol 
 dependencies are not resolved when it is created. Instead this happens 
 when static library is linked into shared library or executable.
 
  If PAL is static and uses symbol from WebCore, link failure may happen 
 only[*] if that symbol is not used anywhere in WebCore itself (provided 
 that PAL stays after WebCore in linker command line and options like 
 --start-group/--end-group are not used).
 
  [*] Assuming linker behavior similar to ELF linkers
>>> 
>>> You can check unresolved symbols of the static library by creating a
>>> unit test executable of PAL.
>> 
>> Actually, it enough just to avoid adding WebCore to include directories of 
>> PAL, and code with 

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

[Maciej Stachowiak]

To be clear, I think PAL is a great move. Details like the namespace, placement 
of the code, and how includes look are all things that can be changed after the 
fact.

That said, I think we need to ultimately consider our porting layer to be the 
combination of PAL and WTF, so it is good for the two to be consistent. I hope 
revisions along these lines can be considered in due course.

Regards,
Maciej

> On Jan 11, 2017, at 3:30 PM, Olmstead, Don <don.olmst...@sony.com> wrote:
> 
> I was the one who did the WebCore::PAL namespace so I wanted to chime in on 
> why I went that route. We at Sony are newcomers to pushing to trunk so my 
> explanation might be entirely too idealistic but here goes.
>  
> I had thought of PAL as a library that is internal to WebCore that provides a 
> clear porting layer. I would not expect anyone outside of WebCore to be 
> linking to it. Because of that it was living inside Source/WebCore, and since 
> it was setup that way having an internal namespace of WebCore::PAL made sense 
> conceptually. Also in the future if PAL was successful I could see a WebKit2 
> equivalent.
>  
> Whatever the consensus is we’re looking forward to working on getting the PAL 
> layer up and running. We’re working on rebooting our port so we’re in a good 
> position to help build it out and do any refactoring to help create a clear 
> layering. Having a clear porting layer, especially one with tests, is 
> something we’re hoping will be beneficial to all the ports.
>  
> From: webkit-dev-boun...@lists.webkit.org 
> [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak
> Sent: Wednesday, January 11, 2017 2:05 PM
> To: Antti Koivisto <koivi...@iki.fi>
> Cc: Webkit Development List <webkit-dev@lists.webkit.org>; 
> mrobin...@igalia.com
> Subject: Re: [webkit-dev] WebCore/platform standalone library
>  
>  
> These both sound right to me. 
>  
> More generally, I would expect that over time, PAL would likely become a peer 
> project to WebCore instead of being inside it, much the same way WTF started 
> inside JavaScriptCore and eventually moved outside it in the source tree. In 
> the WTF case, it always had a separate top-level namespace.
>  
> On Jan 11, 2017, at 12:27 PM, Antti Koivisto <koivi...@iki.fi 
> <mailto:koivi...@iki.fi>> wrote:
>  
> Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
> top-level namespace (even if it currently happens to live in the WebCore 
> project)?
>  
> #include  would be more consistent with existing headers than 
> .
>  
>  
>   antti
>  
> On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield <mmaxfi...@apple.com 
> <mailto:mmaxfi...@apple.com>> wrote:
> After 18 months of no progress, Don Olmstead and I are getting the band back 
> together!
>  
> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
> <https://bugs.webkit.org/show_bug.cgi?id=143358> which incorporates feedback 
> from many different stakeholders (and as such, the direction is a little 
> different than where I was going with this in the beginning).
>  
> First of all, this isn’t a new project; instead, it’s a new target inside the 
> WebCore project. The target creates a static library which gets linked into 
> WebCore, which means that the enforcement mechanism can’t be done by the 
> linker. Instead, the layering will be enforced by a Python script, triggered 
> as an extra build step, which checks the symbol names inside the .a file as 
> well as #include directives in source code.
>  
> We opted for WebCore to include files using “#include ” instead of 
> just including Foo.h. Similarly, we are putting symbols inside the PAL 
> namespace, which is a child of the WebCore namespace. Therefore, inside 
> WebCore, you use PAL things by specifying “PAL::Foo”.
>  
> The first thing to move into PAL is the “crypto” subfolder, which is a good 
> candidate because it’s small, simple, yet also has platform-dependent 
> implementations.
>  
> We would love your feedback on this approach to help make the dream a reality!
>  
> Thanks,
> Myles and Don
>  
> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough <barraclo...@apple.com 
> <mailto:barraclo...@apple.com>> wrote:
>  
> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
>  
> Web Abstraction Toolbox (it’s hard to tell the difference between wat and WTF 
> sometimes…)
>  
> +1
>  
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://l

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

[Maciej Stachowiak]

These both sound right to me. 

More generally, I would expect that over time, PAL would likely become a peer 
project to WebCore instead of being inside it, much the same way WTF started 
inside JavaScriptCore and eventually moved outside it in the source tree. In 
the WTF case, it always had a separate top-level namespace.

> On Jan 11, 2017, at 12:27 PM, Antti Koivisto <koivi...@iki.fi> wrote:
> 
> Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
> top-level namespace (even if it currently happens to live in the WebCore 
> project)?
> 
> #include  would be more consistent with existing headers than 
> .
> 
> 
>   antti
> 
> On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield <mmaxfi...@apple.com 
> <mailto:mmaxfi...@apple.com>> wrote:
> After 18 months of no progress, Don Olmstead and I are getting the band back 
> together!
> 
> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
> <https://bugs.webkit.org/show_bug.cgi?id=143358> which incorporates feedback 
> from many different stakeholders (and as such, the direction is a little 
> different than where I was going with this in the beginning).
> 
> First of all, this isn’t a new project; instead, it’s a new target inside the 
> WebCore project. The target creates a static library which gets linked into 
> WebCore, which means that the enforcement mechanism can’t be done by the 
> linker. Instead, the layering will be enforced by a Python script, triggered 
> as an extra build step, which checks the symbol names inside the .a file as 
> well as #include directives in source code.
> 
> We opted for WebCore to include files using “#include ” instead of 
> just including Foo.h. Similarly, we are putting symbols inside the PAL 
> namespace, which is a child of the WebCore namespace. Therefore, inside 
> WebCore, you use PAL things by specifying “PAL::Foo”.
> 
> The first thing to move into PAL is the “crypto” subfolder, which is a good 
> candidate because it’s small, simple, yet also has platform-dependent 
> implementations.
> 
> We would love your feedback on this approach to help make the dream a reality!
> 
> Thanks,
> Myles and Don
> 
>> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough <barraclo...@apple.com 
>> <mailto:barraclo...@apple.com>> wrote:
>> 
>>> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak <m...@apple.com 
>>> <mailto:m...@apple.com>> wrote:
>>> 
>>> Web Abstraction Toolbox (it’s hard to tell the difference between wat and 
>>> WTF sometimes…)
>> 
>> +1
>> 
>> 
>> ___
>> 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 <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

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

Re: [webkit-dev] Thread naming policy in WebKit

[Maciej Stachowiak]

> On Jan 5, 2017, at 8:07 PM, Yusuke SUZUKI <utatane@gmail.com> wrote:
> 
> On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
> 
>> On Jan 5, 2017, at 9:37 AM, Brady Eidson <beid...@apple.com 
>> <mailto:beid...@apple.com>> wrote:
>> 
>> 
>>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI <utatane@gmail.com 
>>> <mailto:utatane@gmail.com>> wrote:
>>> 
>>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler <da...@apple.com 
>>> <mailto:da...@apple.com>> wrote:
>>> I understand the appeal of “org.webkit” and structured names but personally 
>>> I would prefer to read names that look like titles and are made up of words 
>>> with spaces, like these:
>>> 
>>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>>> “WebKit: JavaScript DFG Compiler” rather than “org.webkit.jsc.DFGCompiler”.
>>> 
>>> Not sure how well that would generalize to all the different names.
>>> 
>>> I like the idea of having a smart way of automatically making a shorter 
>>> name for the platforms that have shorter length limits.
>>> 
>>> One interesting idea I've come up with is that,
>>> 
>>> 1. specifying "org.webkit.ImageDecoder"
>>> 2. In Linux, we just use "ImageDecoder" part.
>>> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
>> 
>> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder” part 
>> is ever going to be used?
>> Is that because Windows could use “org.webkit.”?
> 
> What about if you just specify "Image Decoder" and we automatically convert 
> that to either "ImageDecoder" or "WebKit: Image Decoder" based on platform 
> thread name limits? Is there any case where we want a prefix other than 
> "WebKit: "?
> 
> Yeah. For the prefix case, automatically adding "WebKit: " is fine. The 
> current ToT has the name like "com.apple.IPC.ReceiveQueue".
> Previously I thought that we may need to convert it to "Apple WebKit:" or 
> something like that.
> But now, I think simply using "WebKit: IPC Receive Queue" is fine.
> 
> But I think automatically changing "ImageDecoder" to "Image Decoder" does not 
> work well with long names.
> There is a name like "AsynchrnousDisassembler". It is >= 15 characters. 
> "AsynchronousDisas" is not good for Linux.
> On the other hand, using "AsyncDisasm" => "WebKit: AsyncDisasm" is not good 
> for macOS.
> For macOS, we can choose more readable name like "WebKIt: Asynchronous 
> Disassembler".
> 
> So, I think Geoffrey's suggestion works well: using long / short name pairs. 
> Like,
> 
> ThreadName { "Asynchronous Disassembler", "AsyncDisasm" } // { const char*, 
> const char* }
> 
> // OR, 
> CREATE_THREAD_NAME("Asynchronous Disassembler", "AsyncDisasm") macro => 
> generating ThreadName("WebKit: Asynchronous Disassembler") on macOS, 
> ThreadName("AsyncDisasm") on Linux

If there's a good set of "short name" and "long name" length limits, it would 
be cool if we could check the length at compile time, which seems more feasible 
with the macro.

Regards,
Maciej

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

Re: [webkit-dev] Thread naming policy in WebKit

[Maciej Stachowiak]

> On Jan 5, 2017, at 9:37 AM, Brady Eidson  wrote:
> 
> 
>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI > > wrote:
>> 
>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler > > wrote:
>> I understand the appeal of “org.webkit” and structured names but personally 
>> I would prefer to read names that look like titles and are made up of words 
>> with spaces, like these:
>> 
>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>> “WebKit: JavaScript DFG Compiler” rather than “org.webkit.jsc.DFGCompiler”.
>> 
>> Not sure how well that would generalize to all the different names.
>> 
>> I like the idea of having a smart way of automatically making a shorter name 
>> for the platforms that have shorter length limits.
>> 
>> One interesting idea I've come up with is that,
>> 
>> 1. specifying "org.webkit.ImageDecoder"
>> 2. In Linux, we just use "ImageDecoder" part.
>> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
> 
> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder” part 
> is ever going to be used?
> Is that because Windows could use “org.webkit.”?

What about if you just specify "Image Decoder" and we automatically convert 
that to either "ImageDecoder" or "WebKit: Image Decoder" based on platform 
thread name limits? Is there any case where we want a prefix other than 
"WebKit: "?

 - Maciej

> 
> Again, back to Darin’s point, I don’t see any particular value in ever seeing 
> “org.webkit.”
> 
> Additionally, the way this proposal treats “ImageDecoder” as multiple words, 
> presumably separated on case-change, is problematic.
> 
> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”, 
> different from today.
> e.g. “IndexedDBServer”, which is probably what this should be called, would 
> expand to “Indexed D B Server"
> e.g. “GCController” would expand to “G C Controller”
> 
> —
> 
> Taking your proposal and running with it, I think we could do this:
> 
> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
> 
> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
> 2a - It could get truncated with ellipses: “AsynchronousDi…" 
> 
> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit: 
> Asynchronous Disassemb”
> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
> 
> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous 
> Disassembler"
> 
> Addendum: If we see value in having somethings flagged as “JSC” instead of 
> “WebKit”, we just augment the input to include that.
> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific 
> feature could be “WebKit. IndexedDB Server”
> 
> Thanks,
> ~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] Naming preference: SetForScope vs. TemporaryChange

[Maciej Stachowiak]

> On Dec 26, 2016, at 9:04 AM, Saam Barati  wrote:
> 
> Right. I see what you're saying. The name doesn't confuse me with respect to 
> these semantics but I see that's it's subtly wrong.
> 
> The use case I was thinking of is this:
> `
> class Foo {
>Foo() : m_change(someIntVariable, 20) { }
>...
>...
>ScopedChange m_change;
> };
> `
> 
> Which is admittedly an odd use case that probably doesn't exist in WebKit. 
> However, if this use case were common, the name ScopedChange feels wrong for 
> it. 

When you have a class intended for RAII-like use, making it also work as a data 
member or a heap object is a bit of a fool's errand. So I think it's ok to not 
account for this. If there was a sensible way to make a class only usable as 
local variable stack objects then this would be a great place to do it, though 
I don't think C++ has a good way to do that.

Regards,
Maciej

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

Re: [webkit-dev] Naming preference: SetForScope vs. TemporaryChange

[Maciej Stachowiak]

> On Dec 25, 2016, at 11:35 AM, Saam Barati <sbar...@apple.com> wrote:
> 
> I like ScopedChange the most out of all the names. It's a bit unfortunate 
> that such a name doesn't work well in the context of having a ScopedChange as 
> a member variable. I think TemporaryChange works much better as a name if the 
> use is as a member variable.
> 
> My hunch would be the most frequent use of this class is as a scoped change. 
> If almost all of the uses are indeed for this, my name preference would be:
> 1. ScopedChange
> 2. TemporaryChange
> 
> If there are a lot of uses where the class isn't used as a scoped change, my 
> preference would be to revert to TemporaryChange.

I'm not sure what distinction you are trying to draw between "scoped change" 
and "temporary change". It seems pretty clear that this class is meant to be 
used as a value object on the stack, so anything it does is scoped.

The distinction I was trying to draw is that, if you make additional changes to 
the value still within the scope of the object, they will be overwritten. That 
aspect isn't really captured by either "ScopedChange" or "TemporaryChange". 
That's because, in some fundamental underlying sense, what's really scoped is 
the restore of the original value, not the change. 

Maybe a concrete example would help show what I'm taking about:

// global
double tachyonFlux = 3.14;

void redirectEnginesToShield()
{
ScopedChange(tachyonFlux, 2.0);

doOneThing();

tachyonFlux = 1.0;

doAnotherThing();

// on scope exit, both the scopedChange and the explicit assignment are 
undone
}

Perhaps this doesn't matter in practice because there's never actually 
additional assignments in the scope of one of these things so it will be clear 
enough as actually used.

Regards,
Maciej


> 
> - Saam
> 
>> On Dec 23, 2016, at 6:50 AM, Maciej Stachowiak <m...@apple.com> wrote:
>> 
>> 
>> A few more coats of paint for the bike shed:
>> 
>> It's a little unusual to have a class name that's a verb phrase instead of a 
>> noun phrase. And in this case if you interpret "Set" as a noun you'll get 
>> entirely the wrong idea. Some alternatives that avoid this, but has the 
>> better clarity of "Scope" instead of "Temporary" would be "ScopedChange or 
>> "ScopedAssignment".
>> 
>> One additional thing to think about: the class doesn't just have the effect 
>> of limiting the assignment to a scope. It will also undo any further 
>> assignments to the reference it holds that happen until it is destroyed. 
>> Save-restore semantics like this are common but often the names involved 
>> highlight the restore rather than the setting. I can't think of a great name 
>> off the top of my head but something like RestoreOnScopeExit seems more 
>> technically accurate than SetForScope.
>> 
>> - Maciej
>> 
>>> On Dec 23, 2016, at 6:32 AM, Michael Catanzaro <mcatanz...@igalia.com> 
>>> wrote:
>>> 
>>> On Fri, 2016-12-23 at 05:42 +, Yusuke SUZUKI wrote:
>>>> Personally I like the name "SetForScope" since the name "scope"
>>>> states that this value change is tied to C++ scope.
>>> 
>>> Me too. The name is pretty clear. The first time I saw TemporaryChange
>>> I had to look at the implementation to see what it did.
>>> 
>>> 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

Re: [webkit-dev] Naming preference: SetForScope vs. TemporaryChange

[Maciej Stachowiak]

A few more coats of paint for the bike shed:

It's a little unusual to have a class name that's a verb phrase instead of a 
noun phrase. And in this case if you interpret "Set" as a noun you'll get 
entirely the wrong idea. Some alternatives that avoid this, but has the better 
clarity of "Scope" instead of "Temporary" would be "ScopedChange or 
"ScopedAssignment".

One additional thing to think about: the class doesn't just have the effect of 
limiting the assignment to a scope. It will also undo any further assignments 
to the reference it holds that happen until it is destroyed. Save-restore 
semantics like this are common but often the names involved highlight the 
restore rather than the setting. I can't think of a great name off the top of 
my head but something like RestoreOnScopeExit seems more technically accurate 
than SetForScope.

 - Maciej

> On Dec 23, 2016, at 6:32 AM, Michael Catanzaro  wrote:
> 
> On Fri, 2016-12-23 at 05:42 +, Yusuke SUZUKI wrote:
>> Personally I like the name "SetForScope" since the name "scope"
>> states that this value change is tied to C++ scope.
> 
> Me too. The name is pretty clear. The first time I saw TemporaryChange
> I had to look at the implementation to see what it did.
> 
> 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] Please hold off on commits

[Maciej Stachowiak]

Hello everyone,

At Apple, we are experiencing an unplanned outage in our continuous integration 
lab. This interferes with proper functioning buildbots, performance tests and 
EWS.
Currently we expect the outage will last throughout the weekend and possibly 
into early next week.

Last time we had a lengthy testing outage, many regressions crept into the tree 
and it took a while to get them all resolved. All of us at Apple are holding 
off on commits. We're asking other WebKit community members to be the same.

If the outage doesn't seem likely to be resolved soon by tomorrow, we'll likely 
set the SVN server to temporarily reject commits.

I apologize for the inconvenience. We are doing our utmost to get the service 
outage resolved.

Regards,
Maciej

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

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Maciej Stachowiak]

> On Sep 6, 2016, at 8:20 PM, Darin Adler <da...@apple.com> wrote:
> 
>> On Sep 6, 2016, at 6:43 PM, Maciej Stachowiak <m...@apple.com> wrote:
>> 
>> RefPtr does also have regular release() though. I'm not sure if this is for 
>> a practical reason or just no one has fixed it yet.
> 
> It’s still around until we finish getting rid of PassRefPtr, that’s all.
> 
>> A wacky solution, based on your suggestion for releaseImpl, would be to have 
>> a nonNull method which asserts the pointer is not null and then returns a 
>> self reference, so you'd do move(ref.nonNull()).
> 
> I don’t think we can do that. I don’t know how to change a RefPtr into a 
> Ref& in C++ even though we know the underlying object layout is identical.

I didn't notice that detail. In that case I'll just say that this non-central 
example shouldn't be a major consideration for naming data structure 
remove-and-get combo operations.

[It might be possible to make a way to convert a RefPtr<> to a Ref<> without 
refcount thrash that is closer to typical C++ conventions but I think 
suggestions along these lines are beyond my level of C++ knowledge. As a wild 
guess, perhaps a syntax like Ref x = notNull(move(refPtr)) could be made to 
work.]

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

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Maciej Stachowiak]

> On Sep 6, 2016, at 5:27 PM, Darin Adler <da...@apple.com> wrote:
> 
>> On Sep 6, 2016, at 4:48 PM, Maciej Stachowiak <m...@apple.com> wrote:
>> 
>> STL smart pointers have a 0-argument reset for non-returning remove instead, 
>> and convention seems to be to use swap() or move() for the returning remove 
>> on a smart pointer. So an alternate possibility would be to use the above 
>> convention for collections, but make smart pointers have no remove+get 
>> operation at all.
> 
> Our modern smart pointers follow the standard library convention you mention 
> above.
> 
> It’s the peculiar cases that need names, such as:
> 
> “assert this RefPtr is non-null to turn it into a Ref&&”, currently named 
> releaseNonNull

RefPtr does also have regular release() though. I'm not sure if this is for a 
practical reason or just no one has fixed it yet.

I am not sure about the non-null case. A wacky solution, based on your 
suggestion for releaseImpl, would be to have a nonNull method which asserts the 
pointer is not null and then returns a self reference, so you'd do 
move(ref.nonNull()).

> 
> “release the RefPtr inside the String”, currently named releaseImpl(), but 
> another possibility would be to have impl() be RefPtr& instead of 
> a StringImpl*, so you could do move(string.impl()) instead of 
> string.releaseImpl().

That seems pretty reasonable.

Regards,
Maciej



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

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Maciej Stachowiak]

I thought about why release() seems subtly wrong to me for collections, but not 
for smart pointers. Specifically, release() puts the focus on giving up 
ownership, but the in the case of a collection, the most important thing is 
removal from the collection, where giving up ownership is a detail of the 
removal. In particular, it doesn't leave a hole, like swap() on spot in the 
collection with a default-constructed value would, or like release() on a smart 
does. For this reason, I think move() is also wrong in the collection case).

For similar reasons, having a zero-argument remove() on a smart pointer would 
read a little weird. Sure, you can think of a smart pointer as a collection of 
one item, but our actual smart pointers either have clear() or no non-returning 
removal operation.

Therefore I wonder if consistency between smart pointers and collections is 
really the most important factor. Smart pointers and collections are different 
enough that their operations don't have to be named the same.

That said, I do have a proposal that I think is semantically OK for both smart 
pointers and collections, and also has the correct subject in all cases.


  Non-removing | 
  accessor | remove-only   | remove+get
---|---|-
get()  |erase()|  remove()   


This has the additional advantage of somewhat more consistency with std:: 
containers, which name the plain removal operation erase() rather than 
remove(). A downside is that anyone used to remove() may call it when erase() 
would do, possibly resulting in slightly less efficient code.

STL smart pointers have a 0-argument reset for non-returning remove instead, 
and convention seems to be to use swap() or move() for the returning remove on 
a smart pointer. So an alternate possibility would be to use the above 
convention for collections, but make smart pointers have no remove+get 
operation at all.


For comparison, here is the status quo:

  Non-removing | Smart pointer | Smart pointer | Container   | Container
  accessor | remove-only   | remove+get| remove-only | remove+get
---|---|---|-|-
get()  |N/A or clear() |  release()|  remove()   |  take()




> On Sep 6, 2016, at 11:07 AM, Geoffrey Garen  wrote:
> 
> “take” grinds my gears too — though I’ve gotten used to it, more or less.
> 
> I read “object.verb()” as a command, “verb”, directed at “object” (or 
> sometimes as a question, “verb?”, directed at “object”). I think most APIs 
> are phrased this way. And if I were Antonin Scalia, I would make the 
> originalist argument that Smalltalk originally defined a method in 
> object-oriented programming as a message to a receiver — not a message about 
> a sender.
> 
>> In the context of a container, take() sort of makes sense by parallel to 
>> get(). Though get() could be interpreted as either what the caller is doing 
>> or what the callee is doing.
>> 
>> In other words, you could say that in the code below, function something 
>> gets an item from the collection. In that sense, take() is a parallel 
>> construct. Of course, you could instead say that function something asks 
>> collection to get an item. That's what makes take() not make sense. But I am 
>> not sure release() makes sense either way, for a collection. It conveys 
>> letting go of the item but doesn't seem to convey fetching in the sake way 
>> get() or take() do. I don't think move() would be right in this context 
>> either.
>> 
>> function something(Collection& collection, Key& key)
>> {
>>  doSomething(collection.get(key))
>> }
> 
> Though it is possible to read “get” in this context as “I get from 
> collection”, I think it is more natural to read “get” as a command: 
> “collection, get this for me”. Other access verbs on collections, such as 
> “find”, “add”, and “remove”, establish this pattern.
> 
>> Given that explanation, I think a possible direction is to rename the smart 
>> pointer release() operation to take(). Many of our smart pointers already 
>> have a get(). And the idea of taking the underlying value from a smart 
>> pointer kind of makes sense, even though it is caller-perspective.
> 
> I’ve gotten used to “take", so I won’t call it pure applesauce, but it’s not 
> my preference.
> 
> My favorite suggestion so far is “move”. The C++ standard helps make this a 
> good word because it introduces as terms of art std::move and “move” 
> constructors. But perhaps it is bad for a function named “move” not to return 
> an rvalue reference. For example, one might object to 
> “std::move(collection.move(key))”. Why the double move?
> 
> My second favorite suggestion is “release”. It matches a term of art in std 
> smart pointers and it’s pretty clear.
> 
> My third favorite suggestion is “remove”. For collections, “remove” is just 
> plain clearer. But “remove” is worse for non-collection value 

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Maciej Stachowiak]

> On Sep 5, 2016, at 3:30 PM, Dan Bernstein  wrote:
> 
>> 
>> On Sep 5, 2016, at 10:13 AM, Darin Adler  wrote:
>> 
>> Hi folks.
>> 
>> WebKit has some critical functions that involve asking an object to give up 
>> ownership of something so the caller can take ownership.
>> 
>> In the C++ standard library itself, this is called move, as in std::move.
>> 
>> In WebKit smart pointers, we call this operation release, as in 
>> RefPtr::releaseNonNull and String::releaseImpl.
>> 
>> In WebKit collections, we call this operation take, as in HashMap::take and 
>> ExceptionOr::takeReturnValue.
>> 
>> The release vs. take terminology is distracting to my eyes. The verb “take" 
>> states what the caller wishes to do, and the verb “release” states what the 
>> caller wants the collection or smart pointer to do.
> 
> This can be addressed by renaming take to give (hey, it’s right there in the 
> subject).

It's logical but reads perhaps a little strangely:

Value& = map.give(key)
X* = x_ref.give()

 - Maciej

> 
>> My first thought was be to rename the take functions to use the word release 
>> instead, but I fear it might make them harder to understand instead of 
>> easier and clearly it would make them longer.
>> 
>> Does anyone have other ideas on how to collapse WebKit project terminology 
>> down so we don’t have three different single words that are used to mean 
>> almost the same thing?
> 
> Rename release to give, too?
> ___
> 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] Terminology for giving up ownership: take, release, move

[Maciej Stachowiak]

> On Sep 5, 2016, at 3:18 PM, Ryosuke Niwa  wrote:
> 
> On Mon, Sep 5, 2016 at 2:48 PM, Ryosuke Niwa  > wrote:
>> On Mon, Sep 5, 2016 at 2:47 PM, Filip Pizlo  wrote:
>>> 
>>> On Sep 5, 2016, at 2:35 PM, Ryosuke Niwa  wrote:
>>> 
>>> On Mon, Sep 5, 2016 at 10:13 AM, Darin Adler  wrote:
>>> 
>>> Hi folks.
>>> 
>>> WebKit has some critical functions that involve asking an object to give up
>>> ownership of something so the caller can take ownership.
>>> 
>>> In the C++ standard library itself, this is called move, as in std::move.
>>> 
>>> In WebKit smart pointers, we call this operation release, as in
>>> RefPtr::releaseNonNull and String::releaseImpl.
>>> 
>>> In WebKit collections, we call this operation take, as in HashMap::take and
>>> ExceptionOr::takeReturnValue.
>>> 
>>> The release vs. take terminology is distracting to my eyes. The verb “take"
>>> states what the caller wishes to do, and the verb “release” states what the
>>> caller wants the collection or smart pointer to do. My first thought was be
>>> to rename the take functions to use the word release instead, but I fear it
>>> might make them harder to understand instead of easier and clearly it would
>>> make them longer.
>>> 
>>> 
>>> I agree the verb "take" is not semantically sound here.  How about
>>> HashMap::receiveReleased / ExceptionOr::receiveReleased?  Or simply
>>> HashMap::released / ExceptionOr::takeReleased?  Even HashMap::receive
>>> / ExceptionOr::receiveReturnValue might work better because "receive"
>>> is more a passive form of accepting the ownership of something.
>>> 
>>> 
>>> I don't think that HashMap::receiveReleased() fits with
>>> Subject::verbPhrase().  In HashMap::take(), the HashMap is releasing
>>> ownership of a value.  So, it is releasing it.  It's definitely not
>>> receiving it.
>> 
>> Oh I see.  Sorry, I had assumed they were just taking Ref<>&& as an
>> argument.  In that case, release() definitely seems like the right
>> terminology to use.
> 
> Hm... now that I recall the semantics of HashMap::take, I've started
> to think that "release()" on its own may not be the right name for
> collections because these member functions remove an item from a
> collection while releasing the ownership.  Maybe "removeAndRelease()"
> or "removeToRelease()" would do.
> 
> Alternatively, we could make the regular "remove()" always return the
> removed value (or maybe this would result in more code bloat / runtime
> cost?)

Current HashMap::remove returns a boolean which indicates wether the item was 
found. It also avoids doing a move to a temporary. So both efficiency and 
compatibility may be relevant considerations. If you consider the option of 
renaming the basic remove as well as the one that returns a value, you could 
use erase() for the one that doesn't return the value and remove() for the one 
that does.





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

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Maciej Stachowiak]

> On Sep 5, 2016, at 2:35 PM, Ryosuke Niwa  wrote:
> 
> On Mon, Sep 5, 2016 at 10:13 AM, Darin Adler  > wrote:
>> Hi folks.
>> 
>> WebKit has some critical functions that involve asking an object to give up 
>> ownership of something so the caller can take ownership.
>> 
>> In the C++ standard library itself, this is called move, as in std::move.
>> 
>> In WebKit smart pointers, we call this operation release, as in 
>> RefPtr::releaseNonNull and String::releaseImpl.
>> 
>> In WebKit collections, we call this operation take, as in HashMap::take and 
>> ExceptionOr::takeReturnValue.
>> 
>> The release vs. take terminology is distracting to my eyes. The verb “take" 
>> states what the caller wishes to do, and the verb “release” states what the 
>> caller wants the collection or smart pointer to do. My first thought was be 
>> to rename the take functions to use the word release instead, but I fear it 
>> might make them harder to understand instead of easier and clearly it would 
>> make them longer.
> 
> I agree the verb "take" is not semantically sound here.  How about
> HashMap::receiveReleased / ExceptionOr::receiveReleased?  Or simply
> HashMap::released / ExceptionOr::takeReleased?  Even HashMap::receive
> / ExceptionOr::receiveReturnValue might work better because "receive"
> is more a passive form of accepting the ownership of something.

receive() is still caller-perspective so it doesn't solve the issue with 
take(). If you wanted a detailed and wordy name, getAndRemove() would be 
accurate and callee-perspective (though natural for collections but not so much 
for smart pointers). getAndRelease() would make sense for smart pointers, but 
not really for collections, since you normally ask collections to remove (or 
delete or erase), but to release.

release() as shorthand for getAnd{Remove,Release}() seems ok, though it would 
be local jargon and I'm not sure it would be very readable in the case of a 
HashMap, to those who are not familiar with it. Without knowing the jargon, it 
would not be apparent that this line of code does a lookup and removes the 
item: value = map.release(key)

Regards,
Maciej

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

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Maciej Stachowiak]

> On Sep 5, 2016, at 10:13 AM, Darin Adler  wrote:
> 
> Hi folks.
> 
> WebKit has some critical functions that involve asking an object to give up 
> ownership of something so the caller can take ownership.
> 
> In the C++ standard library itself, this is called move, as in std::move.
> 
> In WebKit smart pointers, we call this operation release, as in 
> RefPtr::releaseNonNull and String::releaseImpl.
> 
> In WebKit collections, we call this operation take, as in HashMap::take and 
> ExceptionOr::takeReturnValue.
> 
> The release vs. take terminology is distracting to my eyes. The verb “take" 
> states what the caller wishes to do, and the verb “release” states what the 
> caller wants the collection or smart pointer to do. My first thought was be 
> to rename the take functions to use the word release instead, but I fear it 
> might make them harder to understand instead of easier and clearly it would 
> make them longer.
> 
> Does anyone have other ideas on how to collapse WebKit project terminology 
> down so we don’t have three different single words that are used to mean 
> almost the same thing?

In the context of a container, take() sort of makes sense by parallel to get(). 
Though get() could be interpreted as either what the caller is doing or what 
the callee is doing.

In other words, you could say that in the code below, function something gets 
an item from the collection. In that sense, take() is a parallel construct. Of 
course, you could instead say that function something asks collection to get an 
item. That's what makes take() not make sense. But I am not sure release() 
makes sense either way, for a collection. It conveys letting go of the item but 
doesn't seem to convey fetching in the sake way get() or take() do. I don't 
think move() would be right in this context either.

function something(Collection& collection, Key& key)
{
doSomething(collection.get(key))
}


Given that explanation, I think a possible direction is to rename the smart 
pointer release() operation to take(). Many of our smart pointers already have 
a get(). And the idea of taking the underlying value from a smart pointer kind 
of makes sense, even though it is caller-perspective.

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

Re: [webkit-dev] Using ResourceTiming API for testing

[Maciej Stachowiak]

> On Apr 24, 2016, at 8:54 AM, Yoav Weiss  wrote:
> 
> Hey,
> 
> As part of implementing support for `` more tests are 
> needed to make sure resources are properly reused. The easiest way to test 
> that is using the ResourceTiming API, which is currently implemented behind 
> an off-by-default build-time flag.
> 
> Therefore, I'd like to move the implementation of ResourceTiming API to be 
> behind an off-by-default runtime flag, so I can use it in preload's layout 
> tests. (By adding an internal API that turns it on when needed)
> 
> Would that be OK with the project? Any reasons I shouldn't be doing that?

Seems good as long as it doesn't hurt performance or correctness when runtime 
disabled.

 - Maciej

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

Re: [webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

[Maciej Stachowiak]

> On Mar 31, 2016, at 11:14 AM, youenn fablet  wrote:
> 
> Hi,
> 
> I like the idea of a runtime flag.
> I would wait to enable fetch use until it passes sufficient numbers of 
> web-platform-test tests.
> This can be tested in http://w3c-test.org/tools/runner/index.html 
>  (folder fetch/api).
> I think th
> 
> Also, are you suggesting that it would be in addition to the compile flag or 
> as a replacement?

As long as everything is hidden and there are no bad side effects when the 
runtime flag is off, it could substitute entirely for a compile-time flag. I'd 
like to see us using runtime flags more and compile-time flags less.

Regards,
Maciej

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

[webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

[Maciej Stachowiak]

The recently released Safari Technology Preview has gotten more people living 
on builds close to trunk, which is cool. Some people pointing out that the 
current state of Fetch API causes problems - it's not quite complete enough for 
real web apps that want to use it, but its presence breaks the detection that 
would substitute a polypill.

I'd like to suggest that it should be disabled until it's complete enough to 
work. I would propose a runtime flag instead of compile-time so it can continue 
to be tested by our regression tests while it's getting finished up.

Regards,
Maciej

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

Re: [webkit-dev] mobile Safari WebGL crash

[Maciej Stachowiak]

This doesn't sound like correct or expected behavior to me. Can you please file 
a bug at http://bugs.webkit.org/ with steps to reproduce?

 - Maciej

> On Dec 23, 2015, at 7:58 AM, Roman Sementsov  wrote:
> 
> Hello,
> I'm Blend4Web developer and currently trying to investigate an issue for 
> mobile Safari. If you launch any WebGL web application, say our Planetarium 
> demo ( 
> https://www.blend4web.com/apps/webplayer/webplayer.html?load=../../assets/interactivity/solar_system/solar_system_en.json
>  
> )
>  which uses frame buffers, and make Safari application go to background 
> (press home button, press power button, wait 10 seconds and turn it on 
> again), it appears that Safari will brake the frame buffers with gl. 
> INVALID_FRAMEBUFFER_OPERATION error.
> 
> Now I'm trying to reproduce the issue using the latest WebKit version 
> compiled for mobile devices. Unfortunately I could start it only in the 
> simulator mode (with the help of this article  
> https://webkit.org/blog/3457/building-webkit-for-ios-simulator/
>  ). It works 
> fine and doesn't crash. I was trying to find some info on how to run it on a 
> mobile device, but I didn't succeed. Could you please tell me, how I can run 
> mobile Safari with the latest WebKit version on a real device?
> 
> Thanks.
> ___
> 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 for serializing alpha channel values; request for algorithm help

[Maciej Stachowiak]

Minimal strings should round trip ok, but will it still be accurate enough if 
the client attempts to do math with them? It's at least theoretically possible 
someone may try to multiply by the alpha value.

 - Maciej

> On Nov 2, 2015, at 12:28 AM, Gavin Barraclough  wrote:
> 
>> On Nov 1, 2015, at 7:40 PM, Darin Adler > > wrote:
>> 
>> 3) Can you help me come up with a super-efficient algorithm to do this 
>> serialization?
> 
> Table lookup? FP conversion code is hard, and this is a relatively small 
> number of strings.
> 
> You could also flatten all the strings into one big string, and take out a 
> pointer indirection (below).
> 
> Data would add 1.5k to binary size, which is probably competitive to 
> instruction space for an optimized implementation.
> 
> cheers,
> G.
> 
> 
> const char* unsignedCharToFloatString(unsigned char x)
> {
> return unsignedCharToFloatStrings[x];
> }
> 
> static const char* unsignedCharToFloatStrings[256] = {
> "0",
> "0.003",
> "0.007",
> "0.01",
> "0.015",
> "0.019",
> "0.023",
> "0.027",
> "0.03",
> "0.035",
> "0.039",
> "0.043",
> "0.047",
> "0.05",
> "0.054",
> "0.058",
> "0.062",
> "0.066",
> "0.07",
> "0.074",
> "0.078",
> "0.082",
> "0.086",
> "0.09",
> "0.094",
> "0.098",
> "0.1",
> "0.105",
> "0.109",
> "0.113",
> "0.117",
> "0.12",
> "0.125",
> "0.129",
> "0.133",
> "0.137",
> "0.14",
> "0.145",
> "0.149",
> "0.152",
> "0.156",
> "0.16",
> "0.164",
> "0.168",
> "0.172",
> "0.176",
> "0.18",
> "0.184",
> "0.188",
> "0.192",
> "0.196",
> "0.2",
> "0.203",
> "0.207",
> "0.21",
> "0.215",
> "0.219",
> "0.223",
> "0.227",
> "0.23",
> "0.235",
> "0.239",
> "0.243",
> "0.247",
> "0.25",
> "0.254",
> "0.258",
> "0.262",
> "0.266",
> "0.27",
> "0.274",
> "0.278",
> "0.282",
> "0.286",
> "0.29",
> "0.294",
> "0.298",
> "0.3",
> "0.305",
> "0.309",
> "0.313",
> "0.317",
> "0.32",
> "0.325",
> "0.329",
> "0.333",
> "0.337",
> "0.34",
> "0.345",
> "0.349",
> "0.352",
> "0.356",
> "0.36",
> "0.364",
> "0.368",
> "0.372",
> "0.376",
> "0.38",
> "0.384",
> "0.388",
> "0.392",
> "0.396",
> "0.4",
> "0.403",
> "0.407",
> "0.41",
> "0.415",
> "0.419",
> "0.423",
> "0.427",
> "0.43",
> "0.435",
> "0.439",
> "0.443",
> "0.447",
> "0.45",
> "0.454",
> "0.458",
> "0.462",
> "0.466",
> "0.47",
> "0.474",
> "0.478",
> "0.482",
> "0.486",
> "0.49",
> "0.494",
> "0.498",
> "0.5",
> "0.505",
> "0.509",
> "0.513",
> "0.517",
> "0.52",
> "0.525",
> "0.529",
> "0.533",
> "0.537",
> "0.54",
> "0.545",
> "0.549",
> "0.552",
> "0.556",
> "0.56",
> "0.564",
> "0.568",
> "0.572",
> "0.576",
> "0.58",
> "0.584",
> "0.588",
> "0.592",
> "0.596",
> "0.6",
> "0.603",
> "0.607",
> "0.61",
> "0.615",
> "0.619",
> "0.623",
> "0.627",
> "0.63",
> "0.635",
> "0.639",
> "0.643",
> "0.647",
> "0.65",
> "0.654",
> "0.658",
> "0.662",
> "0.666",
> "0.67",
> "0.674",
> "0.678",
> "0.682",
> "0.686",
> "0.69",
> "0.694",
> "0.698",
> "0.7",
> "0.705",
> "0.709",
> "0.713",
> "0.717",
> "0.72",
> "0.725",
> "0.729",
> "0.733",
> "0.737",
> "0.74",
> "0.745",
> "0.749",
> "0.752",
> "0.756",
> "0.76",
> "0.764",
> "0.768",
> "0.772",
> "0.776",
> "0.78",
> "0.784",
> "0.788",
> "0.792",
> "0.796",
> "0.8",
> "0.803",
> "0.807",
> "0.81",
> "0.815",
> "0.819",
> "0.823",
> "0.827",
> "0.83",
> "0.835",
> "0.839",
> "0.843",
> "0.847",
> "0.85",
> "0.854",
> "0.858",
> "0.862",
> "0.866",
> "0.87",
> "0.874",
> "0.878",
> "0.882",
> "0.886",
> "0.89",
> "0.894",
> "0.898",
> "0.9",
> "0.905",
> "0.909",
> "0.913",
> "0.917",
> "0.92",
> "0.925",
> "0.929",
> "0.933",
> "0.937",
> "0.94",
> "0.945",
> "0.949",
> "0.952",
> "0.956",
> "0.96",
> "0.964",
> "0.968",
> "0.972",
> "0.976",
> "0.98",
> "0.984",
> "0.988",
> "0.992",
> "0.996",
> "1",
> };
> 
> const char* unsignedCharToFloatStringSingleIndirection(unsigned char x)
> {
> return 
> 

Re: [webkit-dev] PSA: you should use WTF::Lock and WTF::Condition instead of WTF::SpinLock, WTF::Mutex, WTF::ThreadCondition, std::mutex, std::condition_variable, or std::condition_variable_any

[Maciej Stachowiak]

 On Aug 21, 2015, at 12:11 PM, Michael Catanzaro mcatanz...@igalia.com wrote:
 
 On Wed, 2015-08-19 at 13:08 -0700, Filip Pizlo wrote:
 TL;DR.  Don’t use WTF::SpinLock, WTF::Mutex, std::mutex,
 WTF::ThreadCondition, std::condition_variable, or
 std::condition_variable_any.  They waste CPU time and they waste
 memory.  Use WTF::Lock and WTF::Condition instead.
 
 Hi, I recommend adding a style-checker rule to enforce this, if you
 haven't already.

I wonder also if we can get rid of all use of the old options. Then there would 
be no need for a style checker rule, we'd just delete them. Maybe a good 
starter project, if someone wants to learn a bit about WebKit.

 - Maciej


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

Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks

[Maciej Stachowiak]

 On Jul 7, 2015, at 3:36 AM, Yusuke SUZUKI utatane@gmail.com wrote:
 
 On Tue, Jul 7, 2015 at 8:54 AM, Geoffrey Garen gga...@apple.com 
 mailto:gga...@apple.com wrote:
 I’m suggesting a default runloop for non-web content.
 
 I haven’t read through the details of integrating with the web content 
 definition of micro task.
 
 Geoff
 
 OK. Reinventing runloop each time is costly.
 On the other hand, sometimes, users would like to use the other runloop such 
 as libuv.
 So what do you think about providing the both.
 
 1. Provide default runloop in JSC
 2. Provide the way to register callback for enqueueJob. If it's provided, (1) 
 is disabled for this VM.
 
 (1) would become the following (quick proposal)
 
 void JSContextRunMicrotasks(JSContextRef, unsigned someFlags);
 bool JSContextIsMicrotasksEmpty(JSContextRef);
 
 In this case, if we would like to close the VM,
 
 bool executed = false;
 do {
 executed = false;
 for each context belongging to the given VM {
 if (JSContxtIsMicrotasksEmpty(context)) {
 executed = true;
 JSContextRunMicrotasks(context, ...);
 }
 }
 } while (executed);
 Close(VM);

I think that Goeff's suggest would be that microtasks would normally run 
without the client having to make any special calls at all to account for them. 
Possibly this may imply a requirement of running a CFRunLoop on the relevant 
thread.

I also think your API doesn't account for nesting very well - it requires the 
client app to know the VM nesting level. It would be better if that was tracked 
and micro tasks could run on exiting the outermost VM and/or 

 
 (2) would become the original proposal.
  
 
 On Jul 6, 2015, at 4:44 PM, Maciej Stachowiak m...@apple.com 
 mailto:m...@apple.com wrote:
 
 
 Should JS be defining an event loop abstraction that WebCore then uses? That 
 would be weird, because the required behavior of the even loop in web 
 content is chock full of issues that are not at all related to JavaScript. 
 JSC doesn't even know enough to run microtasks at all the right times (from 
 reading the spec it seems that way, at least) for the Web case. Or are you 
 saying it would have a fallback runloop for non-Web contents?
 
 Regards,
 Maciej
 
 On Jul 6, 2015, at 3:24 PM, Geoffrey Garen gga...@apple.com 
 mailto:gga...@apple.com wrote:
 
 I think it would be better for JavaScriptCore to handle micro tasks 
 natively.
 
 It’s not so great for each client to need to reinvent the microtask runloop 
 abstraction.
 
 Geoff
 
 On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI utatane@gmail.com 
 mailto:utatane@gmail.com wrote:
 
 Hi WebKittens,
 
 I've landed the update of the ES6 Promise implementation.
 Through this work, I've experimentally added the internal private 
 function, @enqueueJob(JS function, JS array for arguments).
 This is corresponding to the ES6 spec EnqueueJob[1].
 
 This EnqueueJob handler is now tightly integrated with WebCore's microtask 
 infrastructure. So in JSC framework side, we cannot use this function.
 As a result, current JSC framework disables Promise because there's no 
 event loop abstraction.
 
 So I propose the API configuring euqueueJob handler into JSC VM (That 
 corresponds to the Realm in ECMA spec).
 
 Like,
 
 void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef, 
 JSEnqueueJobCallback, void* callbackData);
 
 What do you think about this?
 
 [1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob 
 http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob
 
 Best Regards,
 Yusuke Suzuki
 ___
 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 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] JSC framework API proposal: setting a handler for enqueuing tasks

[Maciej Stachowiak]

Should JS be defining an event loop abstraction that WebCore then uses? That 
would be weird, because the required behavior of the even loop in web content 
is chock full of issues that are not at all related to JavaScript. JSC doesn't 
even know enough to run microtasks at all the right times (from reading the 
spec it seems that way, at least) for the Web case. Or are you saying it would 
have a fallback runloop for non-Web contents?

Regards,
Maciej

 On Jul 6, 2015, at 3:24 PM, Geoffrey Garen gga...@apple.com wrote:
 
 I think it would be better for JavaScriptCore to handle micro tasks natively.
 
 It’s not so great for each client to need to reinvent the microtask runloop 
 abstraction.
 
 Geoff
 
 On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI utatane@gmail.com 
 mailto:utatane@gmail.com wrote:
 
 Hi WebKittens,
 
 I've landed the update of the ES6 Promise implementation.
 Through this work, I've experimentally added the internal private function, 
 @enqueueJob(JS function, JS array for arguments).
 This is corresponding to the ES6 spec EnqueueJob[1].
 
 This EnqueueJob handler is now tightly integrated with WebCore's microtask 
 infrastructure. So in JSC framework side, we cannot use this function.
 As a result, current JSC framework disables Promise because there's no event 
 loop abstraction.
 
 So I propose the API configuring euqueueJob handler into JSC VM (That 
 corresponds to the Realm in ECMA spec).
 
 Like,
 
 void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef, 
 JSEnqueueJobCallback, void* callbackData);
 
 What do you think about this?
 
 [1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob 
 http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob
 
 Best Regards,
 Yusuke Suzuki
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto: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] Support registerProtocolHandler in WebKit2

[Maciej Stachowiak]

 On May 21, 2015, at 7:38 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Fri, May 22, 2015 at 1:25 AM, Anders Carlsson ander...@apple.com wrote:
 Sam Weinig 2015-05-15 10:12:54 PDT:
 Support for navigator.registerProtocolHandler/unregisterProtocolHandler is 
 not something we want to support in WebKit2 at this time as we are not 
 confident it is a good Web API. This might be a good conversation for 
 webkit-dev.
 
 I agree with Sam.
 
 So what else should web-based email or IRC clients or some such use to
 integrate with sites that offer mailto and irc URLs? Especially for
 email it seems like a worthwhile thing to solve. And that there's no
 cross-browser way to do it in 2015 is somewhat of a shame.

I think it’s useful to have an API for the mailto use case. A lot of people 
use webmail as their default mail client, and it seems nice to make mailto: 
links do the right thing for them. We do allow changing the default Mail reader 
to a native app, at least on Mac. I would almost consider having 
navigator.registerProtocolHandler just for that use case.

On the face of it, the registerProtocolHandler API seems more general than 
necessary, but the actual spec for it has a whitelist of specific schemes, most 
of which seem reasonable for this kind of purpose: 
https://html.spec.whatwg.org/#custom-handlers 
https://html.spec.whatwg.org/#custom-handlers

I am curious what Sam and Anders dislike about this API, and whether it might 
be something we’d want to support at least with a more restricted set of 
schemes.

(I am more dubious of the content handler aspect.)

Regards,
Maciej

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

Re: [webkit-dev] Force Click events

[Maciej Stachowiak]

Beth gave a bunch of details of the feature, but I would like to expand a bit 
on our standards plans, and cross-platform potential of this feature:

(1) We definitely plan to take this proposal to standards bodies. We decided to 
implement a prototype first, so we could ensure we have something that makes 
sense, because this is a complex area.

(2) We’re not necessarily set on “force as the term to use instead of 
“pressure”. We’re open to changing this depending on what the standards 
community thinks. We did think about alignment with pointer events, but force 
has the advantage of brevity and also of working better in names of the new 
events like “mouseforcedown” (“mousepressuredown would sound weird). Also, I 
find that discussing force vs. pressure tends to start physics arguments about 
whether the hardware in relevant input devices is actually measuring Pascals 
(pressure) or Newtons (force). Force is just our placeholder choice.

(3) Pointer Events don’t actually provide everything needed to make best use of 
the Force Trackpad. One notable feature of the device is that, by convention, 
it supports two levels of press, each with a haptic. We thought the “deep 
press” was worthy of its own set of events.

(4) We did not want to make Pointer Events a prereq for making use of pressure. 
First, we don’t want to require web developers to change event models to get 
new functionality, and second, we’re not entirely sure we support the idea of 
combining mouse events and touch events into one concept. We are fine with 
adding the same functionality to Pointer Events, of course, and would even 
recommend that.

(5) It’s not our intent to make our event extensions specific to Apple 
hardware. However, the force trackpad does have interesting features beyond 
pressure-sensitivity. In particular, it has a software-controlled haptic for 
click and by convention has two levels of clicking. We would like events that 
support this well, but are also reasonable for hardware without these specific 
features.

Regards,
Maciej

 On May 8, 2015, at 3:25 AM, Jonathan Rimmer jon.rim...@gmail.com wrote:
 
 [I originally posted this to webkit-help, but Benjamin suggested suggested I 
 post here instead]
 
 Hi all,
 
 On Twitter, I was bemoaning the lack of communication re. the recently added 
 Force Click events to Benjamin Poulain, and he suggested, probably correctly, 
 that I am out of the loop with respect to WebKit development. There had, he 
 said, been dicussion of this feature on the mailing lists, bugzilla, and the 
 recent contributors meeting.
 
 This therefore, is my attempt to get in the loop on this issue. I was 
 wondering if anyone could help me find the following:
 
 Mailing list posts: I have tried searching with the Gmane archive, but have 
 been unable to find any dicussions on this issue. It doesn't help that Gmane 
 does not support phrasal searches, meaning I cannot easily search for force 
 click, force touch, pointer events, etc. Can anyone suggest what words I 
 should search for, or direct me to the relevant threads?
 
 Contributors meeting: There was apparently a 1 hour discussion at the 
 contributor's meeting that lead to the agreement that the Force Click 
 experiment should be upstreamed. Is there a video or sound recording of this 
 dicussion available? Is there a set of minutes or other summary available? A 
 blog post?
 
 Documentation: Benjamin said the feature has been upstreamed to gather 
 feedback. Can anyone point me to developer documentation that would assist in 
 using/testing the feature? Or something like the Surfin' Safari blog posts 
 that introduced the CSS gradient feature?[1]
 
 I am also curious about the decision to develop a non-standard feature 
 instead of implementing Pointer Events? The Point Events spec defines a 
 pressure property on pointer events that seems analagous to the force 
 property introduced by this feature. Why was a proprietary solution pursued 
 instead of adopting the W3C standard? What does the Force Click events offer 
 that Pointer Events do not?
 
 Also, how does the development of this feature relate to the WebKit project's 
 stated goal of standards compliance? [2]. Is there a plan to standardise this 
 events with the W3C? Is it wise to name this feature after a marketing term 
 used by a single contributor organisation? Is it intended that these features 
 will be interopable with pressure-sensitive hardware other than Apple's Force 
 Touch trackpad?
 
 [1] https://www.webkit.org/blog/175/introducing-css-gradients/
 [2] https://www.webkit.org/projects/goals.html
 
 Thanks,
 Jon
 ___
 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] Force Click events

[Maciej Stachowiak]

Beth gave a bunch of details of the feature, but I would like to expand a bit 
on our standards plans, and cross-platform potential of this feature:

(1) We definitely plan to take this proposal to standards


 On May 8, 2015, at 3:25 AM, Jonathan Rimmer jon.rim...@gmail.com wrote:
 
 [I originally posted this to webkit-help, but Benjamin suggested suggested I 
 post here instead]
 
 Hi all,
 
 On Twitter, I was bemoaning the lack of communication re. the recently added 
 Force Click events to Benjamin Poulain, and he suggested, probably correctly, 
 that I am out of the loop with respect to WebKit development. There had, he 
 said, been dicussion of this feature on the mailing lists, bugzilla, and the 
 recent contributors meeting.
 
 This therefore, is my attempt to get in the loop on this issue. I was 
 wondering if anyone could help me find the following:
 
 Mailing list posts: I have tried searching with the Gmane archive, but have 
 been unable to find any dicussions on this issue. It doesn't help that Gmane 
 does not support phrasal searches, meaning I cannot easily search for force 
 click, force touch, pointer events, etc. Can anyone suggest what words I 
 should search for, or direct me to the relevant threads?
 
 Contributors meeting: There was apparently a 1 hour discussion at the 
 contributor's meeting that lead to the agreement that the Force Click 
 experiment should be upstreamed. Is there a video or sound recording of this 
 dicussion available? Is there a set of minutes or other summary available? A 
 blog post?
 
 Documentation: Benjamin said the feature has been upstreamed to gather 
 feedback. Can anyone point me to developer documentation that would assist in 
 using/testing the feature? Or something like the Surfin' Safari blog posts 
 that introduced the CSS gradient feature?[1]
 
 I am also curious about the decision to develop a non-standard feature 
 instead of implementing Pointer Events? The Point Events spec defines a 
 pressure property on pointer events that seems analagous to the force 
 property introduced by this feature. Why was a proprietary solution pursued 
 instead of adopting the W3C standard? What does the Force Click events offer 
 that Pointer Events do not?
 
 Also, how does the development of this feature relate to the WebKit project's 
 stated goal of standards compliance? [2]. Is there a plan to standardise this 
 events with the W3C? Is it wise to name this feature after a marketing term 
 used by a single contributor organisation? Is it intended that these features 
 will be interopable with pressure-sensitive hardware other than Apple's Force 
 Touch trackpad?
 
 [1] https://www.webkit.org/blog/175/introducing-css-gradients/
 [2] https://www.webkit.org/projects/goals.html
 
 Thanks,
 Jon
 ___
 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] Client Hints

[Maciej Stachowiak]

 On May 6, 2015, at 4:49 AM, Yoav Weiss y...@yoav.ws wrote:
 
 
 
 On Wed, May 6, 2015 at 8:41 AM, Ryosuke Niwa rn...@webkit.org 
 mailto:rn...@webkit.org wrote:
 On Tue, May 5, 2015 at 11:35 PM, Yoav Weiss y...@yoav.ws 
 mailto:y...@yoav.ws wrote:
 On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa rn...@webkit.org 
 mailto:rn...@webkit.org wrote:
 I do have the same concern over terse names.  I don't see any point in saving 
 13 bytes by abbrebiating DevicePixelRadio as DPR.
 
 In the case of ResourceWidth, we can't get this number until we trigger a 
 layout.  It doesn't seem desirable to slow down the page load speed by 
 eagering triggering layout before loading each image.  How do we plan to work 
 around that?
 
 The resource width is planned to be based on the `sizes` attribute when 
 available, and to fall back to the viewport width when it is not.
 There are no plans to delay image loading waiting for layout, nor are there 
 current plans to use the layout information once we have it, as that would 
 introduce undesired raciness. 
 
 Okay, thanks for the clarification. Perhaps the spec should explictily state 
 that.
 
  
 Good idea. I'll file a spec issue.
 
 Can I take the feedback here as a green light to implement (assuming that the 
 header name concerns will be addressed)? Are there other blocking issues? Any 
 other feedback?


Some more questions/comments about RW:

- Is maybe-image-width-maybe-viewport-width a useful value? Perhaps there 
should be an always-present header for viewport width, and one for resource 
width that is present only when known? Though I’m not sure you can get a 
resource width even in the case where it’s known.

- The “sizes attribute allows units which can’t be calculated down to px 
without doing a full style resolution, such as “em and “ex”. The HTML spec 
even has an example using em units. But RW requires a number in CSS px units. 
How can this be reconciled with preloading happening before style is resolved?

- I don’t think making viewport-size-based decisions on the server side makes 
sense, because what do you do when the viewport is resized? Do you reissue the 
HTTP request for the image?

- The premise of this spec is to allow an image server to provide multiple 
representations when the markup can’t be changed, but sizes=“” is a new 
attribute, so old markup won’t already have it, and it’s normally only useful 
when doing client-size image selection with srcset=“”. In what case would it 
make sense to combine client-side and server side selection?

- What do you do when sizes=“” is changed on the client side? Do you have to 
issue a fresh HTTP request?

The fact that this is all unclear in the current Internet-Draft is part of what 
makes me think it’s not quite ready for prime time.


More general questions that remain:

- Why require the server to opt into receiving these headers at all? Why not 
just always send?
- Why multiple headers instead of one that can contain multiple tokens? That 
would allow a clearer name while maintaining compactness.

General thoughts:

- I am kind of skeptical of doing image selection on the server side. The 
claimed use cases of not wanting to change the markup don’t make sense to me, 
since to make effective use of the spec as written you may need to change your 
markup. That said, if there is real-world demand for this approach, and if we 
can resolve some of the thorny technical issues, I won’t object to an 
implementation. Right now I’m still not fully convinced this technology is 
compatible with image preloading.


Regards,
Maciej

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