Re: [webkit-dev] Request for position: Canvas 2D display-p3 support

[Sam Weinig via webkit-dev]

Hi Christopher,

We are in favor of this proposal.

- Sam

> On Jun 9, 2021, at 6:39 PM, Christopher Cameron via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> (and sorry for the duplicate post here, I mangled the headers on the previous 
> post!)
> 
> This is a request for WebKit's position on display-p3 support for Canvas 2D. 
> This is already being tracked in bugs.webkit.org  
> here .
> 
> Summary:
> 
> Adds a color space parameter to CanvasRenderingContext2DSettings, which 
> defaults to "srgb" and can take on the value of "display-p3". Adds 
> ImageDataSettings, which allows specifying a color space parameter to 
> getImageData/createImageData and related constructors.
> 
> Spec:
> 
> WhatWG spec changes merged in this PR 
> .
> 
> Tests:
> 
> https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/wide-gamut-canvas
>  
> 
> Includes tests of ImageData (get and put), and ensuring no loss when doing 
> toBlob and toDataURL round-trips.
> 
> Thank you for your feedback!
> 
> Christopher
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Request for position: preferCurrentTab

[Sam Weinig via webkit-dev]

Hi Elad,

Are there other existing uses of the term “tab” in other web exposed APIs? It 
feels a bit wrong to be wrong to be encoding that specific UI treatment into 
API.

- Sam

> On Jun 9, 2021, at 4:20 AM, Elad Alon via webkit-dev 
>  wrote:
> 
> This is a request for WebKit's position on adding a dictionary member in 
> MediaStreamConstraints called preferCurrentTab. If preferCurrentTab is set to 
> true, the user agent will display the current tab as the most prominent 
> option in the media-picker which getDisplayMedia invokes.
> 
> Links:
> Explainer 
> 
> Spec 
> ChromeStatus 
> ___
> 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] Use of Swift (for bridging) in the WebKit project

[Sam Weinig via webkit-dev]

Hi Jer,

I think it sounds like a reasonable rule to allow Swift for bridging purposes 
only, with the caveat that we should prefer Objective-C/C where it can be used.

The one other place that Swift seems reasonable for WebKit is in the definition 
and refinement of Swift bindings to WebKit’s public API.

That is to say, for the time being, we should avoid Swift in tools and core 
functionality.

Thanks for bringing this up on the list.

- Sam

> On Jun 8, 2021, at 3:57 PM, Jer Noble via webkit-dev 
>  wrote:
> 
> Hi all!
> 
> We're working on some new features that currently use APIs exposed through 
> Swift. We have not yet approved writing and committing WebKit code in Swift, 
> given runtime, library, and just plain mental overhead that comes with adding 
> a new language to the project. But I'd argue that doing so for the purpose of 
> allowing existing C++ code to call into Swift APIs is probably not terrible.
> 
> Should we relax our "no new language" policy, only for the purposes of 
> allowing our core language code to call into APIs in Swift?
> 
> (ref: https://bugs.webkit.org/show_bug.cgi?id=226757)
> 
> Thanks, and look forward to hearing from everyone,
> 
> -Jer
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Is anyone building with USE(DIRECT2D)?

[Sam Weinig via webkit-dev]

Hi WebKit-dev,

Is anyone still using attempting to build using USE(DIRECT2D) enabled? 
Recently, I updated files to “keep” it working, but in some I have seen things 
that obviously wouldn’t compile and think it is probably unmaintained. 

So is anyone using it?

- Sam


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

Re: [webkit-dev] New EWS Non-Unified builder

[Sam Weinig via webkit-dev]

Hi,

I am curious about the current state of our knowledge about the various 
benefits we are gaining from Unified Source. I think it is important to 
reevaluate it from time to time to ensure we are still getting the benefits we 
want (as there are some not so insignificant downsides). I know when it was 
introduced, it was a win for clean builds but I don’t believe there have been 
any recent measurements.

So, does anyone have any recent measurements of clean build times with and 
without unified sources enabled? If so, what is the current delta?

- Sam

> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> 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] Making WTF::StringImpl and WTF::AtomString thread-safe

[Sam Weinig via webkit-dev]

Hey Geoff and Chris,

> On Dec 1, 2020, at 9:21 AM, Geoff Garen via webkit-dev 
>  wrote:
> 
> A few thoughts here:
> 
> 1. It’s not just ref counting. 
> 
> To make String thread-safe, you also need to address all other data members. 
> That means all state in m_hashAndFlags, including the 8bit/16bit state.
> 
> It appears that your testing strategy did not reveal this point so far; so, 
> you probably need to expand your plan for unit testing concurrent access to a 
> string, with a focus on writing tests that fail with the current 
> implementation.
> 
> 2. Performance is a challenge.
> 
> I’ve tested making String thread-safe pretty extensively. On modern Apple 
> Silicon, it’s free. But on Intel chips, it’s very expensive.

First of all, crazy!

> 
> Because it’s so expensive, and because we have a no regression policy for 
> performance, I don’t think there’s a way to land this change in pieces. It 
> has to be a mega-patch, so we can test its performance as a whole.

Were you able to quantify anything additional about the performance regression 
on Intel, for instance, if there were any types of String usage that were 
particularly hard hit? If not (or you haven’t tried), do you think there are 
any metrics we should look into gathering that might help pin point where 
things could maybe be optimized? Ideally we would be able to identify places 
where we unnecessarily ref-deref StringImpls where either a move or judicious 
use of StringView would work just as well. 

The Blink document (linked in the bugzilla bug) suggests they identified some 
mitigations, but I am not clear they will be representative for us today.

Putting on my old bindings hat, one area that might be able to get some wins 
here is how Strings (and other ref counted things, but let’s stay focused) are 
passed from the JS bindings layer to the DOM. In most cases Strings should be 
able to be moved into the DOM without refcount churn, but since many of our 
functions take `const String&` or `const AtomString&` we lose out.

- Sam

> 
> 3. I’m surprised by the premise that thread-safe String is a requirement for 
> FontCache and/or the GPU Process.
> 
> It’s certainly a false premise that there’s consensus on this premise, since 
> I do not agree.
> 
> Can you share some problem statements regarding FontCache and/or the GPU 
> Process that explain the problem we’re trying to solve?
> 
> Thanks,
> Geoff
> 
>> On Dec 1, 2020, at 9:09 AM, Chris Lord via webkit-dev 
>>  wrote:
>> 
>> Hi all,
>> 
>> As part of the work for making FontCache thread-safe, it's necessary for
>> there to be a thread-safe AtomString. After discussion, it seems that a
>> thread-safe StringImpl is generally desirable and GPUProcess also has a
>> need of it. I've filed a bug to track this work:
>> https://bugs.webkit.org/show_bug.cgi?id=219285
>> 
>> Google have already done this for Blink and there's a nice plan and lots
>> of discussion to read. Their plan document is linked in the bug. I think
>> we'd be well-served by taking broadly the same approach, which is to
>> make ref-counting on StringImpl atomic and to guard AtomStringTable
>> access with a lock.
>> 
>> Making String thread-safe has implications, of course, and I'd like to
>> open discussion on this - Making ref-counting atomic on StringImpl has a
>> significant, negative impact on the expense of ref and deref operations.
>> I'm interested in discussing how we should approach this in terms of
>> tracking the work in Bugzilla and how to go about landing it. Perhaps
>> people also have alternative ideas?
>> 
>> On the bug is a first-run at implementing the above approach, currently
>> minus the follow-up of everywhere taking into consideration that
>> String/AtomString are now thread-safe. The impact on StringImpl
>> ref/deref performance has it running on my Xeon desktop machine at about
>> 30-50% of non-atomic ref/deref performance. Speedometer 2.0 takes a 1-8%
>> hit considering error margins, but I'm fairly certain it's mostly on the
>> higher end of that and I've not run enough iterations just yet.
>> Jetstream 1.1 seems practically unaffected, I can't run 2.0 with or
>> without the patch, it appears to hang the browser on the bomb-workers
>> test (at least if it completes, it's not in a reasonable time-frame). I
>> would guess that results may vary wildly depending on platform and
>> available atomic access primitives. As one might expect, the impact is
>> far less on a debug build.
>> 
>> I think the initial patch of making it thread-safe vs. the follow-up of
>> altering various areas to take it into account could/should be split,
>> but I assume we'd want to land them at the same time. This is cumbersome
>> with how WebKit Bugzilla currently works and I'd like to hear what
>> people think and how similar changes have been made in the past.
>> 
>> Thoughts?
>> 
>> Regards,
>> 
>> Chris
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Sam Weinig]

> On Oct 20, 2020, at 3:36 PM, Darin Adler  wrote:
> 
>> On Oct 20, 2020, at 3:09 PM, Sam Weinig  wrote:
>> 
>> For the Platform.h issue, I think we could probably engineer things in the 
>> short term to have a script phase that produces a Defines.txt that the other 
>> script phases and build rules depend on.
> 
> We definitely can, and it’s simpler than how we do it now. I have a patch 
> that does this for the makefile partly done and set aside. My approach was to 
> revise each script, one at a time, to take a file with the defines rather 
> than requiring they be passed on the command line. It doesn’t work for the 
> parts of the makefile itself that depend directly on checking the defines 
> (grep for findstring.*FEATURE_AND_PLATFORM_DEFINES to see those).
> 

Great. 

I think we can probably easily replace the makefile checking 
FEATURE_AND_PLATFORM_DEFINES itself ones.

For the ones conditionalizing adding to ADDITIONAL_BINDING_IDLS, those IDLs 
should just have the appropriate Conditional=* extended attribute added, then 
they can be included unconditionally in the makefile.

For the ones conditionalizing adding go USER_AGENT_STYLE_SHEETS, again, there 
doesn’t seem a real reason to keep that. The sheets are all preprocessed 
anyway, so we can just move those #ifdefs into the files.

I filed https://bugs.webkit.org/show_bug.cgi?id=218001 
<https://bugs.webkit.org/show_bug.cgi?id=218001> for this and will get that 
done regardless.

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

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Sam Weinig]

> On Oct 20, 2020, at 2:25 PM, Keith Rollin  wrote:
> 
>> On Oct 20, 2020, at 10:51, Andy Estes  wrote:
>> 
>>> On Oct 18, 2020, at 11:01, Sam Weinig  wrote:
>>> 
>>> One direct benefit of moving away from DerivedSources.make would likely be 
>>> (I say likely, as the details of how it works out are far from certain in 
>>> my mind) removing at least one place that a IDL file needs to be listed as 
>>> we would not need to explicitly the list the IDL file in 
>>> DerivedSources.make, and would only need to ensure it was in some 
>>> *input.xcfilelist.
>> 
>> The way I imagine this working is that the existing .idl file references in 
>> the (e.g., WebCore) project would become members in a target with a custom 
>> build rule for “*.idl”. Target membership is itself another list inside the 
>> .xcodeproj file, just one you manage through checkboxes in Xcode (and can be 
>> done reasonably quickly as part of adding a new file reference).
>> 
>> Whether or not this actually creates one fewer “place a IDL file needs to be 
>> listed” (which I think is a worthwhile goal), I think you should still 
>> remove the Makefile build phases from Xcode for the reasons you originally 
>> cited.
>> 
>> Andy
> 
> Overall, this sounds like an awesome endeavor. The initial reasons for using 
> Makefiles were sound ones (as Darin described), but there are also the 
> incumbent issues, such as maintainability and efficiency.
> 
> I wasn’t clear on what the alternative to Makefiles would look like, though. 
> The options that occur to me are:
> 
> * Custom build rules, as Andy describes. This seems to make sense, but I 
> wonder if it is flexible enough for all the cases we might want to put it 
> through. Our DerivedSources.make files process many types of files. I haven’t 
> checked, but I could imagine that not all of these files could be uniquely 
> distinguished by their suffixes. That is, there might be one set of *.foo 
> files that should be processed one way, and another set that should processed 
> another way. In those cases, I guess some suffixes could be changed to 
> accommodate the different processing.
> 
> * Using a set of Run Script build phases. That is, have a Run Script phase 
> for processing a specific set of *.idl files, another for processing one set 
> of *.foo files, a third for processing a different specific set of *.foo 
> files, and so on. I’m against this approach, though. While it offers lots of 
> flexibility, it’s not very maintainable. It would mean having to keep the set 
> of script inputs and outputs up-to-date, something that is fragile, even with 
> the help of the generate-xcfilelists utility script.
> 
> Of these two, the one based on custom build rules seems to make the most 
> sense. One need only add a file to an Xcode project and possibly a CMake 
> file. Of note, the dreaded .xcfilelists are not affected (and, if this 
> project can be taken to its extreme, we can get rid of the 
> DerivedSources*.xcfilelist files). I do worry about some efficiency issues, 
> though. For instance, one part of DerivedSources.make processes Platform.h 
> (and all its children) in order to extract some configuration information. 
> That processing is done once per DerivedSources.make invocation. If we move 
> to a model where a script is invoked once per *.idl file, then the overhead 
> is now multiplied by the number of *.idl files. We should watch for that. 
> (Perhaps your recent configuration/preferences/settings changes obviate the 
> need to pre-process Platform.h all the time?)

My thought is that we would be using a combination of Run Script phases and 
Build Rules, depending on the thing being generated. There are quite a few 
one-off scripts like makeprop.pl, makevalues.pl, 
makeSelectorPseudoClassAndCompatibilityElementMap.py, etc, that don’t have 
their input or output change very often at all, so are really much better 
suited for a Run Script phase. Whereas things like the IDLs are better suited 
for build rules.

For the Platform.h issue, I think we could probably engineer things in the 
short term to have a script phase that produces a Defines.txt that the other 
script phases and build rules depend on. Longer term, I would like to remove 
the need for it altogether, but that’s going to take additional work in the 
various scripts.


> Still, I’m open to a solution based on a single IDL.txt file that can be 
> shared by Xcode and CMake. It all depends on the details, the resulting 
> solution, and the trade-offs it makes.
> 
> Regarding Xcode vs. CMake, I certainly understand the reasons people would 
> like to see us move solely to CMake. But, for now, the plan is to see if we 
>

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Sam Weinig]

One direct benefit of moving away from DerivedSources.make would likely be (I 
say likely, as the details of how it works out are far from certain in my mind) 
removing at least one place that a IDL file needs to be listed as we would not 
need to explicitly the list the IDL file in DerivedSources.make, and would only 
need to ensure it was in some *input.xcfilelist.

But the idea of sharing “input” lists is very compelling. Just focusing on the 
IDL files themselves, I wonder if we could construct an input file that could 
serve both CMake and Xcode. It seems like CMake has the ability to read files 
into variables (https://cmake.org/cmake/help/latest/command/file.html#reading 
) so perhaps we 
could construct IDLs.txt that worked both as an input CMake and Xcode.

One issue that I don’t know how to solve in a good way is how to make adding 
files to the Xcode project easier. Perhaps this is somewhere that a script 
could help? Rather than adding the files to Sources.txt and then manually 
adding them to the Xcode project, perhaps we should just have a script that 
does this for us (either via manually invoking it or with the post processing 
that generates the xcfilelists?)

- Sam

> On Oct 18, 2020, at 10:38 AM, Darin Adler  wrote:
> 
> It would be wonderful to drastically cut down the repeated mentions of the 
> same filenames. People not on Xcode platforms probably focus primarily on 
> Xcode projects for this frustration. But I find it ridiculous how many places 
> I have to add things. For example, to add AbstractRange I had to add 
> filenames to:
> 
> Shared
> 
> - Sources.txt: Two source files and one IDL-generated file.
> 
> CMake:
> 
> - CMakeLists.txt: IDL file.
> - Headers.cmake: One source file and one IDL-generated file.
> 
> Xcode:
> 
> - DerivedSources.make: IDL file
> - WebCore.xcodeproj/project.pbxproj: IDL file, two source files, and Two 
> IDL-generated files.
> 
> And also, updating these checked-in generated files (that we’d need 
> regardless of build system, due to Apple build requirements):
> 
> - DerivedSources-input.xcfilelist
> - DerivedSources-output.xcfilelist
> 
> It seems like we should have a goal that you should not have to list 
> IDL-generated file names. That will be hard to accomplish in Xcode, though. 
> Maybe the reason we haven’t been so ambitious about getting this right for 
> CMake is that it’s so unreachable a goal for Xcode, given that we want the 
> files to show up in a clean way in the IDE?
> 
> And it would be good to find a way to share the lists of IDL files like we do 
> the list of source files. That seems relevant to this discussion of changing 
> DerivedSources.make.
> 
> — 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

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Sam Weinig]

> On Oct 17, 2020, at 12:34 PM, Fujii Hironori  <mailto:fujii.hiron...@gmail.com>> wrote:
> 
> 
> On Sun, Oct 18, 2020 at 2:00 AM Sam Weinig  <mailto:wei...@webkit.org>> wrote:
> 
> What are your thoughts on this? 
> 
> I'm disappointed. I want to use CMake for all ports.


I hear you, it would indeed be nice to have a single build system, but I’d 
really like to keep this thread specifically about the explicit issue of 
DerivedSources.make use for the current Xcode based builds.

I encourage you to start a separate thread about moving to a CMake only world. 
There are plenty of seperate challenges there (e.g. generating identical 
output, maintaining Xcode based work flows, etc.), and I am not sure how 
practical it is, but I think enumerating the challenging and discussing them is 
important.

Thanks,
- Sam

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

[webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Sam Weinig]

Hi webkit-dev,

I’d like to propose, and gauge feedback on, reducing (with the goal of 
ultimately removing) the use of Makefile based DerivedSources.make.

My understanding is that currently only the Xcode based ports still use 
DerivedSources.make, as all the CMake based ones have moved derived source 
generation to within CMake, so that should limit the scope of who this might 
affect.


Why do we use Makefiles today?

While I can’t recall the initial reasons for using Makefiles for derived 
sources, over the years there have been a number of advantages to it that I do 
know of. One clear advantage, that is no longer applicable, was code sharing, 
as earlier in the project, at least the Apple Windows port did utilize these 
Makefiles. Another was to work around some limitations in what dependencies 
Xcode was able to track with build rules. It seems at least some of the 
problems with build rules are no longer an issue, as we can now specify inputs 
to build rules, but I don’t if other problems will still be there, but for some 
prototyping I did, nothing yet has come up.


What would we move to?

As this only affects the Xcode based ports, we would move to distinct script 
phases and build rules in the Xcode project.  


Why make this change? What’s the benefit?

There are few reasons to consider this. One advantage is simplifying the build 
system. Rather than two dependency systems (one for Xcode, one for the 
Makefile) we reduce it down to one. And with additional knowledge of the stages 
and dependencies, Xcode could potentially parallelize more phases. We would 
would also save some time by avoiding invoking make in the first place. 

We also have a bit of an issue with make itself, as due to system requirements, 
we are forever stuck with Make 3.81, which is coming up on being 15 years old. 
More than once in the last year I have tried to troubleshoot makefile issues, 
looking for resources on the web, only to be stymied because the solutions I 
found required newer make.


What are the downsides?

One potential downside will be that it will be a bit harder for those without 
Xcode to add new types of derived sources. I am not sure how much a real 
problem in practice this will be, as editing project.pbxproj files is already 
required for just adding new files, but I want to call it out anyway.


What are your thoughts on this? Are there additional reasons we might want to 
stick with or move away from Makefile based derived sources?

Thanks,
-Sam

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

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

[Sam Weinig]

While I don’t want to take away from what Darin is saying here about correct 
usage of forward declaration and , I’d like to understand why we 
have two different compilation models supported in WebKit. Is there a reason 
both need to be supported? Can we remove one?

- Sam

> On Jul 14, 2020, at 10:40 AM, Darin Adler  wrote:
> 
> We need to be cautious about adding header includes to other headers. Adding 
> includes to .cpp files is likely fine and not a deeply consequential 
> decision, but adding to headers is something that can have a massive effect 
> on build times over time.
> 
>> On Jul 13, 2020, at 10:44 PM, hironori.fu...@sony.com 
>>  wrote:
>>  <>Modified: trunk/Source/WebCore/platform/graphics/ColorSerialization.h 
>> (264331 => 264332)
>> 
>> --- trunk/Source/WebCore/platform/graphics/ColorSerialization.h  
>> 2020-07-14 05:17:20 UTC (rev 264331)
>> +++ trunk/Source/WebCore/platform/graphics/ColorSerialization.h  
>> 2020-07-14 05:44:25 UTC (rev 264332)
>> @@ -25,6 +25,8 @@
>>  
>>  #pragma once
>>  
>> +#include 
> This change is wrong. The header to include here is Forward.h, not 
> WTFString.h. Not super-harmful since WTFString.h is already so widely 
> included, but we need to be really cautious in headers.
> 
>> Modified: trunk/Source/WebCore/svg/SVGParserUtilities.h (264331 => 264332)
>> 
>> --- trunk/Source/WebCore/svg/SVGParserUtilities.h2020-07-14 05:17:20 UTC 
>> (rev 264331)
>> +++ trunk/Source/WebCore/svg/SVGParserUtilities.h2020-07-14 05:44:25 UTC 
>> (rev 264332)
>> @@ -24,6 +24,7 @@
>>  #include "ParsingUtilities.h"
>>  #include 
>>  #include 
>> +#include 
> Same mistake.
> 
> I’d really like to come up with some other system for reviewing adding 
> headers to *headers*.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] C++17 is here. Should we use it?

[Sam Weinig]

> On Jun 17, 2019, at 8:45 AM, Guillaume Emont  wrote:
> 
> Quoting Sam Weinig (2019-06-17 03:25:15)
>> Did we ever land on conclusion here? 
>> 
>> I tried to use c++17 structured bindings (see 
>> https://bugs.webkit.org/show_bug.cgi?id=198905 
>> <https://bugs.webkit.org/show_bug.cgi?id=198905>) and it looks like most of 
>> the EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not 
>> into it.  Looking at the output, it seems like those bots may still be using 
>> GCC 6.4.0 (but I could be wrong here).
>> 
>> If the issue is getting these bots updated, can we do that? Are there any 
>> other bots that might need updating as well?
> 
> Sorry, yes indeed, jsc-mips and jsc-armv7 still use an old gcc. I've
> been working on updating this but got sidetracked. This is now on top of
> my priority list for this week. Thank you for your patience.
> 
> Guillaume
> 

Thanks Guillaume.

>> 
>> - Sam
>> 
>>> On May 11, 2019, at 7:48 AM, Michael Catanzaro  
>>> wrote:
>>> 
>>> On Fri, May 10, 2019 at 6:47 PM, Yusuke Suzuki  wrote:
>>>> 1. We can use GCC 7
>>>> 2. We can use libstdc++7
>>>> Is my understanding correct? Basically, this means that we can use cool 
>>>> C++17 features super aggressively :)
>>> 
>>> I would say you can use cool C++ 17 features cautiously, enjoying those 
>>> features when they work, and expecting the possibility of libstdc++7 bugs 
>>> causing them to not work.
>>> 
>>> I think our EWS bots are not yet on GCC 7, but that should be addressed 
>>> soon.
>>> 
>>> 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 <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] C++17 is here. Should we use it?

[Sam Weinig]

Did we ever land on conclusion here? 

I tried to use c++17 structured bindings (see 
https://bugs.webkit.org/show_bug.cgi?id=198905) and it looks like most of the 
EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not into it.  
Looking at the output, it seems like those bots may still be using GCC 6.4.0 
(but I could be wrong here).

If the issue is getting these bots updated, can we do that? Are there any other 
bots that might need updating as well?

- Sam

> On May 11, 2019, at 7:48 AM, Michael Catanzaro  wrote:
> 
> On Fri, May 10, 2019 at 6:47 PM, Yusuke Suzuki  wrote:
>> 1. We can use GCC 7
>> 2. We can use libstdc++7
>> Is my understanding correct? Basically, this means that we can use cool 
>> C++17 features super aggressively :)
> 
> I would say you can use cool C++ 17 features cautiously, enjoying those 
> features when they work, and expecting the possibility of libstdc++7 bugs 
> causing them to not work.
> 
> I think our EWS bots are not yet on GCC 7, but that should be addressed soon.
> 
> 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] Reminder regarding formatting uint64_t

[Sam Weinig]

> On Feb 27, 2019, at 6:46 PM, Michael Catanzaro  wrote:
> 
> On Wed, Feb 27, 2019 at 6:05 PM, Keith Rollin  wrote:
>> The underlying Cocoa os_log facility
> 
> Yeah this is really interesting too. RELEASE_LOG is Cocoa-specific, because 
> it's only backed by os_log. So when you change debug LOGs to RELEASE_LOG, 
> you're removing the logging for other platforms. I wonder if we should change 
> that.

This seems really unfortunate. It seems like RELEASE_LOG should use whatever 
the platform native logging mechanism is, and only depend on os_log where 
available. I filed https://bugs.webkit.org/show_bug.cgi?id=195182 to track this.

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

Re: [webkit-dev] Reminder regarding formatting uint64_t

[Sam Weinig]

> On Feb 27, 2019, at 4:05 PM, Keith Rollin  wrote:
> 
>> On Wed, Feb 27, 2019 at 2:36 PM Michael Catanzaro  
>> wrote:
>> Hi,
>> 
>> For the past several years, I've been regularly fixing -Wformat 
>> warnings that look like this:
>> 
>> ../../Source/WebKit/WebProcess/WebPage/WebPage.cpp:3148:46: warning: 
>> format ‘%llu’ expects argument of type ‘long long unsigned 
>> int’, but argument 6 has type ‘uint64_t’ {aka ‘long unsigned 
>> int’} [-Wformat=]
>> RELEASE_LOG_ERROR(ProcessSuspension, "%p - WebPage 
>> (PageID=%llu) - LayerTreeFreezeReason::ProcessSuspended was set when 
>> removing LayerTreeFreezeReason::PageTransition; current reasons are %d",
>> 
>> ^~
>> this, m_pageID, m_LayerTreeFreezeReasons.toRaw());
>>   
>> 
>> Problem is that uint64_t is long long unsigned int on Mac, but only 
>> long unsigned int on Linux. It can't be printed with %llu, so please 
>> use PRIu64 instead. E.g.:
>> 
>> LOG("%llu", pageID); // wrong
>> LOG("%" PRIu64, pageID); // correct
>> 
>> This is good to keep in mind for any sized integer types, but uint64_t 
>> in particular since this is what causes problems for us in practice.
> 
> 
> 
>> On Feb 27, 2019, at 14:47, Ryosuke Niwa  wrote:
>> 
>> We should probably stop using these formatting strings in favor of 
>> makeString by making *LOG* functions to use makeString behind the scene.
> 
> Formatting strings are pretty much required for the RELEASE_LOG* macros. 
> These macros require a string literal for the formatting information, so you 
> can’t say something like:
> 
> RELEASE_LOG_ERROR(ProcessSuspension, makeString(this, " - WebPage (PageID = 
> ", m_pageID, "), - LayerTreeFreezeReason::ProcessSuspended was set when 
> removing LayerTreeFreezeReason::PageTransition; current reasons are ", 
> m_LayerTreeFreezeReasons.toRaw()));
> 
> This would not result in a string literal being passed to RELEASE_LOG, and 
> you’d get a compiler error.
> 
> You could technically get away with passing your created string along with a 
> “%s” format specification:
> 
> RELEASE_LOG_ERROR(ProcessSuspension, "%s", makeString(this, " - WebPage 
> (PageID = ", m_pageID, "), - LayerTreeFreezeReason::ProcessSuspended was set 
> when removing LayerTreeFreezeReason::PageTransition; current reasons are ", 
> m_LayerTreeFreezeReasons.toRaw()));
> 
> But this is not advised. The underlying Cocoa os_log facility is able to 
> greatly compress the logs stored in memory and on disk, as well as get 
> corresponding performance benefits, by taking advantage of the fact that the 
> formatting string is a literal that can be found in the executable’s binary 
> image. When you log with a particular formatting string, that string is not 
> included in the log archive, but a reference to it is. In the case that 
> Michael gives, a reference to the big formatting string is stored along with 
> the pointer, the unsigned long long, and the integer. In the above example, a 
> reference to “%s” is stored, along with the fully-formatted string. This 
> latter approach takes up a lot more memory.
> 
> So go wild with the LOG* macros, but understand the restrictions with the 
> RELEASE_LOG* macros.

Seems like a fun project would be to attempt to generate the format string 
literal at compile time based on the parameters passed.

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

Re: [webkit-dev] Encoding and decoding ProcessID

[Sam Weinig]

> On Feb 24, 2019, at 11:55 AM, Adrien Destugues  
> wrote:
> 
> On Sun, Feb 24, 2019 at 10:52:53AM -0800, Sam Weinig wrote:
>> Hi Adrien,
>> 
>> Would you mind adding the compiler output when this happens? I’d like to see 
>> exactly what the error you are seeing is.
> 
> Sorry, here is the compiler output:
> http://paste.debian.net/1069971
> 
> In file included from 
> DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
> ../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp: In 
> static member function 'static bool 
> WebKit::NetworkResourceLoadParameters::decode(IPC::Decoder&, 
> WebKit::NetworkResourceLoadParameters&)':
> ../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:41: 
> error: no matching function for call to 
> 'IPC::Decoder::decode(WTF::ProcessID&)'
> if (!decoder.decode(result.parentPID))
> ^
> In file included from 
> ../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
> from 
> ../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
> from 
> ../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
> from 
> DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
> ../../Source/WebKit/Platform/IPC/Decoder.h:80:10: note: candidate: bool 
> IPC::Decoder::decode(bool&) 
> bool decode(bool&);
>  ^~
> ../../Source/WebKit/Platform/IPC/Decoder.h:80:10: note:   conversion of 
> argument 1 would be ill-formed:
> In file included from 
> DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
> ../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32: 
> error: cannot bind non-const lvalue reference of type 'bool&' to an rvalue of 
> type 'bool'
> if (!decoder.decode(result.parentPID))
> ~~~^
> In file included from 
> ../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
> from 
> ../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
> from 
> ../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
> from 
> DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
> ../../Source/WebKit/Platform/IPC/Decoder.h:82:10: note: candidate: bool 
> IPC::Decoder::decode(uint8_t&) 
> bool decode(uint8_t&);
>  ^~
> ../../Source/WebKit/Platform/IPC/Decoder.h:82:10: note:   conversion of 
> argument 1 would be ill-formed:
> In file included from 
> DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
> ../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32: 
> error: cannot bind non-const lvalue reference of type 'uint8_t& {aka unsigned 
> char&}' to an rvalue of type 'uint8_t {aka unsigned char}'
> if (!decoder.decode(result.parentPID))
> ~~~^
> In file included from 
> ../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
> from 
> ../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
> from 
> ../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
> from 
> DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
> ../../Source/WebKit/Platform/IPC/Decoder.h:84:10: note: candidate: bool 
> IPC::Decoder::decode(uint16_t&) 
> bool decode(uint16_t&);
>  ^~
> ../../Source/WebKit/Platform/IPC/Decoder.h:84:10: note:   conversion of 
> argument 1 would be ill-formed:
> In file included from 
> DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
> ../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32: 
> error: cannot bind non-const lvalue reference of type 'uint16_t& {aka short 
> unsigned int&}' to an rvalue of type 'uint16_t {aka short unsigned int}'
> if (!decoder.decode(result.parentPID))
> ~~~^
> In file included from 
> ../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
> from 
> ../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
> from 
> ../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
> from 
> DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
> ../../Source/WebKit/Platform/IPC/Decoder.h:86:10: note: candidate: bool 
> IPC::Decoder::decode(uint32_t&) 
> bool decode(uint32_t&);
>  ^~
> ../../Source/WebKit/Platform/IPC/Decoder.h:86:10: note:   conversion of 
> argument 1 would be

Re: [webkit-dev] Encoding and decoding ProcessID

[Sam Weinig]

Hi Adrien,

Would you mind adding the compiler output when this happens? I’d like to see 
exactly what the error you are seeing is.

- Sam  

> On Feb 24, 2019, at 9:54 AM, Adrien Destugues  
> wrote:
> 
> Hi there,
> 
> We are finally starting to look into moving the Haiku port to WebKit2.
> 
> We have hit one little problem I'm not sure how to solve. Our pid_t on
> 32bit Haiku is declared as a signed long integer (this is for legacy
> reasons and not something we can fix easily). Our uint32_t is a signed
> integer (not long). This creates a compilation error when using pid_t
> with IPC::Encoder, because none of the encode() functions match when
> trying to pass a pid_t in our case.
> 
> Our options seems to be:
> - Cast pid_t to int32_t when encoding it. I fear this would break other
>  platforms if they decide to use a 64bit pid_t, for example
> - Add an encode(pid_t) to the IPC::Encoder. I fear on other platforms it
>  would complain that this is the same as encode(int32_t) and break the
>  build
> - Define WTF::ProcessID as int32_t instead of pid_t, which I think could
>  work, afte rfixing some compiler warnings (we will need to cast back
>  to pid_t when passing it to OS functions, I think)
> 
> What do you think about it?
> 
> one example where encoding a pid is
> Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp
> 
> -- 
> Adrien.
> ___
> 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] Remove Credential Management code

[Sam Weinig]

Hey gang,

I’d like to propose removing the Credential Management code from WebCore.  Work 
began on supporting this spec in January of this year, but so far, only IDLs 
and stubs have been added.  In May, there was an effort to update the IDLs and 
stubs to the latest spec (https://webkit.org/b/172011) with the promise of 
continued work, but I don’t believe the further work took place.

Does anyone have concrete plans to work on this in the short term? If not, I 
think it makes sense to remove it.


Thanks,
- Sam
___
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)

[Sam Weinig]

> On Aug 29, 2017, at 6:36 PM, Maciej Stachowiak <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.

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

[Sam Weinig]

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


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

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)

[Sam Weinig]

> On Aug 29, 2017, at 11:03 AM, Geoffrey Garen  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?
> 
> We have some preliminary data that says incremental builds will be OK, but 
> not a full benchmark.
> 
> Here’s a full benchmark I propose to test incremental builds:
> 
>   Start 7 days ago in SVN history. Do a clean build.
> 
>   SVN update forward by 24 hours. Do an incremental build. Time this 
> build.
> 
>   Repeat 7 times. Average the results.
> 
> I think we should run this benchmark per project as we adopt unity builds, 
> starting with WTF.
> 
> In the beginning, when we adopt unity builds for WTF and then JavaScriptCore, 
> the benchmark can build just these projects and stop. Once we get to WebCore 
> and WebKit, the benchmark will take longer. Oh well.
> 
> If we get the bundling right, this benchmark should show obvious speedups. If 
> it shows no speedup or a slowdown, we’ve done something wrong and we need to 
> reconsider.


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.

- Sam

___
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?

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

- Sam

___
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

[Sam Weinig]

> On Jul 28, 2017, at 11:13 AM, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> 
>> On Jul 28, 2017, at 10:58 AM, Sam Weinig <wei...@apple.com 
>> <mailto:wei...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Jul 28, 2017, at 10:31 AM, JF Bastien <jfbast...@apple.com 
>>> <mailto:jfbast...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Jul 28, 2017, at 10:29, Sam Weinig <wei...@apple.com 
>>>> <mailto:wei...@apple.com>> wrote:
>>>> 
>>>> For some generic programming, this form can be dramatically shorter:
>>>> 
>>>> e.g. 
>>>> 
>>>> template>>> KeyTraitsArg, typename MappedTraitsArg>
>>>> template
>>>> ALWAYS_INLINE auto HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
>>>> MappedTraitsArg>::inlineAdd(K&& key, V&& value) -> AddResult
>>>> {
>>>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
>>>> HashFunctions>>(std::forward(key), std::forward(value));
>>>> }
>>>> 
>>>> vs.
>>>> 
>>>> template>>> KeyTraitsArg, typename MappedTraitsArg>
>>>> template
>>>> ALWAYS_INLINE typename HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
>>>> MappedTraitsArg>::AddResult HashMap<KeyArg, MappedArg, HashArg, 
>>>> KeyTraitsArg, MappedTraitsArg>::inlineAdd(K&& key, V&& value)
>>>> {
>>>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
>>>> 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.
> 

I didn’t mean to imply that we should have lambdas in ChangeLogs, only that 
people were probably getting used to that syntax. Sorry for the confusion.

-Sam

___
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

[Sam Weinig]

> On Jul 28, 2017, at 10:57 AM, Brady Eidson <beid...@apple.com> wrote:
> 
>> 
>> On Jul 28, 2017, at 10:29 AM, Sam Weinig <wei...@apple.com 
>> <mailto:wei...@apple.com>> wrote:
>> 
>> For some generic programming, this form can be dramatically shorter:
>> 
>> e.g. 
>> 
>> template> KeyTraitsArg, typename MappedTraitsArg>
>> template
>> ALWAYS_INLINE auto HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
>> MappedTraitsArg>::inlineAdd(K&& key, V&& value) -> AddResult
>> {
>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
>> HashFunctions>>(std::forward(key), std::forward(value));
>> }
>> 
>> vs.
>> 
>> template> KeyTraitsArg, typename MappedTraitsArg>
>> template
>> ALWAYS_INLINE typename HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
>> MappedTraitsArg>::AddResult HashMap<KeyArg, MappedArg, HashArg, 
>> KeyTraitsArg, MappedTraitsArg>::inlineAdd(K&& key, V&& value)
>> {
>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
>> HashFunctions>>(std::forward(key), std::forward(value));
>> }
> 
> In this example, yes it is notably shorter.
> 
> But neither of these definitions are remotely readable without puttin' on 
> your thinkin' cap.
> 
>> It is also the only format available for lambdas, so people are probably 
>> getting used to it.
> 
> Lambdas don't have the problem of prepare-ChangeLog completely missing edits 
> to a member function
> 
>> Not sure it’s worth it to avoid it.
> 
> My request was to be aware of this while prepare-ChangeLog was broken for 
> this case.
> Seems like that's almost fixed. :)

Oh ok. I thought you were proposing a ban.

- Sam

> 
> ~Brady
> 
>> 
>> - Sam
>> 
>>> On Jul 27, 2017, at 11:06 PM, Brady Eidson <beid...@apple.com 
>>> <mailto:beid...@apple.com>> wrote:
>>> 
>>> I just noticed this tonight. When a change is made to one of these 
>>> functions, prepare-ChangeLog doesn't log the functions that changed.
>>> 
>>> I have a question and a request.
>>> 
>>> Question:
>>> 
>>> The functions in question where I noticed this:
>>> auto WebURLSchemeTask::didComplete(const ResourceError& error) -> 
>>> ExceptionType
>>> 
>>> Would normally be written as:
>>> WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const 
>>> ResourceError& error)
>>> 
>>> Is there some actual value to using this syntax other than… being 
>>> syntactically different, and being just a little shorter?
>>> 
>>> Request:
>>> 
>>> Until we fix prepare-ChangeLog, and unless there is some great advantage to 
>>> this syntax that I'm not aware of… it's hold off on using it more.
>>> 
>>> Thanks,
>>> ~Brady
>>> ___
>>> 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] Using "auto <function()> -> returnType" breaks prepare-ChangeLog

[Sam Weinig]

> On Jul 28, 2017, at 10:31 AM, JF Bastien <jfbast...@apple.com> wrote:
> 
> 
> 
>> On Jul 28, 2017, at 10:29, Sam Weinig <wei...@apple.com 
>> <mailto:wei...@apple.com>> wrote:
>> 
>> For some generic programming, this form can be dramatically shorter:
>> 
>> e.g. 
>> 
>> template> KeyTraitsArg, typename MappedTraitsArg>
>> template
>> ALWAYS_INLINE auto HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
>> MappedTraitsArg>::inlineAdd(K&& key, V&& value) -> AddResult
>> {
>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
>> HashFunctions>>(std::forward(key), std::forward(value));
>> }
>> 
>> vs.
>> 
>> template> KeyTraitsArg, typename MappedTraitsArg>
>> template
>> ALWAYS_INLINE typename HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
>> MappedTraitsArg>::AddResult HashMap<KeyArg, MappedArg, HashArg, 
>> KeyTraitsArg, MappedTraitsArg>::inlineAdd(K&& key, V&& value)
>> {
>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
>> 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.

- Sam

> 
> 
>> - Sam
>> 
>>> On Jul 27, 2017, at 11:06 PM, Brady Eidson <beid...@apple.com 
>>> <mailto:beid...@apple.com>> wrote:
>>> 
>>> I just noticed this tonight. When a change is made to one of these 
>>> functions, prepare-ChangeLog doesn't log the functions that changed.
>>> 
>>> I have a question and a request.
>>> 
>>> Question:
>>> 
>>> The functions in question where I noticed this:
>>> auto WebURLSchemeTask::didComplete(const ResourceError& error) -> 
>>> ExceptionType
>>> 
>>> Would normally be written as:
>>> WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const 
>>> ResourceError& error)
>>> 
>>> Is there some actual value to using this syntax other than… being 
>>> syntactically different, and being just a little shorter?
>>> 
>>> Request:
>>> 
>>> Until we fix prepare-ChangeLog, and unless there is some great advantage to 
>>> this syntax that I'm not aware of… it's hold off on using it more.
>>> 
>>> Thanks,
>>> ~Brady
>>> ___
>>> 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

___
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

[Sam Weinig]

For some generic programming, this form can be dramatically shorter:

e.g. 

template
template
ALWAYS_INLINE auto HashMap::inlineAdd(K&& key, V&& value) -> AddResult
{
return m_impl.template add>(std::forward(key), std::forward(value));
}

vs.

template
template
ALWAYS_INLINE typename HashMap::AddResult HashMap::inlineAdd(K&& key, V&& value)
{
return m_impl.template add>(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.

- Sam

> On Jul 27, 2017, at 11:06 PM, Brady Eidson  wrote:
> 
> I just noticed this tonight. When a change is made to one of these functions, 
> prepare-ChangeLog doesn't log the functions that changed.
> 
> I have a question and a request.
> 
> Question:
> 
> The functions in question where I noticed this:
> auto WebURLSchemeTask::didComplete(const ResourceError& error) -> 
> ExceptionType
> 
> Would normally be written as:
> WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const 
> ResourceError& error)
> 
> Is there some actual value to using this syntax other than… being 
> syntactically different, and being just a little shorter?
> 
> Request:
> 
> Until we fix prepare-ChangeLog, and unless there is some great advantage to 
> this syntax that I'm not aware of… it's hold off on using it more.
> 
> 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] "ReflectOnly" IDL equivalent

[Sam Weinig]

> On Jun 10, 2017, at 3:41 PM, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> 
> On Jun 9, 2017, at 10:08 PM, Chris Dumez <cdu...@apple.com 
> <mailto:cdu...@apple.com>> wrote:
> 
>> 
>>> On Jun 9, 2017, at 11:47 AM, Sam Weinig <wei...@apple.com 
>>> <mailto:wei...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Jun 2, 2017, at 11:32 AM, Ryosuke Niwa <rn...@webkit.org 
>>>> <mailto:rn...@webkit.org>> wrote:
>>>> 
>>>> On Fri, Jun 2, 2017 at 9:18 AM, Chris Dumez <cdu...@apple.com 
>>>> <mailto:cdu...@apple.com>> 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-dir>
>> - https://html.spec.whatwg.org/#dom-link-as 
>> <https://html.spec.whatwg.org/#dom-link-as>
>> - https://html.spec.whatwg.org/#dom-link-referrerpolicy 
>> <https://html.spec.whatwg.org/#dom-link-referrerpolicy>
>> - https://html.spec.whatwg.org/#dom-link-updateviacache 
>> <https://html.spec.whatwg.org/#dom-link-updateviacache>
>> - https://html.spec.whatwg.org/#dom-a-referrerpolicy 
>> <https://html.spec.whatwg.org/#dom-a-referrerpolicy>
>> - https://html.spec.whatwg.org/#dom-img-referrerpolicy 
>> <https://html.spec.whatwg.org/#dom-img-referrerpolicy>
>> - https://html.spec.whatwg.org/#dom-iframe-referrerpolicy 
>> <https://html.spec.whatwg.org/#dom-iframe-referrerpolicy>
>> - https://html.spec.whatwg.org/#dom-track-kind 
>> <https://html.spec.whatwg.org/#dom-track-kind>
>> - https://html.spec.whatwg.org/#dom-media-preload 
>> <https://html.spec.whatwg.org/#dom-media-preload>
>> - https://html.spec.whatwg.org/#dom-area-referrerpolicy 
>> <https://html.spec.whatwg.org/#dom-area-referrerpolicy>
>> - https://html.spec.whatwg.org/#dom-th-scope 
>> <https://html.spec.whatwg.org/#dom-th-scope>
>> - https://html.spec.whatwg.org/#dom-form-autocomplete 
>> <https://html.spec.whatwg.org/#dom-form-autocomplete>
>> - https://html.spec.whatwg.org/#dom-input-type 
>> <https://html.spec.whatwg.org/#dom-input-type>
>> - https://html.spec.whatwg.org/#dom-input-inputmode 
>> <https://html.spec.whatwg.org/#dom-input-inputmode>
>> - https://html.spec.whatwg.org/#dom-button-type 
>> <https://html.spec.whatwg.org/#dom-button-type>
>> - https://html.spec.whatwg.org/#dom-textarea-inputmode 
>> <https://html.spec.whatwg.org/#dom-textarea-inputmode>
>> - https://html.spec.whatwg.org/#dom-fs-method 
>> <https://html.spec.whatwg.org/#dom-fs-method>
>> - https://html.spec.whatwg.org/#dom-fs-enctype 
>> <https://html.spec.whatwg.org/#dom-fs-enctype>
>> - https://html.spec.whatwg.org/#dom-fs-formenctype 
>> <https://html.spec.whatwg.org/#dom-fs-formenctype>
>> - https://html.spec.whatwg.org/#dom-fs-formmethod 
>> <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.
> 

That is quite an imposing list, I rescind my objection.

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

I’d prefer ReflectLimitedToKnownValues.

- Sam

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

Re: [webkit-dev] "ReflectOnly" IDL equivalent

[Sam Weinig]

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

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

Re: [webkit-dev] Another WPT bite

[Sam Weinig]

> On May 12, 2017, at 2:49 PM, Alexey Proskuryakov <a...@webkit.org> wrote:
> 
> 
>> 12 мая 2017 г., в 14:38, Sam Weinig <wei...@apple.com 
>> <mailto:wei...@apple.com>> написал(а):
>> 
>> 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).  
> 
> 
> That's still not good enough, as this means that I can't point someone else 
> to an instance of the test on trac.webkit.org <http://trac.webkit.org/> to 
> reproduce an issue. There is of course be another place to point to when/if 
> the test gets upstreamed, but even that doesn't support stable links like 
> trac does.
> 
> That's not to mention that learning the name of this proposed script is no 
> easier than learning about run-webkit-httpd.
> 
> - Alexey
> 


I’m not sure what you mean by “good enough”.  Good enough for what?  What are 
we debating here?  I was suggesting a mechanism to ease Simon’s specific 
problem, and I do think a script which both starts the server, and loads the 
correct URL would be helpful.  I often forget exactly what path to copy when 
writing http tests.

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

Re: [webkit-dev] Another WPT bite

[Sam Weinig]

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

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

- Sam



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

Re: [webkit-dev] Another WPT bite

[Sam Weinig]

> On May 8, 2017, at 9:31 PM, youenn fablet  wrote:
> 
> Hi all,
> 
> Discussing with some WebKittens, testharness.js is more and more used in 
> WebKit.
> Is it time to make testharness.js the recommended way of writing LayoutTests?

I am in favor of this. If we simplified the question to some form of, “do we 
really need both testharness.js/testharnessreport.js and 
js-test-pre.js/js-test-post.js?” I am even more in favor, as having two test 
harnesses seems unnecessary, cumbersome and unfriendly to new contributors,

Do I think all tests should use testharness.js? No. Just as currently I don’t 
think all tests should use testharness.js/testharnessreport.js. But for many 
tests of new web platform features, it seems quite reasonable to start using 
this harness, as the benefits, which include a good feature set, easier 
interoperability with other browsers, and a reduced cost to upstreaming to 
web-platform-tests, out weigh the costs, leaning something new (there are 
probably other costs I am forgetting).


> To continue moving forward, some of us are proposing to serve all tests in 
> LayoutTests/wpt through the WPT server [1].
> This would serve some purposes like increasing the use of WPT goodies: 
> file-specific headers, templated tests (*.any.js), IDLParser, server-side 
> scripts...
> It could also ease test migration from WebKit to W3C WPT.

This seems uncontroversial and great to me (which would make sense since I 
asked you if we could do it).  It’s just a new directory, like LayoutTests/http 
where we can put tests that use the WPT server.  

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

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Sam Weinig]

> On Feb 22, 2017, at 1:22 PM, Ryosuke Niwa  wrote:
> 
> On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers  > wrote:
> Chrome ships with a built-in extension that exposes the high-level API (which 
> I think we all agree is a hack).  We recently had this discussion 
> 
>  about the right path forward here, and agreed that we should instead focus 
> our efforts 
> 
>  on the Web Authentication API  instead, 
> since it seemed much more likely to be something that would become 
> interoperable between browsers.
> 
> Boris's comment in the referenced thread makes me think that we should just 
> implement https://w3c.github.io/webauthn/  
> if any:
> 
> 1) [Gecko/Firefox] have an implementation of the FIDO U2F API behind a pref 
> so people 
> can experiment with it. 
> 2) [Gecko/Firefox] plan to ship the API being developed at 
> https://w3c.github.io/webauthn/  once it 
> stabilizes. 
> > 3) [Gecko/Firefox] have no plans to ship the FIDO U2F API, now or in the 
> > future. 
> 
> As such, I don't think we should be implementing FIDO U2F API on trunk.
> 
> - R. Niwa
> 

Given that data, I agree with Ryosuke, and adding an implementing of the FIDO 
U2F API doesn’t seem like a great fit for WebKit.

That said, Jacob, do you have any interest in working on an implementation of 
the Web Authentication specification?

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

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Sam Weinig]

> On Feb 22, 2017, at 5:52 AM, Jacob Greenfield  wrote:
> 
> I’m working on adding support to WebKit for FIDO U2F (JS API: 
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html
>  Architecture overview: 
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html
>  ). The FIDO U2F specification allows a secure second factor to be used 
> during authentication flow, with bidirectional verification (token verifies 
> server, server verifies token and token’s knowledge of a specific private 
> key). There are current implementations in Chrome, Opera, and Blink 
> (Firefox). I’m primarily interested in bringing support to Safari, so that is 
> the focus what I am currently working on.

Hi Jacob, and welcome to WebKit.

I went looking for how to use the feature in Chrome and Firefox (I assume you 
meant Gecko (Firefox), not Blink (Firefox)) I’m a little confused as to how 
this feature is exposed in the other browsers.  On the topic of the low-level 
MessagePort API, section 3 states “This specification does not describe how 
such a port is made available to RP web pages, as this is (for now) 
implementation and browser dependent” 
(https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html#api-levels
 
).
  Similarly, for the high-level API, it states in section 3.2, “Implementations 
may choose how to make such an API available to RP web pages. If such an API is 
provided, it should provide a namespace object u2f of the following interface" 
(https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html#high-level-javascript-api
 
).

Do you have insight into how either of these APIs are exposed in other 
browsers? How do you plan on exposing them in WebKit?

I should say, generally, I am concerned with APIs that leave important details 
like how the APIs are exposed to the implementation, as they lead to 
non-interoperable implementations. 

Thanks,
- Sam

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

Re: [webkit-dev] Proposal: Adopt Web Inspector coding style for all WebKit JS/CSS source code

[Sam Weinig]



It should probably get a parallel page to 
https://webkit.org/code-style-guidelines/ and be updated with the same type of 
right / wrong examples.  

Our of curiosity, other than for features that simply aren’t available in C++ / 
Objective-C (or vice-versa), are there places where the inspector JS guideline 
deviates from what we do in the rest of WebKit?  

- Sam

> On Jul 7, 2016, at 11:29 AM, Geoffrey Garen  wrote:
> 
> 
> 
> To make this policy easy for new folks, I agree with Ryosuke that we should 
> extract a JS and CSS style guide that is separate from Inspector-specific 
> concerns.
> 
> Geoff
> 
>> On Jul 6, 2016, at 10:17 PM, Filip Pizlo  wrote:
>> 
>> I like the idea of adopting inspector style for JS builtins!
>> 
>> It might also be good to adopt it for JS tests that we write ourselves, with 
>> an escape hatch if you need to violate style to test some feature. For 
>> example, it should be a goal to follow inspector style for the JetStream 
>> harness code, and probably for all of ES6SampleBench. New JS tests in 
>> JavaScriptCore/tests/stress that we write ourselves probably should follow 
>> inspector style, because it's code that we have to read and understand and I 
>> can't think of a reason not to be consistent. Thoughts?
>> 
>> -Filip
>> 
>>> On Jul 6, 2016, at 7:53 PM, Ryosuke Niwa  wrote:
>>> 
 On Wed, Jul 6, 2016 at 7:34 PM, Dean Jackson  wrote:
 I propose we make it official that the Web Inspector Coding Style is what 
 must be used for all JavaScript and CSS that count as source code in the 
 project.
 https://trac.webkit.org/wiki/WebInspectorCodingStyleGuide
 
 Now that JavaScript is used in more places (JS builtins, some parts of the 
 DOM, media controls) it would be nice to make it all consistent. Note that 
 the page above can't decide if it is just JS or both JS and CSS, but I 
 think it should be both.
>>> 
>>> It's hard to tell which parts of the above guide would apply to
>>> non-Inspector JS code because it has a bunch of Inspector specific
>>> guidelines such as layering guides and references to
>>> https://trac.webkit.org/browser/trunk/Source/WebInspectorUI/UserInterface/Views/Variables.css
>>> 
>>> We should probably extract the parts that matter into a separate MD
>>> file or a section in the wiki page before we proceed with this
>>> discussion.
>>> 
>>> - R. Niwa
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Networking proxy on iOS

[Sam Weinig]

> On May 22, 2016, at 3:39 PM, Daniel Olegovich Lazarenko  
> wrote:
> 
> What if I make a bug report in bugzilla about making a design spec of this 
> feature. I could then write down implementation details options and summarize 
> all points we've discussed here. Maybe in a form of a google document. This 
> spec could then be reviewed and approved for action by you and any other 
> interested people you want to be involved. Do you think it could work better?

Before getting to the design of things, we usually spend quite a bit of time 
figuring out what the use cases are, and from the those use cases, what the 
different possible solutions are that address those use cases.  I don’t feel we 
have gotten past the use case part yet.

- Sam

> 
> On Sun, May 22, 2016 at 11:59 PM, Brady Eidson  > wrote:
> 
>> On May 22, 2016, at 3:14 AM, Daniel Olegovich Lazarenko > > wrote:
>> 
>> > It’s not yet clear what the ideal architecture is, which is one of the 
>> > reasons why the mentioned issued remains unresolved.
>> 
>> What are the other reasons?
> 
> Perhaps I misrepresented - AFAIK that is the only important reason.
> 
>> Are there any reasons that block us from discussing the right architecture?
>> I'd like to start working on a patch, but I need directions from you.
> 
> I replied to this thread to describe significant issues with the two 
> approaches you suggested.
> 
> But I am not able to conclude the thread by unilaterally giving directions to 
> a lone contributor on how to properly implement this feature.
> 
> That’s a much broader conversation than just you and I.
> 
> Thanks,
> ~Brady
> 
>> 
>> I'd like to come up with some sort of a plan for this as well. Since the 
>> desired approach sounds complicated, it would be nice to split it as a 
>> series of patches where each patch is committed separately and improves the 
>> feature towards the goal.
>> 
>> On Sun, May 22, 2016 at 6:16 AM, Brady Eidson > > wrote:
>> 
>>> On May 21, 2016, at 2:05 PM, Daniel Olegovich Lazarenko >> > wrote:
>>> 
>>> > We are exploring ways to restore that full functionality - 
>>> > https://bugs.webkit.org/show_bug.cgi?id=138169 
>>> > 
>>> 
>>> Having custom scheme protocols is important to me too. I didn't know that 
>>> it is broken with WKWebView. Do you know what exactly is broken?
>> 
>> From most developer’s perspective, what is broken is that their 
>> NSURLProtocol they can register in their “UI Process” that used to work in 
>> WK1 views no longer has any effect in WK2.
>> 
>>> 
>>> I thought that if you call [WKBrowsingContextController 
>>> registerSchemeForCustomProtocol:] with your scheme, then it works. When I 
>>> checked last (a year ago) it was implemented in a way that the 
>>> WebProcess/NetworkingProcess would pass a message to UIProcess, and handle 
>>> the network request in the UIProcess. Did it change?
>> 
>> That did not change.
>> 
>> But that mechanism was never API, and even as SPI it is formally deprecated.
>> 
>>> Assuming that registerSchemeForCustomProtocol still works the same way, you 
>>> basically state that you dislike the current solution (that does the work 
>>> in the UIProcess), and want to have a different architecture.
>>> 
>>> For custom networking or proxying you have to run the app-provided code. 
>>> The basic strategy I proposed was to run it in the app process (i.e. 
>>> UIProcess). Since you don't want any networking in UIProcess, it means that 
>>> the app needs to spawn a dedicated process to do custom networking. This 
>>> process would run app-specific code (including NSURLProtocol-s), and 
>>> communicate by IPC with the NetworkingProcess. Is this a kind of 
>>> architecture you would like to have?
>> 
>> It’s not yet clear what the ideal architecture is, which is one of the 
>> reasons why the mentioned issued remains unresolved.
>> 
>> Thanks,
>> ~Brady
>> 
>> 
>>> 
>>> 
>>> On Fri, May 20, 2016 at 5:58 PM, Brady Eidson >> > wrote:
>>> 
 On May 20, 2016, at 2:30 AM, Daniel Olegovich Lazarenko > wrote:
 
 Thank you for such a fast reply. That is amazing! :)
 Back to questions...
 
 > Are you primarily focused on a custom networking layer (e.g. your own 
 > HTTP implementation?),
 > or with custom protocol handling for non-http protocols?
 
 I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but 
 if there are any other widely used protocols that's also interesting. FTP 
 support is not interesting for me. Do you have any other specific things 
 in mind?
 
 If there's a custom proprietary protocol that people handle in the app 
 with 

Re: [webkit-dev] Which bugzilla component should be used for bmalloc?

[Sam Weinig]

I agree.  I added the bmalloc component. Let me know if there are any problems 
with it.

- Sam

> On Feb 23, 2016, at 11:36 AM, saam barati  wrote:
> 
> I also came across this when doing a bmalloc patch recently. I think it'd be 
> useful to have a bmalloc component.  
> 
> Saam
> 
>> On Feb 22, 2016, at 7:58 AM, Konstantin Tokarev  wrote:
>> 
>> Hello,
>> 
>> It seems like there is no appropriate bugzilla component for bmalloc. In my 
>> understanding, closest one is JavaScriptCore since it is mostly work on by 
>> the same folks who work on JSC, but technically they are very different 
>> components.
>> 
>> I think we need to create new component "Bmalloc" (or "FastMalloc" to 
>> abstract away of current implementation).
>> 
>> -- 
>> 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] Support registerProtocolHandler in WebKit2

[Sam Weinig]

(Sorry, had this sitting in my drafts).

My concern with the registerProtocolHandler() API is that it complicates an 
already the very complicated area of custom protocols and a good implementation 
requires configuration UI (to choose which of potentially multiple 
apps/websites you want a specific protocol to go to) that I am not sure users 
are in the position make.  

That, coupled with the small existing usage on the web and very few (if any) 
reports from developers that they want this, leads me to think it isn’t a good 
API for us to support.

From an implementation perspective I also have concerns.  How is this should 
the registration data be managed? Can it fit in the WebSiteData model we are 
using for other data? Does it account for non-persistent sessions?  And lastly, 
can we get the code size of supporting a feature like this to be smaller?   

- Sam

 On Jun 7, 2015, at 5:39 PM, Darin Adler da...@apple.com wrote:
 
 Are we making progress in this discussion?
 
 Maciej stated that he thinks this is useful for mailto and I think that 
 Gyuyoung Kim and Michael Catanzaro stated that they want to do this.
 
 As one next step in the discussion, is there anyone that wants to present a 
 use case for a protocol other than mailto?
 
 Sam, Anders, you haven’t replied to the thread since Maciej made his remarks 
 two weeks ago. He asked what you dislike about the API.
 
 — 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

Re: [webkit-dev] Content-DPR header

[Sam Weinig]

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

Hi Yoav,

Sorry, but I’m afraid I’m still not really getting it.  Can you get even more 
concrete?  Perhaps provide some a sample page that would need this kind of 
functionality and go through what Content-DPR values would be used?

- Sam

 If you don't have markup control, the same exercise applies, but would 
 require the full-fledged Client-Hints in order to actually deliver resized 
 images.
  
 
 On May 29, 2015, at 11:23 AM, Yoav Weiss y...@yoav.ws 
 mailto:y...@yoav.ws wrote:
 
 As a first step towards the Client-Hints implementation, I submitted a patch 
 https://bugs.webkit.org/show_bug.cgi?id=145380 for Content-DPR support 
 http://igrigorik.github.io/http-client-hints/#confirming-selected-dpr.
 A discussion followed on the thread, so I'd like to move it to the list, in 
 order for it to get higher exposure.
 
 Content-DPR is an HTTP response header that enables style-agnostic image 
 resizing,
 
 What exactly does style-agnostic image resizing” mean? I am not familiar 
 with that term 
 
 It's not an official term. I meant to say that it enables you to perform 
 image resizing without taking into account the style rules that control the 
 way in which the resized image will be displayed.
 
 
 by enabling the server to adapt the image's intrinsic size so that layout 
 will not break, even if the image's dimensions are not defined in style.
 
 Opinions welcome! :)
 ___
 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] Content-DPR header

[Sam Weinig]

Hi Yoav,

Can you give a concrete example of when this will be used?  I’m having trouble 
understanding when an author will want to change an images intrinsic size but 
not have control of the markup.

 On May 29, 2015, at 11:23 AM, Yoav Weiss y...@yoav.ws wrote:
 
 As a first step towards the Client-Hints implementation, I submitted a patch 
 https://bugs.webkit.org/show_bug.cgi?id=145380 for Content-DPR support 
 http://igrigorik.github.io/http-client-hints/#confirming-selected-dpr.
 A discussion followed on the thread, so I'd like to move it to the list, in 
 order for it to get higher exposure.
 
 Content-DPR is an HTTP response header that enables style-agnostic image 
 resizing,

What exactly does style-agnostic image resizing” mean? I am not familiar with 
that term 

 by enabling the server to adapt the image's intrinsic size so that layout 
 will not break, even if the image's dimensions are not defined in style.
 
 Opinions welcome! :)
 ___
 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] Picking a text autosizing implementation

[Sam Weinig]

Hi,

WebKit currently has two text autosizing implementations, each behind its own 
ENABLE macro, the IOS_TEXT_AUTOSIZING implementation used on iOS and the 
TEXT_AUTOSIZING implementation.  I would like to bring that number down to one, 
and compile it everywhere so we can test it on all platforms (we would still 
probably want to disable it at runtime for most platforms).

Is anyone using the TEXT_AUTOSIZING implementation?  If so, would you be 
against switching to the IOS_TEXT_AUTOSIZING implementation?

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

[webkit-dev] Removing support for Shared Workers

[Sam Weinig]

Hello,

I’d like to remove support for Shared Workers. 

We have not shipped support for Shared Workers in Safari for two releases and 
have not seen any significant complaints.  The code as it currently stands is 
not a good fit for the WebKit2 architecture, so, if we ever decided Shared 
Workers were important, we would probably start over.

Does anyone object?

- Sam

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

Re: [webkit-dev] Removing webkit prefix from CSS Shapes properties?

[Sam Weinig]

Hi Bem,

Can you give us an overview of what other browsers have shipped CSS Shapes and 
how interoperable they are (e.g are they all passing a shared test suite)?

-Sam

 On Oct 27, 2014, at 11:42 AM, Bem Jones-Bey bjone...@adobe.com wrote:
 
 Hey all,
 
 Chrome shipped CSS Shapes un-prefixed. The spec has been in CR for awhile 
 now, with no changes in behavior. I keep on coming across content that uses 
 CSS Shapes but doesn't use the prefixed version, so it doesn't work in 
 Safari. Any objections to enabling un-prefixxed versions of CSS Shapes 
 properties in WebKit?
 
 - Bem
 ___
 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] Type checking / casting helpers

[Sam Weinig]

This all looks wonderful!

One question though, why downcast(…)? Will we be adding an upcast() 
function? Since the answer is probably no, could we just call this cast(…)?

- Sam

 On Sep 25, 2014, at 11:11 AM, Chris Dumez cdu...@apple.com wrote:
 
 Hi all,
 
 I started working on automatically generating the type casting helpers for 
 HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until now, we were 
 generating only the type checking helpers using make_names.pl (e.g. 
 isHTMLDivElement()). The type casting helpers had to be manually defined 
 using NODE_TYPE_CASTS() macro.
 
 The type casting helpers are now automatically generated for most types. Part 
 of the solution involved using a templated function for type casting because 
 the types are forward-declared and we needed to do a static_cast() (a 
 reinterpret_cast() could be used with forward declarations but wouldn’t be 
 safe due to multiple inheritance).
 
 I initially had macros in place so that toHTMLDivElement() would still work 
 and would be equivalent to downcastHTMLDivElement(). The feedback I 
 received is that we should get rid of these macros and just use 
 isHTMLDivElement() / downcastHTMLDivElement() everywhere.
 The new style is very close to C++’s is_classT() and Boost’s 
 polymorphic_downcastT().
 
 I actually started updating the code to do this but I should have emailed 
 webkit-dev about this beforehand. I apologize for sending this message a bit 
 late.
 
 Please let me know if you have feedback / concerns / questions about this 
 change. I hope that this email gives you a better understanding of why I am 
 making this change.
 
 As I said before, the code base is not fully ported yet so the current 
 situation is not necessarily pretty. I will try and go through the transition 
 as fast as I can, provided that people don’t raise any concerns about this.
 
 Please also note that these new helpers still catch unnecessary type checks / 
 casts. As a matter of fact, those are now caught at build time instead of 
 linking time and should give you a nice “Unnecessary type check” / 
 “Unnecessary type cast” static assertion.
 
 Also note that the plan is to get rid of TYPE_CAST_BASE() macro entirely and 
 extend is() / downcast() to all types, not just Nodes.
 
 Kr,
 --
 Chris Dumez - Apple Inc.
 Cupertino, CA
 
 
 
 
 ___
 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] Type checking / casting helpers

[Sam Weinig]

That also sounds like reasonable behavior for something called cast() to me. 

Sent from my iPhone

 On Oct 2, 2014, at 5:01 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 downcast fails if you do a useless cast/upcast.
 
 Benjamin
 
 On 10/2/14, 4:47 PM, Sam Weinig wrote:
 This all looks wonderful!
 
 One question though, why downcast(…)? Will we be adding an upcast()
 function? Since the answer is probably no, could we just call this
 cast(…)?
 
 - Sam
 
 On Sep 25, 2014, at 11:11 AM, Chris Dumez cdu...@apple.com
 mailto:cdu...@apple.com wrote:
 
 Hi all,
 
 I started working on automatically generating the type *casting*
 helpers for HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until
 now, we were generating only the type *checking* helpers using
 make_names.pl (e.g. isHTMLDivElement()). The type *casting* helpers
 had to be manually defined using NODE_TYPE_CASTS() macro.
 
 The type casting helpers are now automatically generated for most
 types. Part of the solution involved using a templated function for
 type casting because the types are forward-declared and we needed to
 do a static_cast() (a reinterpret_cast() could be used with
 forward declarations but wouldn’t be safe due to multiple inheritance).
 
 I initially had macros in place so that toHTMLDivElement() would still
 work and would be equivalent to downcastHTMLDivElement(). The
 feedback I received is that we should get rid of these macros and just
 use isHTMLDivElement() / downcastHTMLDivElement() everywhere.
 The new style is very close to C++’s is_classT() and Boost’s
 polymorphic_downcastT().
 
 I actually started updating the code to do this but I should have
 emailed webkit-dev about this beforehand. I apologize for sending this
 message a bit late.
 
 Please let me know if you have feedback / concerns / questions about
 this change. I hope that this email gives you a better understanding
 of why I am making this change.
 
 As I said before, the code base is not fully ported yet so the current
 situation is not necessarily pretty. I will try and go through the
 transition as fast as I can, provided that people don’t raise any
 concerns about this.
 
 Please also note that these new helpers still catch unnecessary type
 checks / casts. As a matter of fact, those are now caught at build
 time instead of linking time and should give you a nice “Unnecessary
 type check” / “Unnecessary type cast” static assertion.
 
 Also note that the plan is to get rid of TYPE_CAST_BASE() macro
 entirely and extend is() / downcast() to all types, not just Nodes.
 
 Kr,
 --
 Chris Dumez - Apple Inc.
 Cupertino, CA
 
 
 
 
 ___
 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

Re: [webkit-dev] Swift in WebKit

[Sam Weinig]

Hi David,

I think it is a bit too early to start using Swift in WebKit, especially since 
the language is still evolving.  Eventually, I think we should start using it, 
but I’d like for it to settle a bit before we do.

- Sam


On Jul 28, 2014, at 12:47 PM, David Farler dfar...@apple.com wrote:

 Hello all,
 
 I have the following bug to help build out support for layout tests in the 
 iOS Simulator.
 
 iOS Simulator LayoutTestRelay
 https://bugs.webkit.org/show_bug.cgi?id=135269
 
 I'd like to include this as a new tool written in Swift.
 
 Why I think it's fine in this case:
 - This tool is specific to the iOS and OS X platforms
 - Swift is a fully supported, albeit new, language starting in Xcode 6.
 - Swift is probably the best way to get Objective-C bridging for free in 
 the long term
 - Swift supports script-like immediate mode with good JIT-compiled 
 performance
 - The tool's size and scope is sufficiently small with no complex or 
 WebKit-specific dependencies
 
 I understand that its freshness and continual evolution means that we won't 
 reviewer support relative to our C family languages. I would argue that it 
 will be difficult to subjectively tell when the time is right, that a good 
 way to solve that is to start using the language itself, and take an 
 incremental approach to crafting the Swift story in WebKit. Using it for some 
 simple tools is a good place to start.
 
 The larger discussion of using Swift in larger AOT-compiled contexts but is 
 probably going to happen in this thread anyway, so let's have it:
 
 What of future use of Swift in WebKit?
 
 Regards,
 David Farler
 ___
 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] Swift in WebKit

[Sam Weinig]

On Jul 28, 2014, at 4:38 PM, Geoffrey Garen gga...@apple.com wrote:

 (2) The language and implementation are still changing in breaking ways.
 
 Yep, I concede to this. My only question in response is whether it's 
 valuable to observe those changes in a project like this or even to use a 
 project like this to investigate other points of discussion, like:
 
 - Is there one Swift coding style? If not, what's ours?
 - What do we need to implement in spite of, or for lack of, a standard 
 library feature?
 
 Or, just save all that for a rainy day, I suppose.
 
 Interesting. I think it might be valuable to do these things in a limited 
 project, if we can minimize the downside of breaking changes.
 
 Geoff

I’d also be okay with allowing Swift, in this limited fashion, as an experiment.

- Sam

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

[webkit-dev] Is anyone using the LevelDB backend to IndexedDB?

[Sam Weinig]

Hello,

Is anyone using the LevelDB backend to IndexedDB?

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

[webkit-dev] WebKit Contributors Meeting 2014 - UPDATED DATES

[Sam Weinig]

Hi all,

I’m really sorry abut this, but we have to move the WebKit Contributors Meeting 
by one day. We previously told you that the meeting will be Monday, April 14th 
and Tuesday, April 15th but instead it will be Tuesday, April 15th and 
Wednesday, April 16th. 

So just to be clear: the new dates for the meeting are Tuesday, April 15th and 
Wednesday, April 16th.

I apologize for any inconvenience.

- Sam

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

[webkit-dev] Registration is now open for the 2014 WebKit Contributors Meeting!

[Sam Weinig]

Hi all,

Registration is now open for the 2014 WebKit Contributors Meeting. Sign up at 
http://www.webkit.org/meeting/!

- Sam

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

[webkit-dev] WebKit Contributors Meeting 2014 - Save the Date

[Sam Weinig]

Hi all,

Apple will once again be hosting a WebKit Contributors Meeting. This year, it 
will be held on Apple’s Infinite Loop campus in Cupertino on Monday, April 14th 
and Tuesday, April 15th. As with the meeting in previous years, this event will 
have an unconference-like format, allowing plenty of time for impromptu 
sessions/discussions and hacking.

We will open registration next week. The meeting will be free of charge. All 
WebKit contributors are encouraged to attend.

We hope to see you there!

Thanks,
Sam

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

[webkit-dev] Proposal: Remove ENABLE(SVG)

[Sam Weinig]

Hi Everyone,

While we are discussing removing #ifdefs that everyone has enabled, I’d like to 
propose removing ENABLE(SVG), as every port has SVG enabled.  The only argument 
I have heard for keeping it around is to keep a “minimal build” working, but I 
don’t think the clutter of the #ifdefs is worth that.

-Sam

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

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

[Sam Weinig]

On Jan 28, 2014, at 4:20 PM, Thomas Fletcher tho...@cranksoftware.com wrote:

 Not a true statement if you consider out of tree ports.

In general, we do not take in consideration ports that don’t contribute back or 
live in tree.

 None of the ports we have done at Crank have used or needed svg support and 
 as embedded systems, they all benefit from the smaller footprint.

Since you live out of tree, you probably need to do a bit of merging anyway, so 
you will be free to add back the #ifdefs.

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

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

[Sam Weinig]

On Jan 28, 2014, at 4:51 PM, Philip Rogers p...@google.com wrote:

 This will make hacking on WebKit much easier. For better or worse, SVG is 
 tightly coupled with the rest of rendering/. We recently measured SVG usage 
 on the web and found 10% of all pageviews contain SVG.

Interesting stat! Thanks.

 
 Do you plan to remove ENABLE(SVG_FONTS) as well?

Not at this point.

-Sam

 
 
 On Tue, Jan 28, 2014 at 4:34 PM, Andreas Kling akl...@apple.com wrote:
 This sounds good to me.
 
 A WebKit without SVG support is scarcely a WebKit at all.
 
 On Jan 28, 2014, at 4:13 PM, Sam Weinig wei...@apple.com wrote:
 
  Hi Everyone,
 
  While we are discussing removing #ifdefs that everyone has enabled, I’d 
  like to propose removing ENABLE(SVG), as every port has SVG enabled.  The 
  only argument I have heard for keeping it around is to keep a “minimal 
  build” working, but I don’t think the clutter of the #ifdefs is worth that.
 
  -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
 

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

[webkit-dev] Proposal: Stop EWS bot commenting in bugs

[Sam Weinig]

Hi Everyone,

I am becoming increasingly annoyed by the comments made in bugs.webkit.org bugs 
by our non-human helpers, the EWS bots.  I don’t find the addition of a comment 
indicating that a patch has failed on a bot, over the existing indication in 
the bubble, to be worth the noise it creates.

I propose that we stop allowing the bots to comment, and leave that space for 
the developers.

- Sam

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

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

[Sam Weinig]

Could we compromise for now, and remove all the non-test failing EWS comments 
(e.g. build failure, style failure)?

- Sam

On Jan 15, 2014, at 8:04 PM, Ryosuke Niwa rn...@webkit.org wrote:

 I find Mac EWS's listing the failing tests to be very useful especially 
 because it uploads the results to Bugzilla.
 
 I do agree that comments about build failures are much less useful.
 
 - R. Niwa
 
 
 On Wed, Jan 15, 2014 at 7:54 PM, Sam Weinig wei...@apple.com wrote:
 Hi Everyone,
 
 I am becoming increasingly annoyed by the comments made in bugs.webkit.org 
 bugs by our non-human helpers, the EWS bots.  I don’t find the addition of a 
 comment indicating that a patch has failed on a bot, over the existing 
 indication in the bubble, to be worth the noise it creates.
 
 I propose that we stop allowing the bots to comment, and leave that space for 
 the developers.
 
 - 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] Status of the Blackberry port

[Sam Weinig]

I’ll take from the silence that there are no parties interested in maintaining 
the port. I have filed https://webkit.org/b/126715 to track removing it from 
trunk.

Thanks,
-Sam
  
On Jan 4, 2014, at 11:21 AM, Sam Weinig wei...@apple.com wrote:

 There hasn’t been a response to this question in many months and as far as I 
 can tell, no additional activity in the BlackBerry port.  Is anyone from 
 BlackBerry still interested in maintaining the port? If not, I think we 
 should remove it from the tree.
 
 - Sam
 
 On Oct 13, 2013, at 12:01 PM, Anders Carlsson ander...@apple.com wrote:
 
 Hi Eli,
 
 I’m not sure what “still being maintained” means.
 
 Looking in WebKit/blackberry, I see 9 changes from BlackBerry people since 
 July and 24 changes from non-BlackBerry people. I’m also not sure that 
 what’s in the WebKit repository even builds (which makes it really 
 frustrating to make changes that touch BlackBerry code).
 
 Looking forward to an update,
 - Anders
 
 On Oct 7, 2013, at 7:04 AM, Eli Fidler efid...@blackberry.com wrote:
 
 Yes, it's still being maintained by the folks here at BlackBerry.
 
 Eli
 
 
 
 On 13-10-05 7:12 PM, Sam Weinig wei...@apple.com wrote:
 
 Hello,
 
 Can anyone comment on the status of the Blackberry port?  Is it still
 being maintained?
 
 -Sam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received this transmission in error, 
 please immediately reply to the sender and delete this information from 
 your system. Use, dissemination, distribution, or reproduction of this 
 transmission by unintended recipients is not authorized and may be unlawful.
 
 ___
 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] Heads-up: ENABLE_GESTURE_EVENTS removal

[Sam Weinig]

Sounds good.

-Sam

On Oct 10, 2013, at 3:18 PM, Anders Carlsson ander...@apple.com wrote:

 Hello,
 
 I’m planning to remove the ENABLE_GESTURE_EVENTS ifdef and related code. It 
 was used by Chromium (and perhaps to some extent Qt) as well as WebKit2 for 
 trackpad events before we switched over to wheel events (which is the 
 recommended way to do things). From what I can see all the code in both 
 WebKit2 and WebCore is dead.
 
 - Anders
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Status of the Blackberry port

[Sam Weinig]

Hello,

Can anyone comment on the status of the Blackberry port?  Is it still being 
maintained?

-Sam

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

Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag

[Sam Weinig]

Or better yet, enable it for all ports on ToT.

-Sam

On Oct 4, 2013, at 11:03 AM, Timothy Hatcher timo...@apple.com wrote:

 Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it?
 
 I have a legitimate use for -webkit-text-decoration-color that would allow me 
 to eliminate a hack in the Inspector.
 
 — Timothy Hatcher
 
 
 On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 Hello, all!
 
 Between the current and previous versions of the CSS3 Text spec, the text 
 decoration section was split out into its own spec [1] [2] [3]. Because of 
 this shift, I’m going to be creating a new compile-time flag: 
 CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in 
 [4]. For those who wish to follow progress, the feature bug is at [5]. The 
 first thing I am working on is the text-decoration-skip: ink property [6]. I 
 will also be migrating existing text-decorations code from behind the 
 existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag.
 
 Thanks,
 Myles C. Maxfield
 
 [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/
 [2] http://www.w3.org/TR/css3-text/
 [3] http://www.w3.org/TR/css-text-decor-3/
 [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html
 [5] https://bugs.webkit.org/show_bug.cgi?id=58491
 [6] https://bugs.webkit.org/show_bug.cgi?id=121806
 ___
 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] Type cast by using toFoo()

[Sam Weinig]

On Sep 30, 2013, at 3:39 AM, Gyuyoung Kim gyuyoung@webkit.org wrote:

 Hello WebKittens,
 
 I have focused on using toFoo() for SVG and CSS instead of using 
 static_cast.  Because I think there are some advantages when we use it.
 
   - Bad type cast can be detected by using ASSERTION in toFoo(). The toFoo() 
 function has an ASSERTION to check if source value is a proper super class.
   - Unnecessary local variables can be removed. There are some local 
 variables, which are only used once in WebKit. In those cases, we don’t need 
 to use a local variable. Besides, we can remove unnecessary ASSERTION because 
 toFoo() already has it.
   - I believe toFoo() can improve code readability.
 
 Currently, HTML, SVG Elements support toHTML|SVGFooElement() and CSSValue 
 also starts to support toCSSFooValue(). Please check if there is toFoo() when 
 you need to use static_cast in HTML, SVG and CSS module.

Nice.

 
 Finally I plan to add this toFoo() policy to the WebKit style checker.

Can you explain more about this?  How are you going to determine static_casts 
that are acceptable from ones that aren’t.

-Sam

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

Re: [webkit-dev] Proposal: Remove DOMFileSystem support

[Sam Weinig]

Antonio Gomes noted to me that Ryosuke asked the same question around a month 
ago and got no objections 
(https://lists.webkit.org/pipermail/webkit-dev/2013-August/025351.html), so I 
am going to move forward and remove it.

Thanks,
-Sam

On Sep 29, 2013, at 9:24 PM, Sam Weinig wei...@apple.com wrote:

 WebKit,
 
 I’d like to remove WebKit’s support for the DOMFileSystem API (which is under 
 the ENABLE(FILE_SYSTEM) #define) due to it being un-maintained and not 
 enabled in any mainline port.  DOMFileSystem is not supported by any major 
 browser except Chrome, and I expect WebKit’s future support in this area will 
 revolve around Mozilla’s proposal 
 (http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0071.html).
 
 Thoughts?
 
 -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

[webkit-dev] Proposal: Remove DOMFileSystem support

[Sam Weinig]

WebKit,

I’d like to remove WebKit’s support for the DOMFileSystem API (which is under 
the ENABLE(FILE_SYSTEM) #define) due to it being un-maintained and not enabled 
in any mainline port.  DOMFileSystem is not supported by any major browser 
except Chrome, and I expect WebKit’s future support in this area will revolve 
around Mozilla’s proposal 
(http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0071.html).

Thoughts?

-Sam

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

Re: [webkit-dev] Changes in QtWebKit development

[Sam Weinig]

Allan,

Andreas and Benjamin make good points, care to respond?  (Being an active 
member of this community means responding on this mailing list). 

-Sam

On Sep 14, 2013, at 3:24 AM, Allan Sandfeld Jensen k...@carewolf.com wrote:

 On Friday 13 September 2013, Benjamin Poulain wrote:
 
 This is sad.
 
 Yes :(
 
 
 When modules of Qt are put on maintenance, it is basically a synonym
 to it's unmaintained, just let it die. I am very unexcited about
 having one of those in the tree along the live development from everyone
 else.
 It is unfair for all the ports who put real efforts in the WebKit
 opensource project.
 
 Previously modules put in maintenance in Qt were already dead because we had 
 lost the developers during business transitions. This is different, QtWebKit 
 is still being actively developed and we still have the developers, even if 
 the primary focus has changed.
 
 Realistically, how much development will go in QtWebKit/Linux? Why does
 it stay in WebKit trunk if the two other ports are maintained in a
 branch?
 
 Staying in trunk is the best way to still be part of the development of 
 WebKit, and WebKit is still our main web api, and will remain so in the next 
 release of Qt. As long as we ship WebKit as a major part of Qt, we also want 
 to be active in project and contribute back, even if we are forced to scale 
 back our commitment.
 
 We are keeping QtWebKit/Linux in particular because it is the easiest to 
 maintain and requires the least amount of Qt specific code (most is shared 
 with GTK, EFL and Nix) and QtWebKit/Linux has use cases beyond just being 
 part 
 of the official QtWebKit releases. WebKit has a number of advantages over 
 Chromium especially on embedded linux, using less memory, having better JIT 
 support of smaller architectures (MIPS, old ARM, etc), more customizable 
 feature set, and a more powerful API on the WebKit1 side that is not easily 
 duplicated in a multiprocess design. Those use cases are all outside the 
 stock 
 QtWebKit releases though.
 
 That said, in all likelihood the Qt port will not remain part of WebKit 
 forever, but leaving will not be Digia's decision alone to make. For now I 
 will continue working full time on WebKit, my coworkers are still bug-fixing 
 in WebKit whenever necessary, there are still several developers from 
 Cisco(NDS) using the Qt port of webkit, and we still have a handful of 
 developers from the university of Szeged working on the port as well. So some 
 5-10 developers, though the majority are not Digia employees any more.
 
 Best regards
 `Allan Jensen
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Proposed feature: Network Service Discovery

[Sam Weinig]

I don’t think this belongs in WebKit, as this doesn’t seem like it would ever 
be appropriate to expose to the Web at large.  I recommend trying to find a way 
to layer this on top of WebKit if it is something you need to support.

-Sam

On Aug 29, 2013, at 4:19 PM, Brendan Long b.l...@cablelabs.com wrote:

 We would like to implement the Network Service Discovery spec in WebKIt. 
 There's an existing bug (with a basic patch to show the API) in the bug 
 tracker.
 
 This is useful to allow media applications to discover network media sources, 
 players or DLNA remote UI's (and presumably plenty of other things).
 
 I was planning to start by implementing SSDP, using GSSDP, targetting 
 QtWebKit (and probably WebKitGTK and WebKit-EFL as a side-effect). The API 
 itself is pretty simple, but I'll probably need some help fitting it into 
 WebKit.
 
 Does anyone have any opinions about this?
 ___
 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] Implementing object-fit

[Sam Weinig]

Sounds fine to me.

-Sam

On Aug 26, 2013, at 4:23 PM, Simon Fraser simon.fra...@apple.com wrote:

 Support for CSS object-fit has landed in Blink (runtime-enabled)[1] and I’d 
 like to land it in WebKit[2].
 
 The spec[3] is at CR, so I’d like to land this unprefixed, and not protected 
 by ENABLE guards. Does anyone see fit to object?
 
 Simon
 
 [1] http://src.chromium.org/viewvc/blink?view=revisionrevision=156535
 [2] https://bugs.webkit.org/show_bug.cgi?id=52040
 [3] http://www.w3.org/TR/css3-images/
 ___
 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] Proposal: Add support for Promises

[Sam Weinig]

Hey WebKittens,

I’d like to add support for Promises.  Promises are currently specified in the 
DOM Living Standard (http://dom.spec.whatwg.org/#promises) but will probably be 
moved to an ECMAScript standard at some point in the future.  As such, I plan 
to implement them in JavaScriptCore.

The main motivation for adding Promises is that many upcoming specs have them 
as a dependency, including WebCrypto 
(https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html), the 
updated FileSystem API 
(http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0071.html) and 
others.

Thoughts?

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

[webkit-dev] Proposal: Remove Microdata support

[Sam Weinig]

Hello,

I’d like to propose removing support for the Microdata JS API 
(http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html) 
from WebKit.  The specification has not gotten much adoption from either 
implementors or from site authors.  Additionally, its use cases can all be 
addressed in author scripts, and if we see it becoming popular we can always 
bring it back.

The Mac port has never enabled the feature, and Blink has recently ripped out 
their support. 

Thoughts?

-Sam

(I have done the work to rip it out, but it is not up for review yet - 
https://webkit.org/b/119480)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving WebCore/accessibility code into WebCore/platform/

[Sam Weinig]

On May 21, 2013, at 8:15 AM, Darin Adler da...@apple.com wrote:

 
 Of course, we could always add an exception to the style checker
 
 The style checker rule is wrong and should be removed. It’s better to use a 
 platform abstraction, but a platform #ifdef is also OK.

This was something we discussed during the contributors meeting.  The premise 
was that we should aim for having no PLATFORM() #ifdefs in non-Platform and and 
should instead use other macros that are more descriptive.  I like that rule, 
but if isn't really possible, we should probably remove the check.

Accessibility is a tricky one. The way it is currently written requires both 
cross platform and platform specific knowledge to co-exist.  Looking at the 
base class, AccessibilityObject, it seems like there is a WebCore object 
(AccessibilityObject) that wraps a platform specific piece (m_wrapper, which on 
mac is a WebAccessibilityObjectWrapper and on GTK is a AtkObject, etc.).  The 
way I would recommend moving forward is seeing if there is some way to abstract 
the platform specific piece in a C++ object that could live in platform (much 
like we do in other areas), and make all the WebCore code work in terms of it.

-Sam

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

Re: [webkit-dev] Moving WebCore/accessibility code into WebCore/platform/

[Sam Weinig]

On May 21, 2013, at 10:56 AM, Darin Adler da...@apple.com wrote:

 On May 21, 2013, at 10:42 AM, Sam Weinig wei...@apple.com wrote:
 
 On May 21, 2013, at 8:15 AM, Darin Adler da...@apple.com wrote:
 
 Of course, we could always add an exception to the style checker
 
 The style checker rule is wrong and should be removed. It’s better to use a 
 platform abstraction, but a platform #ifdef is also OK.
 
 This was something we discussed during the contributors meeting.  The 
 premise was that we should aim for having no PLATFORM() #ifdefs in 
 non-Platform and and should instead use other macros that are more 
 descriptive.  I like that rule, but if isn't really possible, we should 
 probably remove the check.
 
 It’s an interesting principle, but I think too far from reality right now.
 
 And it leads to crazy things like the Clipboard in the dom directory with 
 per-platform subclasses in the platform directory.
 
 — Darin

Fair enough. I'll talk to Jessie about removing it, and maybe we can revisit it 
in the future.

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

Re: [webkit-dev] C++11 (was Re: on coding-style)

[Sam Weinig]

On Apr 13, 2013, at 1:55 AM, Carlos Garcia Campos carlo...@webkit.org wrote:

 
 El vie, 12-04-2013 a las 18:15 -0700, Maciej Stachowiak escribió:
 On Apr 12, 2013, at 4:09 PM, Karen Shaeffer shaef...@neuralscape.com wrote:
 
 
 Of course, I understand that. But there is a huge opportunity cost to 
 webkit.
 The c++11 standard also rewrites the entire standard library. I have been 
 using
 g++ 4.7.2 using -stdc++11 in my work with linux. And the code I have tested 
 is
 performing nearly like c code. If you take advantage of the performance 
 enhancements
 in C++11, then you can realize impressive performance gains.
 
 I do understand the nature of the business. And I also understand that 
 performance
 is huge moving forward, where resource constrained mobile platforms are 
 significantly
 affected by performance issues. I suggest you'll see Blink moving 
 aggressively to
 support C++11 moving forward. And I suggest it is in WebKit's long term 
 interest to
 do so as well.
 
 As others have said, we are definitely eager to use C++11 across the board 
 but are limited by compiler support requirements.
 
 One thing that it would be useful to know: what are the compilers and 
 minimum required versions used for in-tree ports? Perhaps we could record 
 this so we can regularly evaluate which features are safe to use and what 
 the blockers are to wholesale adoption, if any.
 
 The GTK+ port now requires gcc = 4.7 and clang = 3. We also added the
 -stdc++11 where possible. See
 https://bugs.webkit.org/show_bug.cgi?id=109932

That's awesome!  

-Sam

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

[webkit-dev] You can now register for the 2013 WebKit Contributors Meeting

[Sam Weinig]

Registration is now open for the 2013 WebKit Contributors Meeting.  You can 
register by going to https://www.webkit.org/meeting/.

Hope to see you all there!

-Sam

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

[webkit-dev] WebKit Contributors Meeting - Save the Date

[Sam Weinig]

Hi all,

Apple will once again be hosting a WebKit Contributors Meeting. It will be held 
at the DoubleTree by Hilton Hotel in San Jose on Thursday, May 2nd and Friday, 
May 3rd. As with the meeting in previous years, this event will have an 
unconference-like format, allowing plenty of time for impromptu 
sessions/discussions and hacking.

We will open registration in the coming weeks. The meeting will be free of 
charge. All WebKit contributors are encouraged to attend.

We hope to see you there!

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

Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code

[Sam Weinig]

Sounds good to me as well.

-Sam

On Jan 30, 2013, at 3:54 PM, Nico Weber tha...@chromium.org wrote:

 Hi,
 
 I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know,
 nobody ever shipped this and nobody intents to. Please speak up if
 you'd like that code to stick around.
 
 Nico
 ___
 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] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient

[Sam Weinig]

Hi Mario,

The motivation of the change was to reduce the chatter between the WebProcess 
and UIProcess and reduce the amount of knowledge the UIProcess has about the 
internals of the WebProcess.  We will also be removing the UIProcess' notion of 
the frame tree, for the same reason.

Going forward, if you need that kind of detailed knowledge, you should use the 
WebInspector or the protocol it is based on.

-Sam

On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada mario.pr...@samsung.com 
wrote:

 Hi,
  
 So it seems WebKit2GTK+ builds are broken since yesterday due to this commit 
 (as it was already predicted by EWS in [1]):
 http://trac.webkit.org/changeset/140285
  
 ... and it seems to me it’s not something easily fixable since it will 
 certainly require a certain amount of work (and maybe a certain amount of 
 re-design too) to get it back, as the WebKitWebResource API (as well as 
 certain parts in WebKitWebView API) did benefit of both WKResourceLoadClient 
 and WebResourceLoadClient.
  
 I’ve checked the related bug [1], but still haven’t been able to properly 
 understand what’s exactly the reason of this change and, more importantly, 
 what could be the best way to sort this out in the GTK port (an alternative 
 implementation using the Injected Bundle perhaps?).
  
 If anyone could drop some light on this issue or provide some pointers to 
 better understand the motivation of this change, I’d really appreciate that. 
 I understand rolling r140285 might be not the best option at this point, yet 
 I’d personally rather not keep the WebKit2GTK+ broken for too long.
  
 Thanks,
 Mario
  
 [1] https://bugs.webkit.org/show_bug.cgi?id=107405
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Constructors for DOM4 Events

[Sam Weinig]

Seems fine to me.

-Sam

On Jan 10, 2013, at 6:36 AM, Kentaro Hara hara...@chromium.org wrote:

 At TPAC there was no objection for DOM4 Event constructors (e.g. new
 MouseEvent()).
 
 Now DOM4 Event constructors are on editor's draft:
 http://html5labs.interoperabilitybridges.com/dom4events/
 https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm
 
 Given the above, I am planning to implement them in WebKit (without
 any flag). If you have any concern, please let me know.
 
 Best Regards
 
 
 On Mon, Oct 1, 2012 at 7:44 AM, Kentaro Hara hara...@chromium.org wrote:
 Since TPAC is less than a month away, I don't understand why we can't wait 
 for that discussion.
 
 Sounds reasonable. I'll wait for TPAC.
 
 I do support the idea in general, and I plan to be at TPAC and will 
 advocate for it.
 
 I'll be also going to TPAC. I would appreciate your support.
 
 
 
 On Mon, Oct 1, 2012 at 2:11 PM, Maciej Stachowiak m...@apple.com wrote:
 
 Since TPAC is less than a month away, I don't understand why we can't wait 
 for that discussion. I do support the idea in general, and I plan to be at 
 TPAC and will advocate for it.
 
 I understand that sometimes we need to move ahead of the spec. If there's a 
 reason not to wait a few extra weeks in this case, then please at least use 
 a prefix.
 
 Cheers,
 Maciej
 
 On Sep 30, 2012, at 6:32 PM, Kentaro Hara hara...@chromium.org wrote:
 
 TL;DR: Would it be OK to implement constructors for DOM4 Events in
 WebKit without waiting for the spec?
 
 
 == Background ==
 
 Events should have constructors. 'new XXXEvent()' is much easier than
 'e = document.createEvent(...); e.initXXXEvent(_a_lot_of_arguments_)'.
 We have already implemented constructors for a bunch of Events such as
 Event, CustomEvent, ProgressEvent, etc [5]. However, we have not yet
 implemented constructors for DOM4 Events (i.e. UIEvent, MouseEvent,
 KeyboardEvent, WheelEvent, TextEvent, CompositionEvent) because they
 are not yet speced.
 
 Recently PointerEvent was speced with [Constructor] [2]. Considering
 that PointerEvent inherits MouseEvent, now we want to support
 [Constructor] on MouseEvent
 too. In terms of implementation, it is possible to implement
 [Constructor] on PointerEvent without implementing [Constructor] on
 MouseEvent. However, implementing [Constructor] on both PointerEvent
 and MouseEvent would be best.
 
 == Rationale for implementing constructors for DOM4 Events ==
 
 I have been discussing this topic for one year, in www-dom@ [4] and a
 www.w3.org bug [3]. It looks like there is a consensus on introducing
 constructors for DOM4 Events. However, the spec is still a draft [1]
 and the www.w3.org bug [3] is marked as LATER. Last week I discussed
 the timeline of the spec with Jacob Rossi (a.k.a. a spec author of
 PointerEvent and DOM4 Events). According to him:
 
 - Their primary focus is on finishing DOM3 Events first.
 - With DOM3 Events in Candidate Recommendation, they are going to
 start working on the DOM4 Events. They will discuss it in TPAC.
 - They will introduce constructors to DOM4 Events.
 
 In summary, constructors for DOM4 Events are going to be speced, but
 it will take time. So I would like to implement them in WebKit a bit
 ahead of the spec (and thus implement PointerEvent constructors too).
 If you have any concern, please let me know.
 
 
 == References ==
 [1] The spec draft by Jacob Rossi:
 http://html5labs.interoperabilitybridges.com/dom4events/
 
 [2] The spec of Pointer Events:
 http://www.w3.org/Submission/pointer-events/
 
 [3] www.w3.org bug:
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14051
 
 [4] Discussion on www-dom@:
 http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0081.html
 http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0025.html
 
 [5] WebKit bug:
 https://bugs.webkit.org/show_bug.cgi?id=67824
 
 
 --
 Kentaro Hara, Tokyo, Japan (http://haraken.info)
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 --
 Kentaro Hara, Tokyo, Japan (http://haraken.info)
 
 
 
 -- 
 Kentaro Hara, Tokyo, Japan
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Changes to the WebKit2 development process

[Sam Weinig]

Trivial changes like this do not need to be approved by an owner.

-Sam

On Jan 9, 2013, at 9:38 AM, Gregg Tavares g...@google.com wrote:

 I've got a patch in flight that adds a feature flag. 
 https://bugs.webkit.org/show_bug.cgi?id=106275
 
 According to the instructions liked below I need to edit a WebKit2 file
 http://trac.webkit.org/wiki/AddingFeatures#ActivatingafeatureforAutotoolsbasedports
 
 Does that guideline change? Should I remove the WebKit2 change?
 
 
 On Tue, Jan 8, 2013 at 2:57 PM, Sam Weinig wei...@apple.com wrote:
 Hello webkit-dev,
 
 We are making some changes to the development process for WebKit2. These 
 changes were announced to reviewers in advance, and I'd like to share them 
 with you now.
 
 WebKit2 has a core set of functionality that is valuable to all ports, and 
 then aspects that are only of limited/specialized interest. It is becoming 
 increasingly difficult to improve and advance the core functionality while 
 maintaining the more peripheral aspects. In addition, changes to the core 
 often require significant expertise to evaluate, for instance to ensure that 
 the security and responsiveness goals of WebKit2 are met.
 
 The changes are:
 
 1) WebKit2 now has owners. Only owners should review WebKit2 patches. While 
 we do not want to apply this concept across the whole WebKit project at this 
 time, for WebKit2 it is appropriate. The list of owners is documented in the 
 Owners file at the WebKit2 top level directory, and in committers.py.
 
 2) Ports must keep themselves building. Non Apple Mac ports, if broken by 
 core functionality changes to WebKit2, are now responsible for fixing 
 themselves. We have asked those who run the EWS bots to make sure that 
 failing to build WebKit2 does not block the commit queue from committing.
 
 3) Over time, owners may remove peripheral functionality from the main 
 WebKit2 directory, such as support for features that aren't broadly 
 applicable. We will not do this immediately, and we will work with ports that 
 are interested in such features to create appropriate, maintainable 
 general-purpose mechanisms that can be used to implement them outside of core 
 WebKit2 code.
 
 While we understand that this change will inconvenience some ports, we have 
 decided that forward progress of WebKit2 is a more important concern, and we 
 are moving forward with this change tonight.
 
 - Sam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 

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

Re: [webkit-dev] Changes to the WebKit2 development process

[Sam Weinig]

On Jan 9, 2013, at 8:10 AM, Gustavo Noronha Silva g...@gnome.org wrote:

 On Qua, 2013-01-09 at 12:04 +0200, Thiago Marcos P. Santos wrote:
 I think the fact that the regular WebKit review process stops at the 
 boundary
 of WebKit2 should be documented in the WebKit Committers and Reviewer 
 Policy.
 
 
 Agree. And please clarify on the policy if we are talking about
 everything inside the WebKit2/ directory or if we have exceptions. It
 is not clear to me if port specific code is covered by this rule and
 should by reviewed by the owners. And what about code shared by Qt,
 GTK and EFL (i.e. Platform/CoreIPC/unix/) but not used by Mac?
 
 Curious about this myself, I just reviewed a patch only affecting the
 GTK-specific parts of WebKit2, I believe that is OK? Should we ammend
 the Owners file to include information about port-specific directories
 and reviewers?
 
 Cheers,

At this point, we ask that all completely non-trivial patches be reviewed by an 
owner, even if in port specific code.

- Sam

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

[webkit-dev] Changes to the WebKit2 development process

[Sam Weinig]

Hello webkit-dev,

We are making some changes to the development process for WebKit2. These 
changes were announced to reviewers in advance, and I'd like to share them with 
you now.

WebKit2 has a core set of functionality that is valuable to all ports, and then 
aspects that are only of limited/specialized interest. It is becoming 
increasingly difficult to improve and advance the core functionality while 
maintaining the more peripheral aspects. In addition, changes to the core often 
require significant expertise to evaluate, for instance to ensure that the 
security and responsiveness goals of WebKit2 are met.

The changes are:

1) WebKit2 now has owners. Only owners should review WebKit2 patches. While we 
do not want to apply this concept across the whole WebKit project at this time, 
for WebKit2 it is appropriate. The list of owners is documented in the Owners 
file at the WebKit2 top level directory, and in committers.py.  

2) Ports must keep themselves building. Non Apple Mac ports, if broken by core 
functionality changes to WebKit2, are now responsible for fixing themselves. We 
have asked those who run the EWS bots to make sure that failing to build 
WebKit2 does not block the commit queue from committing.

3) Over time, owners may remove peripheral functionality from the main WebKit2 
directory, such as support for features that aren't broadly applicable. We will 
not do this immediately, and we will work with ports that are interested in 
such features to create appropriate, maintainable general-purpose mechanisms 
that can be used to implement them outside of core WebKit2 code.

While we understand that this change will inconvenience some ports, we have 
decided that forward progress of WebKit2 is a more important concern, and we 
are moving forward with this change tonight.

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

Re: [webkit-dev] [WK2] WebContext destructor is never triggered on normal exit

[Sam Weinig]

I see.  Then what I said was right, you just need to release your WKContextRef 
when exiting your minibrowser.  This should not be changed in WebKit.

-Sam

On Aug 27, 2012, at 8:02 PM, Kangil Han kangil@samsung.com wrote:

 I hope below bug url would help your understanding.
 https://bugs.webkit.org/show_bug.cgi?id=94783
  
 My query was from finding ‘LEAK’ on WebContext that is supposed being 
 triggered from ‘WTF::RefCountedLeakCounter’ automatically when exit 
 minibrowser.
 I have investigated little bit further and found WebContext would be freed by 
 WebProcessProxy which depends on WebProcess.
  
 As Alexey described in that bug, we would gain little compared to efforts.
 However, I think ignoring destructor call and see the ‘LEAK’ print out 
 message at every time I exit program on debug build would not be so nice.
 That’s why I’ve asked here for hearing opinions. :)
  
 - kangil
  
 From: Sam Weinig [mailto:wei...@apple.com] 
 Sent: Sunday, August 26, 2012 8:36 AM
 To: kangil@samsung.com
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] [WK2] WebContext destructor is never triggered on 
 normal exit
  
 I'm not clear on what you mean.  A client of WebKit2 release their 
 WKContextRef pointer from atexit() if they wanted to (or in whatever other 
 termination routines they already have), but its not clear to me why the 
 framework should do it for them.  We don't do this for any other objects.
  
 -Sam
  
 On Aug 24, 2012, at 7:15 PM, Kangil Han kangil@samsung.com wrote:
 
 
 Hi,
  
 I’ve found WebContext destructor is never triggered on normal exit in WK2.
  
 This happens because only IPC message from WebProcess could terminate it but 
 won’t do that in this case.
 One possibility for doing this is to create a flow of termination from 
 UIProcess on exit.
  
 But, before starting investigation, I would like to ask your opinion.
  
 kangil
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] [WK2] WebContext destructor is never triggered on normal exit

[Sam Weinig]

I'm not clear on what you mean.  A client of WebKit2 release their WKContextRef 
pointer from atexit() if they wanted to (or in whatever other termination 
routines they already have), but its not clear to me why the framework should 
do it for them.  We don't do this for any other objects.

-Sam

On Aug 24, 2012, at 7:15 PM, Kangil Han kangil@samsung.com wrote:

 Hi,
  
 I’ve found WebContext destructor is never triggered on normal exit in WK2.
  
 This happens because only IPC message from WebProcess could terminate it but 
 won’t do that in this case.
 One possibility for doing this is to create a flow of termination from 
 UIProcess on exit.
  
 But, before starting investigation, I would like to ask your opinion.
  
 kangil
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Proposal and WIP implementation for refactoring cross thread communication

[Sam Weinig]

Function is definitely useful in non-cross thread cases.  It is analogous to 
std::function, and its use cases are very similar.  Please don't rename it.

-Sam

On Aug 15, 2012, at 7:35 PM, Kwonjin Jeong g...@company100.net wrote:

 I also thought about what you said. But I'm not sure whether WTF::Function 
 will be used for cross thread communication only.
 
 So, I'd like to know whether WTF::Function won't be used for single threaded 
 case.
 
 On Tue, Aug 14, 2012 at 8:57 AM, KwangYul Seo sk...@company100.net wrote:
 Currently, there is no code using WTF::Function in single-threaded code. It 
 seems WTF::Function is intended to be used for cross thread communication. 
 One evidence is that FunctionImplBase is thread-safe ref-counted, which is 
 not super efficient for single threaded use cases.
 
 If we have no plan to use WTF::Function for single threaded code, why don't 
 we rename WTF::Function to WTF::CrossThreadFunction and add more features 
 such as cross thread copying there?
 
 Regards,
 Kwang Yul Seo
 
 On Mon, Aug 13, 2012 at 9:26 PM, Kwonjin Jeong g...@company100.net wrote:
 Hi, WebKit.
 
 There are several implementations of threads, tasks and cross thread 
 communication. e.g. FileThread, DatabaseThread and StorageThread perform 
 blocking IO asynchronously and invoke callbacks using ScriptExecutionContext. 
 Each of these implementation is pretty similar, but there is no code sharing 
 at all.
 
 So, my team at Company 100 is trying to refactor cross thread communication. 
 We wrote an API proposal and modified some thread code to use our new API. 
 
 As the first step, we added two new abstractions for cross thread 
 communcation:
 
 1) TaskThread is our new abstraction for the task thread. FileThread, 
 DatabaseThread and other task threads reuse the code by inheriting from 
 TaskThread.
 
 2) We also added CrossThreadFunction. It's used to pass a task to the task 
 thread and invoke callbacks. CrossThreadFunction is similar to WTF::Function 
 but it has some additional features. e.g., cross-thread parameter copying and 
 ref counting.
 
 Please refer to the following bug for details:
 
 https://bugs.webkit.org/show_bug.cgi?id=92365
 
 We welcome feedbacks on our work.
 
 Thanks.
 
 -- 
 
 Kwonjin Jeong
 Computer Scientist
 Company 100, Inc.
 Phone: +82-10-9528-2581
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 
 
 -- 
 
 Kwonjin Jeong
 Computer Scientist
 Company 100, Inc.
 Phone: +82-10-9528-2581
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

[Sam Weinig]

On Jun 3, 2012, at 6:10 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth aba...@webkit.org wrote:
 On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Sun, Jun 3, 2012 at 5:33 PM, Maciej Stachowiak m...@apple.com wrote:
 On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Sun, Jun 3, 2012 at 3:55 PM, Maciej Stachowiak m...@apple.com wrote:
 I am on vacation so I won't be able to review your patch in detail, but from 
 your description it sounds less appealing to me than the WKTR approach. It 
 seems like bad layering to me to define the IDL interface in WebCore for 
 something actually implemented completely outside of WebCore.
 
 While you're right that it's somewhat of a layer violation to define the IDL 
 for layoutTestController, WebCoreTestSupport appears to be the most logical 
 place to share files between DumpRenderTree and WebKitTestRunner at the 
 moment unless we're going to create another project/library in Tools.
 
 The downside is that they would be using internal WebCore interfaces instead 
 of the public interface as originally intended. I do not think that is a good 
 change, nor does it seem required just to share more code.
 
 Are you referring to things like JSValueRef? If JS* functions are supposed to 
 be tested in DumpRenderTree, then that's a good argument against this 
 approach.
 
 JavaScriptCore has a bunch of tests for its API independent of 
 DumpRenderTree.  I suspect Maciej's point is more about having DumpRenderTree 
 use public rather than private interfaces so that it's easier for 
 JavaScriptCore to change its private interfaces.
 
 Have you looked at adding a V8 backend to the code generator that 
 WebKitTestRunner is using currently?  My guess is that it will be much 
 simpler than CodeGeneratorV8.pm because WebKitTestRunner doesn't have deal 
 with all the exciting variety was have in the web platform.  
 http://trac.webkit.org/browser/trunk/Tools/WebKitTestRunner/InjectedBundle/Bindings/CodeGeneratorTestRunner.pm
  hasn't changed in 17 months, so I wouldn't expect an ongoing maintenance 
 issue.
 
 Yes. But there was a recent discussion about supporting V8 in 
 WebKitTestRunner where Sam objected to it citing that doing so will clutter 
 the WTR's codebase. I have no problem with creating a V8 backend if Sam 
 doesn't mind introducing V8 equivalent there.
 

My objects were to adding V8 support to WebKit2, not WebKitTestRunner.

 However, the real difficulty is in sharing files between WebKitTestRunner and 
 DumpRenderTree, and modifying 11? build configurations we have for 
 DumpRenderTree.
 

Just to give a bit of history here, the reason I didn't use DumpRenderTree for 
writing a test harness for WebKit2 was that there was no real benefit in me 
doing so.  The requirements of the test harness were quite different than they 
were for a test harness for WebKit1, specifically, we had to split 
functionality between the UIProcess and injected bundle.  In addition, 
DumpRenderTree had become a weird hodge-podge of code, where sharing code 
between projects seemed to be the exception, rather than the rule, for 
instance, I am not sure if the chromium port shares any code in DumpRenderTree 
with other ports (I could be wrong there), and since I was binding to a new 
API, a fresh start seemed the way to go.  All in all, I feel it has worked 
quite well, and has allowed better sharing of code between the Qt, Mac, Gtk and 
Windows WebKit2 implementations.

That said, I am not sure the current approach taken in WebKitTestRunner is 
fully suited to being merged with DumpRenderTree.  It is quite tied to the idea 
of having two processes and specifically the WebKit2 API. 

-Sam


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

Re: [webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

[Sam Weinig]

On Jun 4, 2012, at 11:07 AM, Adam Barth aba...@webkit.org wrote:

 On Mon, Jun 4, 2012 at 10:51 AM, Sam Weinig wei...@apple.com wrote:
 On Jun 3, 2012, at 6:10 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth aba...@webkit.org wrote:
 On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Sun, Jun 3, 2012 at 5:33 PM, Maciej Stachowiak m...@apple.com wrote:
 On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Sun, Jun 3, 2012 at 3:55 PM, Maciej Stachowiak m...@apple.com wrote:
 I am on vacation so I won't be able to review your patch in detail, but 
 from your description it sounds less appealing to me than the WKTR 
 approach. It seems like bad layering to me to define the IDL interface in 
 WebCore for something actually implemented completely outside of WebCore.
 
 While you're right that it's somewhat of a layer violation to define the 
 IDL for layoutTestController, WebCoreTestSupport appears to be the most 
 logical place to share files between DumpRenderTree and WebKitTestRunner at 
 the moment unless we're going to create another project/library in Tools.
 
 The downside is that they would be using internal WebCore interfaces instead 
 of the public interface as originally intended. I do not think that is a 
 good change, nor does it seem required just to share more code.
 
 Are you referring to things like JSValueRef? If JS* functions are supposed 
 to be tested in DumpRenderTree, then that's a good argument against this 
 approach.
 
 JavaScriptCore has a bunch of tests for its API independent of 
 DumpRenderTree.  I suspect Maciej's point is more about having 
 DumpRenderTree use public rather than private interfaces so that it's easier 
 for JavaScriptCore to change its private interfaces.
 
 Have you looked at adding a V8 backend to the code generator that 
 WebKitTestRunner is using currently?  My guess is that it will be much 
 simpler than CodeGeneratorV8.pm because WebKitTestRunner doesn't have deal 
 with all the exciting variety was have in the web platform.  
 http://trac.webkit.org/browser/trunk/Tools/WebKitTestRunner/InjectedBundle/Bindings/CodeGeneratorTestRunner.pm
  hasn't changed in 17 months, so I wouldn't expect an ongoing maintenance 
 issue.
 
 Yes. But there was a recent discussion about supporting V8 in 
 WebKitTestRunner where Sam objected to it citing that doing so will clutter 
 the WTR's codebase. I have no problem with creating a V8 backend if Sam 
 doesn't mind introducing V8 equivalent there.
 
 
 My objects were to adding V8 support to WebKit2, not WebKitTestRunner.

*objections* :(.

 
 However, the real difficulty is in sharing files between WebKitTestRunner 
 and DumpRenderTree, and modifying 11? build configurations we have for 
 DumpRenderTree.
 
 
 Just to give a bit of history here, the reason I didn't use DumpRenderTree 
 for writing a test harness for WebKit2 was that there was no real benefit in 
 me doing so.  The requirements of the test harness were quite different than 
 they were for a test harness for WebKit1, specifically, we had to split 
 functionality between the UIProcess and injected bundle.  In addition, 
 DumpRenderTree had become a weird hodge-podge of code, where sharing code 
 between projects seemed to be the exception, rather than the rule, for 
 instance, I am not sure if the chromium port shares any code in 
 DumpRenderTree with other ports (I could be wrong there), and since I was 
 binding to a new API, a fresh start seemed the way to go.  All in all, I feel 
 it has worked quite well, and has allowed better sharing of code between the 
 Qt, Mac, Gtk and Windows WebKit2 implementations.
 
 That said, I am not sure the current approach taken in WebKitTestRunner is 
 fully suited to being merged with DumpRenderTree.  It is quite tied to the 
 idea of having two processes and specifically the WebKit2 API. 
 
 Even if we don't end up fully merging the two, sharing the IDL file seems 
 valuable since they're intended to run the same tests, which means the 
 interface between the tests and the test harness should be the same.
 
 Adam

I would not object to the IDL files being shared, as long it doesn't introduce 
additional mental overhead.  Right now, it is pretty simple, and I would like 
to keep it that way.

-Sam
 

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

Re: [webkit-dev] Removing type attribute from DOMSelection

[Sam Weinig]

Without any data on its usage, I don't support this.

-Sam
 
On May 30, 2012, at 9:58 PM, Antaryami Pandia xqb...@motorola.com wrote:

 Hi ,
 We plan to remove the type attribute from DOM selection.
 This attribute is not part of any standard specification and the current 
 webkit implementation is not consistent with IE.
 I looked at Firefox's selection interface and found its not implemeted there 
 (http://doxygen.db48x.net/mozilla/html/interfacensISelection.html).
 
 The webkit bug is https://bugs.webkit.org/show_bug.cgi?id=23853
 
 Please let me know, any concerns about removal of this attribute.
 
 Regards,
 -Antaryami
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] webkit2 with v8

[Sam Weinig]

Hi Balazs,

This is something we don't want at this time.  Dealing with V8 in WebCore is 
pretty big maintenance burden and one I would rather not have in WebKit2 unless 
there is considerable demand for it.  

In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), 
there are many intrusive changes to core WebKit2 code, making it harder to 
comprehend and refactor. 
Also, since a much bigger proportion of developers who develop WebKit2 don't 
ever compile V8, it seems more likely that the code will stop working.

-Sam

On Apr 23, 2012, at 3:28 AM, Balazs Kelemen kbal...@webkit.org wrote:

 Hi everyone,
 
 I would like to inform you about the topic I am working on, since it is 
 something
 that can affect WebKit2 architecturally. I would like to make WebKit2 work 
 with v8.
 The motivation behind this is that the long term goal of the Qt port is to 
 switch to v8.
 Qt already use v8 in it's Qml module, and it's better to have only one VM in 
 the framework
 (less code size, less memory usage, easier maintenance).
 
 My goal is to achieve this with the minimal amount of changes made in 
 WebKit2. My plan
 for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in 
 another point of
 view, implement the JSC API upon the v8 API). For the core of WebKit2 we will 
 have to use
 some bindings for things like plugins or the injected bundle but it should be 
 not too much of
 a maintenance burden.
 
 Inform me if you have any concerns or suggestion.
 
 Cheers!
 Balazs Kelemen
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] webkit2 with v8

[Sam Weinig]

Without considerable more demand, I don't think we want this.

-Sam

On Apr 23, 2012, at 3:20 PM, Balazs Kelemen kbal...@webkit.org wrote:

 On 04/23/2012 11:53 PM, Sam Weinig wrote:
 Hi Balazs,
 
 This is something we don't want at this time.  Dealing with V8 in WebCore is 
 pretty big maintenance burden and one I would rather not have in WebKit2 
 unless there is considerable demand for it.
 
 Well, it's important for Qt.
 
 
 In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), 
 there are many intrusive changes to core WebKit2 code, making it harder to 
 comprehend and refactor.
 Also, since a much bigger proportion of developers who develop WebKit2 don't 
 ever compile V8, it seems more likely that the code will stop working.
 
 The WIP patch I uploaded is just a very first step to make it possible to 
 build with v8
 without breaking the most basic features. I have just overhacked every 
 problematic part
 - instead of finding a proper solution to them - to see how many dependencies 
 there are
 on JSC as quickly as possible. It should be way better before uploaded for 
 review.
 
 
 
 -Sam
 
 On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org  wrote:
 
 Hi everyone,
 
 I would like to inform you about the topic I am working on, since it is 
 something
 that can affect WebKit2 architecturally. I would like to make WebKit2 work 
 with v8.
 The motivation behind this is that the long term goal of the Qt port is to 
 switch to v8.
 Qt already use v8 in it's Qml module, and it's better to have only one VM 
 in the framework
 (less code size, less memory usage, easier maintenance).
 
 My goal is to achieve this with the minimal amount of changes made in 
 WebKit2. My plan
 for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in 
 another point of
 view, implement the JSC API upon the v8 API). For the core of WebKit2 we 
 will have to use
 some bindings for things like plugins or the injected bundle but it should 
 be not too much of
 a maintenance burden.
 
 Inform me if you have any concerns or suggestion.
 
 Cheers!
 Balazs Kelemen
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

[Sam Weinig]

Hey Dave,

Can you describe the use case for this new property?  When would an author use 
it?

-Sam

On Mar 22, 2012, at 4:16 PM, David Levin le...@chromium.org wrote:

 Resurrecting a really old thread so continue the conversation now that I'm 
 hitting this issue :).
 
 On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig sam.wei...@gmail.com wrote:
 I am not sure I agree.  Does our behavior actually cause any real bugs in the 
 places you have tracked down?  The log spam really doesn't seem like an 
 issue, we can remove it if we want to, but have found it useful in the past. 
 
 Speaking as someone who working on a web app, the log spam is a significant 
 issue because:
 It clutters up the console output making it harder to find the real error. 
 (It is hard to explain how much worse this makes the experience until you 
 have to deal with a sophisticated web page. Image looking at the logs from 
 your app and seeing lots of error messages -- many of which are this one and 
 then a real one hidden among them -- from personal experience.)
 When more sophisticated end users see it, they think there is a problem in 
 the app and report it (and it could be that they include this in their error 
 report and ignore other more important things).
 I understand that that the console/log spam is useful to detect real issues 
 as well (given that WebKit doesn't throw an exception in this case).
 
 Would people find it acceptable to have window.webkitCanAccess so that a web 
 page can use that property first to detect the cross origin issue and avoid 
 doing an access which would trigger the console spam? (I would also be fine 
 with an exception instead of log spam.)
 
 Thanks,
 dave
 
 
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] CSS3 Selectors3 test suite

[Sam Weinig]

On Mar 22, 2012, at 6:41 PM, Ojan Vafai o...@chromium.org wrote:

 I've recently been greening Chromium's expectations for css3/selectors3. ~10% 
 of these test need interaction (e.g. hovering over a link or selecting text). 
 Given that this is an imported test suite does it make sense to add the 
 appropriate layoutTestController hooks? As it is, the tests aren't really 
 verifying correctness.

I don't think it is a good idea to change imported suites unless we can do it a 
non-destructive way (e.g. all tests in this directory get this script added to 
them).  If we want to split up the tests that require interaction from the 
others, we should do that upstream and see if we can make as many as we can not 
require explicit interaction.

 
 Also, this test suite is a great example of one that I think it would make 
 more sense for us to check in reftest expected results instead of 
 png+rendertreedump. These tests are explicitly testing selector matching 
 only, so it would be easy to write reftests that have a high confidence of 
 accurately verifying correctness. They'd only fail if we had some egregious 
 bug such that we painted everything green as white. Presumably we'd notice 
 such a bug through other means.
 

Again, I think this should happen upstream in the CSS working group.

-Sam

 Ojan
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[webkit-dev] 2012 WebKit Contributors' meeting

[Sam Weinig]

Apple will once again be hosting a WebKit Contributors Meeting. It will be held 
at the Cypress Hotel in Cupertino, CA on April 19 and 20. This meeting is for 
contributors to the WebKit Open Source Project. As with the meeting last year, 
this event will have an unconference-like format, allowing plenty of time for 
impromptu sessions/discussions and hacking.

The meeting will be free of charge. All WebKit contributors are encouraged to 
attend. However, space is limited, so registrations will be accepted on a 
first-come, first-served basis.

Please register for the conference using the form at 
https://www.webkit.org/meeting/ by April 11. When you register, you will 
automatically be subscribed to webkit-meet...@lists.webkit.org, which will be 
used for general discussion and to communicate additional information about the 
meeting.

If you have any questions about the meeting, or about whether this meeting is 
appropriate for you to attend, you may email me at wei...@apple.com.

We hope to see you there!

Thanks,
Sam Weinig

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

Re: [webkit-dev] About BrowsingContext and WindowProxy spec

[Sam Weinig]

On Mar 7, 2012, at 9:25 PM, Darin Adler wrote:

 On Mar 7, 2012, at 9:34 AM, Adam Barth wrote:
 
 The WindowProxy is implemented in WebKit using the WindowShell class.
 
 Idle thought: We might want to consider renaming our WindowShell class 
 WindowProxy, just to match the HTML specification concept, as I think we’ve 
 done in a few other cases.
 
 -- Darin

Yeah, we should do that.  Filed https://bugs.webkit.org/show_bug.cgi?id=80733.

-Sam

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

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

[Sam Weinig]

On Mar 7, 2012, at 4:41 PM, Ojan Vafai wrote:

 I just did a first pass a greening the Chromium Lion bot: 
 http://trac.webkit.org/changeset/110096. Of these hundreds of tests,  ~99% of 
 them are perfect candidates for being reftests (e.g. they contain one line of 
 text and a solid box or two under the text), but most of them are in the CSS 
 imported test suites.
 
 Is it kosher to convert them to reftests or should we leave pixel tests from 
 imported test suites alone?

If we want to make these ref tests, it probably makes more sense to do that 
work with the CSS WG, so that they can be part of the standard test suite. 
Until then, I think we should keep them regular pixel tests.

-Sam

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

Re: [webkit-dev] Should WebKit require SQLite?

[Sam Weinig]

It seems acceptable to me to require SQLite.  

-Sam

On Dec 3, 2011, at 10:47 AM, Ryosuke Niwa wrote:

 Hi,
 
 Recent removal of OFFLINE_WEB_APPLICATIONS flag in 
 http://trac.webkit.org/changeset/96123 made SQLite a new requirement to port 
 WebKit. However, there are many operating systems and platforms (mostly 
 embedding) into which SQLite hasn't been ported yet; e.g. 
 http://www.monaos.org/.
 
 It seems undesirable to increase the number of dependencies since being able 
 to port easily is one of the strengths of WebKit. On the other hand, reducing 
 the number of flags will certainly reduce the build system complexity for 
 people who are already shipping with SQLite.
 
 Do we want to require SQLite to port WebKit for the sake to reducing the 
 complexity for major ports?
 
 Best,
 Ryosuke Niwa
 Software Engineer
 Google Inc.
 
 P.S. I have https://bugs.webkit.org/show_bug.cgi?id=73749 to reintroduce 
 OFFLINE_WEB_APPLICATIONS.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] EventConstructors.h

[Sam Weinig]

It should long term be generated from the EventInit dictionary IDLs, but it was 
handy to implement it in a macro based DSL initially. 

-Sam

On Nov 2, 2011, at 11:02 AM, Adam Barth wrote:

 This file seems to be growing a list of ever feature in the project:
 
 Source/WebCore/bindings/generic/EventConstructors.h
 
 Can we generate this file from the event IDL files?
 
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Tightening up our include discipline

[Sam Weinig]

I'd be interested in performance cost to that, especially on a test that 
creates a lot of JS wrapped Events.

-Sam

On Oct 18, 2011, at 6:42 PM, Adam Barth wrote:

 My thought on that is to use a single virtual function and return an atomic 
 string, like we do for elements.
 
 Adam
 On Oct 18, 2011 6:10 PM, Sam Weinig wei...@apple.com wrote:
 For the specific case of Event, we do need some sort of poor man's RTTI here 
 for the sake of the bindings, but we could consider alternatives.  Since you 
 need to identify the subclasses, you need to either use many virtual 
 functions, as we do currently for Event, or have some tagging mechanism, 
 which we do for classes like Element and EventListener.
 
 If we use a tagging technique, we need someway to ensure that the tags are 
 unique. In EventListener, we list the types up front in an enum, though this 
 has same downside as the many virtual functions in that the tendrils of 
 WebAudio reach into the base class.  For Element, we rely on qualified names, 
 which doesn't require the icky reach, but are slightly more costly.  (You 
 still end up with the tendrils in the JS base class).
 
 Of course, it might make sense to solve the issue of #ifdefs in Event by 
 simply removing the #ifdefs in Event, since they are just base class 
 implementations. The only downside of that is if we later remove the feature, 
 it is harder to find all the places it touched.
 
 -Sam
 
 On Oct 18, 2011, at 4:37 PM, Adam Barth wrote:
 
  The other day, Sam chided me on a bug for including a header from
  WebCore proper in a file in WebCore/platform.  Even though I know I'm
  not supposed to do that, it's an easy mistake to make.  There's some
  work going on in https://bugs.webkit.org/show_bug.cgi?id=49192 to
  improve the style checker to flag these sorts of bad dependencies.
  This check isn't live yet, but don't be surprised if some robotic user
  complains about a bad include in one of your patches.  (As always, if
  the bot complains incorrectly, please let me know so we can eliminate
  false positives.)
 
  Relatedly, as part of the recent ENABLE cleanup effort, I noticed that
  some files (e.g.,
  http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Event.cpp)
  attract lots of ifdefs because many unrelated features need to
  register themselves.  I was thinking it might be an improvement to
  restructure things a bit so that, for example, WebAudio wouldn't need
  to reach its fingers into Event.cpp and instead could be better
  contained in the WebCore/webaudio directory.
 
  I welcome any thoughts you have on either of these topics.
 
  Thanks,
  Adam
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

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

Re: [webkit-dev] Style guide should mention that we don't use anonymous namespace

[Sam Weinig]

Another benefit to using the static keyword is that you can tell at a glance 
that the function is internal to the translation unit, while you may not notice 
the anonymous namespace.

-Sam

On Oct 19, 2011, at 3:45 PM, Darin Adler wrote:

 The guideline is not to disallow anonymous namespaces.
 
 It’s to prefer “static” over anonymous namespaces when either one would work.
 
 Debugging tools on at least some of the platforms work better with functions 
 that are given internal linkage by using the “static” keyword rather than 
 functions that are inside anonymous namespaces.
 
 On the other hand, anonymous namespaces are a more powerful tool that can do 
 more than the “static” keyword can.
 
-- Darin
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] ENABLE-removal summary

[Sam Weinig]

Hazzah! Great work Adam and friends!

-Sam

On Oct 18, 2011, at 10:37 AM, Adam Barth wrote:

 As discussed previously on webkit-dev, we've been cleaning up some of
 the ENABLE macros in WebKit:
 
 https://lists.webkit.org/pipermail/webkit-dev/2011-September/017988.html
 
 As part of this effort, we've removed 19 ENABLE macros.  Of those, 5
 were converted to USE macros, 6 were deleted along with their
 associated code, and 8 were removed and the associated code was always
 enabled.
 
 I'd like to thank everyone who helped with this project, both patch
 writers and reviewers.  Hopefully everyone will find WebKit a little
 more hackable now.  :)
 
 Enjoy,
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Tightening up our include discipline

[Sam Weinig]

For the specific case of Event, we do need some sort of poor man's RTTI here 
for the sake of the bindings, but we could consider alternatives.  Since you 
need to identify the subclasses, you need to either use many virtual functions, 
as we do currently for Event, or have some tagging mechanism, which we do for 
classes like Element and EventListener. 

If we use a tagging technique, we need someway to ensure that the tags are 
unique. In EventListener, we list the types up front in an enum, though this 
has same downside as the many virtual functions in that the tendrils of 
WebAudio reach into the base class.  For Element, we rely on qualified names, 
which doesn't require the icky reach, but are slightly more costly.  (You still 
end up with the tendrils in the JS base class).

Of course, it might make sense to solve the issue of #ifdefs in Event by simply 
removing the #ifdefs in Event, since they are just base class implementations. 
The only downside of that is if we later remove the feature, it is harder to 
find all the places it touched.

-Sam

On Oct 18, 2011, at 4:37 PM, Adam Barth wrote:

 The other day, Sam chided me on a bug for including a header from
 WebCore proper in a file in WebCore/platform.  Even though I know I'm
 not supposed to do that, it's an easy mistake to make.  There's some
 work going on in https://bugs.webkit.org/show_bug.cgi?id=49192 to
 improve the style checker to flag these sorts of bad dependencies.
 This check isn't live yet, but don't be surprised if some robotic user
 complains about a bad include in one of your patches.  (As always, if
 the bot complains incorrectly, please let me know so we can eliminate
 false positives.)
 
 Relatedly, as part of the recent ENABLE cleanup effort, I noticed that
 some files (e.g.,
 http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Event.cpp)
 attract lots of ifdefs because many unrelated features need to
 register themselves.  I was thinking it might be an improvement to
 restructure things a bit so that, for example, WebAudio wouldn't need
 to reach its fingers into Event.cpp and instead could be better
 contained in the WebCore/webaudio directory.
 
 I welcome any thoughts you have on either of these topics.
 
 Thanks,
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Style: Vector::iterator vs indexed iteration

[Sam Weinig]

In general, we have preferred index style.

-Sam

On Oct 17, 2011, at 2:48 PM, Adam Klein wrote:

 A small style question came up in a review today, and I was curious if
 there's any consensus on this: when iterating over a WTF::Vector, does
 WebKit style prefer using a size_t vs a Vector::iterator, or
 vice-versa?  Both show up in WebCore, but the indexed style is more
 common (by maybe a 5-1 ratio by my rough git grep estimation), which
 at least suggests that it may be preferred.
 
 - Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Current legacy argument refactoring -- behavior changes?

[Sam Weinig]

This list doesn't seem to include the changes in behavior to addEventListener 
and removeEventListerner (from patches like 
http://trac.webkit.org/changeset/92469 http://trac.webkit.org/changeset/92433). 
 Are those intentionally left out?

-Sam


On Aug 5, 2011, at 12:44 PM, Mark Pilgrim wrote:

 Here is the complete list of intentional behavior changes in patches
 I've submitted in the past few months, along with bug URLs to show the
 discussion / rationale behind each change:
 
 
 https://bugs.webkit.org/show_bug.cgi?id=63065
 
 IDBFactory.open()
 
 https://bugs.webkit.org/show_bug.cgi?id=63079
 
 IDBIndex.get()
 IDBIndex.getKey()
 
 https://bugs.webkit.org/show_bug.cgi?id=63085
 
 IDBKeyRange.only()
 IDBKeyRange.lowerBound()
 IDBKeyRange.upperBound()
 IDBKeyRange.bound()
 
 https://bugs.webkit.org/show_bug.cgi?id=63087
 
 IDBObjectStore.put()
 IDBObjectStore.add()
 IDBObjectStore.delete()
 IDBObjectStore.get()
 IDBObjectStore.createIndex()
 IDBObjectStore.index()
 IDBObjectStore.deleteIndex()
 
 https://bugs.webkit.org/show_bug.cgi?id=63140
 
 IDBDatabase.createObjectStore()
 IDBDatabase.deleteObjectStore()
 IDBDatabase.setVersion()
 IDBDatabase.transaction()
 
 https://bugs.webkit.org/show_bug.cgi?id=64539
 
 all arguments in File API-related methods not already marked [Optional]
 
 https://bugs.webkit.org/show_bug.cgi?id=64549
 
 all arguments in WebGL-related methods not already marked [Optional]
 
 https://bugs.webkit.org/show_bug.cgi?id=65338
 
 DOMTokenList.item()
 DOMTokenList.contains()
 DOMTokenList.add()
 DOMTokenList.remove()
 DOMTokenList.toggle()
 DOMURL.createObjectURL()
 DOMURL.revokeObjectURL()
 HTMLAnchorElement.getParameter()
 HTMLButtonElement.setCustomValidity()
 HTMLFieldSetElement.setCustomValidity()
 HTMLInputElement.setCustomValidity()
 HTMLKeygenElement.setCustomValidity()
 HTMLMediaElement.canPlayType()
 TimeRanges.start()
 TimeRanges.end()
 HTMLAllCollection.namedItem()
 HTMLAllCollection.tags()
 
 https://bugs.webkit.org/show_bug.cgi?id=65353
 
 DOMWindow.webkitRequestFileSystem()
 DOMWindow.webkitResolveLocalFileSystemURL()
 DOMWindow.webkitRequestAnimationFrame() (reverted in
 https://bugs.webkit.org/show_bug.cgi?id=65698 )
 DOMWindow.webkitCancelRequestAnimationFrame() (reverted in
 https://bugs.webkit.org/show_bug.cgi?id=65698 )
 
 https://bugs.webkit.org/show_bug.cgi?id=65355
 
 Geolocation.clearWatch()
 PositionCallback.handleEvent()
 PositionErrorCallback.handleEvent()
 
 https://bugs.webkit.org/show_bug.cgi?id=65370
 
 Navigator.registerProtocolHandler()
 
 https://bugs.webkit.org/show_bug.cgi?id=65570
 
 SpeechInputResultList.item()
 
 https://bugs.webkit.org/show_bug.cgi?id=65571
 
 WebKitAnimationList.item()
 
 https://bugs.webkit.org/show_bug.cgi?id=65715
 
 MediaStreamList.item()
 MediaStreamTrackList.item()
 TouchList.item()
 
 https://bugs.webkit.org/show_bug.cgi?id=65750
 
 AudioBufferSourceNode.noteOn()
 AudioBufferSourceNode.noteGrainOn()
 AudioBufferSourceNode.noteOff()
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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