[webkit-dev] Unsubscribe

[Peter Frane]

I've been trying to to retrieve my password but the "remind" button here does 
not work: https://lists.webkit.org/mailman/options/webkit-dev


I need my password to unsubscribe.


Thanks.

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

Re: [webkit-dev] Rename LayoutTests

[Ryosuke Niwa]

On Tue, May 9, 2017 at 10:23 PM, Maciej Stachowiak  wrote:
>
>
>> On May 9, 2017, at 9:07 PM, Michael Catanzaro  wrote:
>>
>> On Tue, May 9, 2017 at 11:01 PM, Maciej Stachowiak  wrote:
>>> How about just Tests?
>>> Or alternately, RegressionTests. But I like just plain Tests.
>>
>> Then we should move ManualTests
>
> I'd be in favor of burying this somewhere deeper. As it is, people are still 
> adding tests here, which is kind of a disaster. These tests are very rarely 
> run, so a manual test is often barely better than no test at all. We should 
> also put a file in this directory strongly discouraging the addition of new 
> manual tests IMO.
>
>> , PerformanceTests,
>
> Could be renamed Benchmarks.

I'm not sure benchmarks would be a good description given that
directory also contains perf tests that are written to test specific
feature like line layout and DOM bindings.

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

This used to be the case but it got moved out of JavaScriptCore in
https://trac.webkit.org/changeset/203972 to be aligned with
LayoutTests and ManualTests and ease the pain of grep'ing
Source/JavaScriptCore, which used to find a whole bunch of things
inside Source/JavaScriptCote/Tests

>> TestWebKitAPI
>
> That might be reasonable for TestWebKitAPI/Tests but probably not 
> TestWebKitAPI itself, since the part other than the tests is a harness like 
> WebKitTestRunner. And I'm not sure it's practical to move just the tests. 
> It's probably easier to have them contained inside the tool in the source 
> tree.
>
> Also this is a weird mix of native code tests of public APIs for different 
> frameworks, and native code unit tests for some internal classes (mostly 
> low-level data structures).
>
> If these didn't need to be linked into a single tool, I might suggest that 
> each framework should contain its own units and API tests.

I'm not sure if that would be a good idea for the same reason JSTests
got moved out of Source/JavaScriptCore. Chromium use a similar
directory structure where tests are located next to code, and I find
that to be extremely annoying when grep'ing the code because I end up
finding a whole bunch of code in tests while looking for some keyword.

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

>> underneath it, because it would be weird to have tests outside of the Tests 
>> directory. Right?
>>
>> And then we would probably want to move all the layout tests to a new 
>> subdirectory, to separate them from the ManualTests, PerformanceTests, 
>> JSTests, and API tests. Then we have to find a name that subdirectory
>
> If we did add any special directories to Tests with different semantics, they 
> could just be special directories that are peers to the others, much like the 
> http/ directory.
>
> What are now called LayoutTests have the distinction (along with 
> PerformanceTests) of being tests that can cover things up and down the stack. 
> Most other tests could be assigned to one of the subdirectories of Source.

This is why I think IntegrationTests or FunctionalTests most
accurately describe these tests.

> But I'd also be ok with having special subdirectories under Source.

I'd be strongly against that approach given my prior experience
working with (sub-)projects which used that structure including but
not limited to JavaScriptCore, webkitpy, and Chromium.

> BTW we also have:
>  bindings tests (under WebCore/bindings/scripts/tests)
>  perl tests (under Tools)
>  python tests (under Tools)
>  builtins-generator-tests (not sure what or where these are)
>  dashboard-tests (also not sure what or where these are)
>
> In general, I think it's good for more specific kinds of tests like this to 
> be next to their relevant code.

I think these are small enough that they don't suffer from the same
issue of making grep'ing much harder although I've found binding tests
to be annoying for the same reason.

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

Re: [webkit-dev] Rename LayoutTests

[Dan Bernstein]

> On May 9, 2017, at 10:23 PM, Maciej Stachowiak  wrote:
> 
>> JSTests, and
> 
> Could go under JavaScriptCore, since these by design don't test anything 
> outside of JavaScriptCore.

There is an advantage to Apple’s internal production build system in keeping 
large amounts of test content out of projects’ source directories (which is why 
we moved it out of JavaScriptCore in 
https://bugs.webkit.org/show_bug.cgi?id=160180 
), but if that’s the preferred 
directory layout, then we can make some project changes to accommodate the 
aforementioned build system.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename LayoutTests

[Manuel Rego Casasnovas]

On 10/05/17 04:23, Ryosuke Niwa wrote:
> Continuing the tradition of a massive rename in
> https://lists.webkit.org/pipermail/webkit-dev/2012-August/021746.html,
> I suggest we rename the top-level LayoutTests directory to something
> more descriptive of the current state.
> 
> Some ideas:
> IntegrationTests - Represents what they are for WebCore.
> AutomatedTests - As opposed to ManualTests.
> ContentTests - Not great for tab completion.
> WebTests - Probably a bad idea for tab completion.

The very same discussion is happening right now on blink-dev:
https://groups.google.com/a/chromium.org/d/topic/blink-dev/KKNbuzj-3HY/discussion

A document with some ideas and pros/cons of each one:
https://docs.google.com/document/d/1wLSfod8apDy2sZsmXpTLRacfjweXP86C-V0wx5koJBg/edit

BTW, on a first sight I like "WebTests/" or even "Tests/".

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

Re: [webkit-dev] Rename LayoutTests

[Maciej Stachowiak]

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

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

> , PerformanceTests,

Could be renamed Benchmarks.

> JSTests, and

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

> TestWebKitAPI

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

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

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

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

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

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

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

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

Regards,
MAciej

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

Re: [webkit-dev] Another WPT bite

[youenn fablet]

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

Agreed that some tests, especially the ones dedicated to WebKit
specificities should be kept in WebKit.
The risk is that these changes might be changed upstreamed in
small/stylistic ways and no longer cover the initial case.

That does not prevent to use WPT infrastructure for these tests, especially
if it eases authoring.
As a temporary measure, Chris mentioned the possibility to have inside the
WPT folder a folder dedicated to "to-be-upstreamed" tests.


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

This is an issue in WebKit repository as well.
I saw some clean-up done in WPT though.
Sharing this goal and effort amongst the different communities might end up
with a better result.
Note also that spec editors are usually involved in WPT, which might help
organizing the test suites in better ways.


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

Re: [webkit-dev] Rename LayoutTests

[Michael Catanzaro]

On Tue, May 9, 2017 at 11:01 PM, Maciej Stachowiak  
wrote:

How about just Tests?

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


Then we should move ManualTests, PerformanceTests, JSTests, and 
TestWebKitAPI underneath it, because it would be weird to have tests 
outside of the Tests directory. Right?


And then we would probably want to move all the layout tests to a new 
subdirectory, to separate them from the ManualTests, PerformanceTests, 
JSTests, and API tests. Then we have to find a name that 
subdirectory


Michael

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

Re: [webkit-dev] Rename LayoutTests

[Ryosuke Niwa]

On Tue, May 9, 2017 at 9:01 PM, Maciej Stachowiak  wrote:
> How about just Tests?
>
> Or alternately, RegressionTests. But I like just plain Tests.

But we also have JSTests, ManualTests, and PerformanceTests so I think
it's nice to convey that what they're testing. e.g. WebContentTests
would work but that's not great for tab completion.

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

Re: [webkit-dev] Rename LayoutTests

[Maciej Stachowiak]

How about just Tests?

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

> On May 9, 2017, at 8:51 PM, Michael Catanzaro  wrote:
> 
>> On Tue, May 9, 2017 at 9:23 PM, Ryosuke Niwa  wrote:
>> AutomatedTests - As opposed to ManualTests.
> 
> The API tests under Tools/TestWebKitAPI (which never seemed to me like a good 
> location for tests) are also automated, so this doesn't seem like the best 
> name unless we want to move the API tests there too.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename LayoutTests

[Michael Catanzaro]

On Tue, May 9, 2017 at 9:23 PM, Ryosuke Niwa  wrote:

AutomatedTests - As opposed to ManualTests.


The API tests under Tools/TestWebKitAPI (which never seemed to me like 
a good location for tests) are also automated, so this doesn't seem 
like the best name unless we want to move the API tests there too.


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

[webkit-dev] Rename LayoutTests

[Ryosuke Niwa]

Hi,

Continuing the tradition of a massive rename in
https://lists.webkit.org/pipermail/webkit-dev/2012-August/021746.html,
I suggest we rename the top-level LayoutTests directory to something
more descriptive of the current state.

Some ideas:
IntegrationTests - Represents what they are for WebCore.
AutomatedTests - As opposed to ManualTests.
ContentTests - Not great for tab completion.
WebTests - Probably a bad idea for tab completion.

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

Re: [webkit-dev] Exporting WPT tests

[Ryosuke Niwa]

On Fri, Apr 28, 2017 at 8:24 AM, Mike Pennisi  wrote:
> Hi Youenn. My name is Mike, and I've been working with Google for the past 4
> months or so to improve various aspects of the Web Platform Tests project
> (more
> on that here [1]).
>
>> The only constraint I know of is that the test does not give flaky tests
>> from
>> WPT Chrome/Firefox bots.
>
> The full set of validation steps are described in the project's
> `.travis.yml`
> file [2]. That's a bit tough to read even if you're familiar with TravisCI
> (we're
> working on it!), but from WebKit's perspective, the only other relevant
> check
> is for file linting. It's not very opinionated (mostly limited to objective
> concerns) but still something to be aware of.

We can probably integrate W3C's lint into our style checker.

> I'm wondering if we can avoid duplicating effort by making a standalone
> tool.
> It might even be the kind of thing we could host in the W3C GitHub
> organization--whose to say that Edge (for example) wouldn't benefit from
> that,
> too? I would love to be involved in that implementation.

That would be fantastic. I suppose each vendor can configure the
scripts for their own needs?

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

Re: [webkit-dev] Exporting WPT tests

[Mike Pennisi]

Jeff has just created a document to explore what this tool might look like:

https://bugs.chromium.org/p/chromium/issues/detail?id=691653#c3

Youenn, this sounds like it's right up your alley!

On Fri, Apr 28, 2017 at 11:44 AM, youenn fablet  wrote:
> Hi Mike,
>
> Thanks for the information.
> It is really great to see Safari be integrated in the bots :)
> https://cs.chromium.org/chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/w3c/wpt_github.py
> seems like a really good potential candidate for WPT upstream.
> y
>
> Le ven. 28 avr. 2017 à 08:25, Mike Pennisi  a écrit :
>>
>> Hi Youenn. My name is Mike, and I've been working with Google for the past
>> 4
>> months or so to improve various aspects of the Web Platform Tests
>> project (more
>> on that here [1]).
>>
>>  > The only constraint I know of is that the test does not give flaky
>> tests from
>>  > WPT Chrome/Firefox bots.
>>
>> The full set of validation steps are described in the project's
>> `.travis.yml`
>> file [2]. That's a bit tough to read even if you're familiar with
>> TravisCI (we're
>> working on it!), but from WebKit's perspective, the only other relevant
>> check
>> is for file linting. It's not very opinionated (mostly limited to
>> objective
>> concerns) but still something to be aware of.
>>
>> Also note that we're very close to including both Edge and Safari in the
>> set of
>> browsers used to identify flaky tests! [3]
>>
>>
>>  > We do not have yet the tooling to automate the creation of a WPT
>> GitHub PR
>>  > from a WebKit patch that lands.
>>
>> I've recently been migrating tests for Service Workers from the Chromium
>> project to WPT. The process in place there is pretty slick. (Context for
>> other
>> folks on the list: it's able to create commits that exclude
>> Chromium-specific
>> files [4] and then submit GitHub pull requests from those, merging when CI
>> passes [5]. The patch Youenn mentioned is based on those files.)
>>
>> I'm wondering if we can avoid duplicating effort by making a standalone
>> tool.
>> It might even be the kind of thing we could host in the W3C GitHub
>> organization--whose to say that Edge (for example) wouldn't benefit from
>> that,
>> too? I would love to be involved in that implementation.
>>
>> But I'm getting ahead of myself :) I've CC'd Jeff Carp and Quinten
>> Yearsley of
>> the Chromium team since they are currently working with that tooling.
>>
>> So what do you folks think? Would it be practical to share code like this?
>>
>> [1] https://bocoup.com/blog/diving-into-the-web-platform-tests
>> [2] https://github.com/w3c/web-platform-tests/blob/master/.travis.yml
>> [3] https://github.com/w3c/web-platform-tests/pull/5231
>> [4]
>>
>> https://cs.chromium.org/chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/w3c/chromium_commit.py
>> [5]
>>
>> https://cs.chromium.org/chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/w3c/wpt_github.py
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Tue, May 9, 2017 at 12:11 PM, Maciej Stachowiak  wrote:
>
>
>> On May 9, 2017, at 11:35 AM, Michael Catanzaro  wrote:
>>
>> On Tue, May 9, 2017 at 1:13 PM, Maciej Stachowiak  wrote:
>>> I think this second option may suppress the warning when you have forgotten 
>>> to list one of the enum values, since there is now a default case. I 
>>> believe that's the reason for the recommended option.
>>
>> Ah, good point. Normally we do want a warning when a new enum value has been 
>> introduced. That could be avoided by this variant:
>>
>>  static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>>  {
>>  switch (event) {
>>  // ...
>>  }
>>
>>  RELEASE_ASSERT_NOT_REACHED();
>>  }
>>
>> That seems nicer than this:
>>
>>  static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>>  {
>>  switch (event) {
>>  // ...
>>  }
>>
>>  ASSERT_NOT_REACHED();
>>  return static_cast(0);
>>  }
>

One annoying thing is that I've seen clang complaining about that
return statement being an unreachable statement while gcc doesn't :(.
So we probably shouldn't have return statement, not to mention that 0
may not be a valid enum value.

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

Re: [webkit-dev] Another WPT bite

[Mike Pennisi]

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

While many tests can probably be run in this way, many others are dependent
on the functionality of the Web Platform Test Server. It's written in Python
and supports (among other things) arbitrary HTTP request handling via
standalone Python scripts. Its capabilities are documented here:

https://wptserve.readthedocs.io/en/latest/

Like with `testharness.js`, this additional infrastructure is a case of
"simplicity versus power."

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

This is a good point. I'm currently migrating service worker tests from
Chromium to WPT, and I'm frequently coming across tests (or sometimes
specific assertions) that aren't appropriate for WPT.

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

This gets at another consideration that hasn't been mentioned yet:
participating in WPT like this expands the responsibilities of authors and
reviewers.  Contributors may have to spend extra time cataloging their new
tests (or finding the correct test to extend). Likewise, reviewers will need
to develop some familiarity with certain sub-directories of WPT.

This can be kind of a drag, but only if you aren't committed to the
long-term benefits of sharing tests. From that perspective, meaningful
organization is just another part of the job, and the value accrues with
every new test.

Which is all to say: buy-in is important. If the team decides to participate in
WPT, folks ought to be excited about it!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Ryosuke Niwa]

Forgot to CC webkit-dev.
- R. Niwa


On Tue, May 9, 2017 at 12:36 PM, Ryosuke Niwa  wrote:
> On Tue, May 9, 2017 at 1:12 AM, Maciej Stachowiak  wrote:
>>
>>
>> On May 8, 2017, at 11:15 PM, Ryosuke Niwa  wrote:
>>
>> On Mon, May 8, 2017 at 11:01 PM, Brady Eidson  wrote:
>>
>> On May 8, 2017, at 10:44 PM, Ryosuke Niwa  wrote:
>> On Mon, May 8, 2017 at 10:17 PM, Brady Eidson  wrote:
>>
>> But now talking about testharness.js directly, I object on the grounds of "a
>> file:// regression test is dirt easy to hack on and work with, whereas
>> anything that requires me to have an httpd running is a PITA"
>>
>> I think whether we use file:// or http:// is orthogonal point to using
>> testharness.js.  Many of the tests Chris and I have written using
>> testharness.js are checked into regular LayoutTests/ directories, and
>> they work just fine.
>>
>> Yes, I misunderstood this in Youenn's original message. Good to know!
>>
>> I just object to making it the "recommended way" of writing tests.
>>
>> Would you equally object to making js-test.js / js-test-pre.js the
>> recommended way of writing tests?
>>
>> Yes.
>>
>> If not, why?
>>
>> N/A
>>
>> What we're suggesting is to give preferential treatments to
>> testharness.js over js-test.js / js-test-pre.js when you were already
>> planning to write a test with the latter two scripts.
>>
>> "It's okay to write your test however you'd like. If you were considering
>> using js-test, maybe you should consider using testharness instead."
>> Is that's what's being proposed?
>>
>>
>> On May 8, 2017, at 10:44 PM, Ryosuke Niwa  wrote:
>>
>> On Mon, May 8, 2017 at 10:17 PM, Brady Eidson  wrote:
>>
>> But now talking about testharness.js directly, I object on the grounds of "a
>> file:// regression test is dirt easy to hack on and work with, whereas
>> anything that requires me to have an httpd running is a PITA"
>>
>>
>> I think whether we use file:// or http:// is orthogonal point to using
>> testharness.js.  Many of the tests Chris and I have written using
>> testharness.js are checked into regular LayoutTests/ directories, and
>> they work just fine.
>>
>>
>> Yes, I misunderstood this in Youenn's original message. Good to know!
>>
>>
>> I just object to making it the "recommended way" of writing tests.
>>
>>
>> Would you equally object to making js-test.js / js-test-pre.js the
>> recommended way of writing tests?
>>
>>
>> Yes.
>>
>> If not, why?
>>
>>
>> N/A
>>
>> What we're suggesting is to give preferential treatments to
>> testharness.js over js-test.js / js-test-pre.js when you were already
>> planning to write a test with the latter two scripts.
>>
>>
>> "It's okay to write your test however you'd like. If you were considering
>> using js-test, maybe you should consider using testharness instead."
>>
>> Is that's what's being proposed?
>>
>>
>> Besides other issues mentioned, testharness tends to result in more verbose
>> tests compared to js-test, at least for simple cases.
>>
>>
>> The thing I specifically asked Youenn to ask is, whether we should
>> place a test inside LayoutTests/wpt like LayoutTests/http/tests when
>> we want to write a test using testharness.js which requires some sort
>> of network code.
>>
>> Since people have had some opinions about directory structures in the past.
>>
>>
>> It seems like we need a few different directories, here are my opinions on
>> them:
>>
>> (1) Imported web platform tests that don't need a server
>> Currently LayoutTests/imported/w3c/web-platform-tests, which seems fine.
>> (2) Imported web platform tests that do need a server
>> Probably should be under LayoutTests/imported/w3c/ somewhere, or maybe
>
> I don't think it's a good idea to split web-platform-tests into two
> separate directories like that because I'd imagine there are resource
> dependencies between tests.  Note that this whole process of detecting
> & separating tests that can be ran locally is the work we'd have to
> do, and upstream won't maintain it.  Given that, we should be making
> the minimal amount of differences to the upstream directory structure
> as well.
>
> Granted, this would make it harder to know which tests require a
> server and which one doesn't. Perhaps this is bad enough that we need
> two directories after all but perhaps there is some other way to solve
> this problem like adding suffix to test names. (Although some ref
> tests in web-platform-tests use other tests as expectation but ref
> tests don't tend to require servers anyway; I know this is a terrible
> idea but we don't really have a control over what upstream does).
>
>> under http/tests/ per point (4)
>> (3) Custom testharness.js tests that don't need a server
>> Probably these should just go in their normal topic-specific directories
>> and should not need a special directory
>> (4) Custom testharness.js tests that do 

Re: [webkit-dev] Another WPT bite

[Ryosuke Niwa]

On Tue, May 9, 2017 at 11:06 AM, Maciej Stachowiak 
>
> If we run all the w3c-imported web platform tests under a web server, then
> obviously we only need one directory. My understanding is that we don't run
> them under a server at all. So it seems like one part of this proposal is
> "run everything under LayoutTests/imported/w3c/ from a web server".

We currently run all web-platform-tests using WPT server. In theory,
there's nothing preventing us from running these tests using file://
so long as tests don't rely on the networking aspect. However, we
don't currently rewrite URLs to testharness.js and
testharness-report.js both of which refers to the top-level directory
at the moment.

IMO, the entirety of the effort to make these imported tests runnable
in file scheme should be about re-enabling these URL rewrites that got
broken sometime ago.

>
> I think it would be cleaner to have a separate directory of tests intended
> for import, separate from imported tests.

You mean intended for exports?
> It could be right next to imported/w3c/web-platform-tests. I think mixing 
> tests that are imported from
> upstream and tests intended for eventual upstreaming is more confusing than
> helpful.

Okay. I've actually advocated for this approach for the same reason.

One annoying thing in this approach is that if we wanted to add a test
to, say, html/infrastructure/conformance-requirements/extensibility/
then we either have to mirror the same directory structure in this
upstream directory, or add some sort of WebKit-only annotation that
this test needs to be added there for the upstream process to be
automated.

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

No. Most of web-platform-tests that do require HTTP access have an
accompanying Python file which use WPT server's functionality as far
as I know.

In fact, I'd even argue that we should try to use the WPT server for
writing tests for Web APIs and security checks since those tests would
be extremely valuable for other browser vendors as well.

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

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

[Alex Christensen]

I like switch statements without defaults when possible because if someone adds 
another enum value, it causes compiler warnings/errors and forces us to update 
all necessary code.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Remove Vibration API

[Ryosuke Niwa]

On Tue, May 9, 2017 at 11:39 AM, Joseph Pecoraro  wrote:
> There is code in the tree for the Vibration API guarded by
> ENABLE(VIBRATION). I propose we remove it:
>  Remove Vibration API
>
> There have been concerns that the Vibration API can be used for
> fingerprinting and has the potential for abuse by web content:
> 
> 
>
> Currently this feature is not enabled by any port, so it is unmaintained.
> Generally that would be enough to remove the code unless a port wishes to
> enable and maintain the feature.
>
> Does any port intend to enable and maintain this feature?

I think only EFL port used this feature so it's safe to remove it from
trunk now.

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

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

[Maciej Stachowiak]

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

Some possible reasons:

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

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

Re: [webkit-dev] Proposal: Remove Vibration API

[Michael Catanzaro]

On Tue, May 9, 2017 at 1:39 PM, Joseph Pecoraro  
wrote:

Does any port intend to enable and maintain this feature?


I don't think either WPE or GTK are interested in vibration API.

I'm sure someone will quickly contradict me here if I'm wrong.

Michael

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

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

[Maciej Stachowiak]

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

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

Regards,
Maciej

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

[webkit-dev] Reminder: be careful when printing sized integer types

[Michael Catanzaro]

Hi,

This is just a reminder to avoid a case that occasionally causes 
warnings for GTK+. On Mac, uint64_t is (I assume) a typedef for 
unsigned long long. But on Linux 86_64 it's a typedef for unsigned 
long. This means they have to be printed differently. Using "%llu" to 
print a uint64_t (presumably) works on Mac, but it causes compiler 
warnings on Linux. The right way is unfortunately to use "%" PRIu64, 
which expands to "%llu" on Mac and "%lu" on Linux. There are variants 
on these macros for many different integer types: 
http://en.cppreference.com/w/cpp/types/integer


It's verbose, but helps us avoid warnings. And since it's declared in 
stdint.h/cstdint, if you're using uint64_t then it's already available.


Thanks,

Michael

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

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

[Alfonso Guerra]

On May 9, 2017 2:07 PM, "Michael Catanzaro"  wrote:

Hi,

Consider this function:

   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent
event)
   {
   switch (event) {
   case WebCore::AutoplayEvent::DidEndMediaPlaybackWithoutUserInterf
erence:
   return kWKAutoplayEventDidEndMediaPla
ybackWithoutUserInterference;
   case WebCore::AutoplayEvent::DidPlayMediaPreventedFromPlaying:
   return kWKAutoplayEventDidPlayMediaPreventedFromAutoplaying;
   case WebCore::AutoplayEvent::DidPreventMediaFromPlaying:
   return kWKAutoplayEventDidPreventFromAutoplaying;
   case WebCore::AutoplayEvent::UserDidInterfereWithPlayback:
   return kWKAutoplayEventUserDidInterfereWithPlayback;
   case WebCore::AutoplayEvent::UserNeverPlayedMediaPreventedFromPla
ying:
   return kWKAutoplayEventUserNeverPlaye
dMediaPreventedFromPlaying;
   }
   }



Out of curiosity, why is using a switch statement better than defining an
array to hold the return values?




Alfonso Guerra
Founder/CEO
Apokalypse Software Corp
@Huperniketes
(626) 667-4285


It will trigger this GCC warning:

[3490/4357] Building CXX object Source...bKit2.dir/UIProcess/A
PI/C/WKPage.cpp.o
../../Source/WebKit2/UIProcess/API/C/WKPage.cpp: In static member function
‘static WKAutoplayEvent WKPageSetPageUIClient(WKPageRef, const
WKPageUIClientBase*)::UIClient::toWKAutoplayEvent(WebCore::AutoplayEvent)’:
../../Source/WebKit2/UIProcess/API/C/WKPage.cpp:2277:9: warning: control
reaches end of non-void function [-Wreturn-type]
}
^

Such functions are very common in WebKit. What should be our preferred
idiom for suppressing this warning?

https://bugs.webkit.org/show_bug.cgi?id=171851 suggests this approach:

   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent
event)
   {
   switch (event) {
   // ...
   }

   ASSERT_NOT_REACHED();
   return 0;
   }

That works for the cases in that bug, but it won't work in this case,
because the return value here is an enum, so a cast would be needed.

I've been putting a RELEASE_ASSERT_NOT_REACHED() in the default case:

   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent
event)
   {
   switch (event) {
   // ...
   default:
   RELEASE_ASSERT_NOT_REACHED();
   }
   }

Of course, that would work just as well coming after the switch. This is
more general as it works for enums, but RELEASE_ASSERT_NOT_REACHED() is a
bunch of typing. I've seen CRASH() used frequently as well, but what's the
point of having RELEASE_ASSERT_NOT_REACHED() at all if we are using CRASH()
directly?

Opinions?

Bugs to close once we've decided how to handle this:

https://bugs.webkit.org/show_bug.cgi?id=171851
https://bugs.webkit.org/show_bug.cgi?id=171866
https://bugs.webkit.org/show_bug.cgi?id=171867

Michael

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

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

[Andy Estes]

> On May 9, 2017, at 11:35 AM, Michael Catanzaro  wrote:
> 
> Andy suggests returning one of the enumeration values directly, then we can 
> use ASSERT_NOT_REACHED() instead of RELEASE_ASSERT_NOT_REACHED(). That would 
> work too, though it forces me to think about which one to pick.

You had to think about that for static_cast(0) as well, though. 0 might 
not be one of the enumerated values, for instance.

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

[webkit-dev] Proposal: Remove Vibration API

[Joseph Pecoraro]

There is code in the tree for the Vibration API guarded by ENABLE(VIBRATION). I 
propose we remove it:
 Remove Vibration API

There have been concerns that the Vibration API can be used for fingerprinting 
and has the potential for abuse by web content:
>
>

Currently this feature is not enabled by any port, so it is unmaintained. 
Generally that would be enough to remove the code unless a port wishes to 
enable and maintain the feature.

Does any port intend to enable and maintain this feature?

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

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

[Andy Estes]

> On May 9, 2017, at 11:06 AM, Michael Catanzaro  wrote:
> 
> https://bugs.webkit.org/show_bug.cgi?id=171851 
>  suggests this approach:
> 
>   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>   {
>   switch (event) {
>   // ...
>   }
> 
>   ASSERT_NOT_REACHED();
>   return 0;
>   }
> 
> That works for the cases in that bug, but it won't work in this case, because 
> the return value here is an enum, so a cast would be needed.

You wouldn’t need a cast if you returned one of the enumeration values (say, 
the first one) instead of 0.

I prefer this option for the reason Maciej gave.

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

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

[Maciej Stachowiak]

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

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

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

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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

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

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

Regards,
Maciej

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

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

[Michael Catanzaro]

Hi,

Consider this function:

   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent 
event)

   {
   switch (event) {
   case 
WebCore::AutoplayEvent::DidEndMediaPlaybackWithoutUserInterference:
   return 
kWKAutoplayEventDidEndMediaPlaybackWithoutUserInterference;
   case 
WebCore::AutoplayEvent::DidPlayMediaPreventedFromPlaying:
   return 
kWKAutoplayEventDidPlayMediaPreventedFromAutoplaying;

   case WebCore::AutoplayEvent::DidPreventMediaFromPlaying:
   return kWKAutoplayEventDidPreventFromAutoplaying;
   case WebCore::AutoplayEvent::UserDidInterfereWithPlayback:
   return kWKAutoplayEventUserDidInterfereWithPlayback;
   case 
WebCore::AutoplayEvent::UserNeverPlayedMediaPreventedFromPlaying:
   return 
kWKAutoplayEventUserNeverPlayedMediaPreventedFromPlaying;

   }
   }

It will trigger this GCC warning:

[3490/4357] Building CXX object 
Source...bKit2.dir/UIProcess/API/C/WKPage.cpp.o
../../Source/WebKit2/UIProcess/API/C/WKPage.cpp: In static member 
function ‘static WKAutoplayEvent WKPageSetPageUIClient(WKPageRef, 
const 
WKPageUIClientBase*)::UIClient::toWKAutoplayEvent(WebCore::AutoplayEvent)’:
../../Source/WebKit2/UIProcess/API/C/WKPage.cpp:2277:9: warning: 
control reaches end of non-void function [-Wreturn-type]

}
^

Such functions are very common in WebKit. What should be our preferred 
idiom for suppressing this warning?


https://bugs.webkit.org/show_bug.cgi?id=171851 suggests this approach:

   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent 
event)

   {
   switch (event) {
   // ...
   }

   ASSERT_NOT_REACHED();
   return 0;
   }

That works for the cases in that bug, but it won't work in this case, 
because the return value here is an enum, so a cast would be needed.


I've been putting a RELEASE_ASSERT_NOT_REACHED() in the default case:

   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent 
event)

   {
   switch (event) {
   // ...
   default:
   RELEASE_ASSERT_NOT_REACHED();
   }
   }

Of course, that would work just as well coming after the switch. This 
is more general as it works for enums, but RELEASE_ASSERT_NOT_REACHED() 
is a bunch of typing. I've seen CRASH() used frequently as well, but 
what's the point of having RELEASE_ASSERT_NOT_REACHED() at all if we 
are using CRASH() directly?


Opinions?

Bugs to close once we've decided how to handle this:

https://bugs.webkit.org/show_bug.cgi?id=171851
https://bugs.webkit.org/show_bug.cgi?id=171866
https://bugs.webkit.org/show_bug.cgi?id=171867

Michael

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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

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

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

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

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

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

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

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

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

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

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

Regards,
Maciej


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

Re: [webkit-dev] User agent woes

[Michael Catanzaro]

On Tue, May 9, 2017 at 12:34 PM, Konstantin Tokarev  
wrote:
Maybe they just assume this traffic is coming from bots, and this 
conflict
can be resolved by simply informing them about existence of other 
WebKit

ports?


I think we should not contact sites that present unsupported browser 
warnings, like Whatsapp. Their interest is in ensuring that users don't 
use browsers they haven't tested, and there is no question they're 
doing it intentionally, because that's exactly what their big "use 
another browser" landing page says. If many sites start doing this, 
that could put us out of business, and would be a huge problem for 
embedded device manufacturers. It's better for us to just not say 
anything, so long as our quirk continues to work. That said, testing 
Whatsapp right now, it seems the user agent quirk is no longer enough: 
it's failing due to lack of WebCrypto support. That's an actual 
legitimate reason to block us, so OK. Maybe they have switched from 
user agent checks to feature checks. We should reevaluate if this quirk 
is still needed after enabling WebCrypto.


Testing Slack right now, it works perfectly fine with our standard user 
agent. I think this quirk can be removed.


Michael

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

Re: [webkit-dev] User agent woes

[Konstantin Tokarev]

08.05.2017, 06:12, "Michael Catanzaro" :
> Hi Maciej,
>
> I agree with basically everything you wrote, except I recommend not
> using OS X as the operating system string in the default user agent
> except when actually running on macOS. We tried this for about a year
> and got tons of complaints. It breaks more than it fixes: many websites
> decide to present only macOS versions of downloads and offer no
> recourse to get the right version of the download (like Hangouts), and
> other times it's just annoying, e.g. the OS field on Bugzilla defaults
> to OS X, which a substantial subset of bug reporters feel the need to
> complain about. So instead, we now add OS X quirks for websites when
> needed.
>
>>  You mentioned that for some sites, that wouldn't work. I think it's
>>  reasonable to have more specific exceptions just for those, and we
>>  can review them together. Specifically, for Google Hangouts, you
>>  mention that claiming to be Mac Safari will offer a non-working
>>  plugin. However, it looks like WebKitGTK+ pretends to be Linux
>>  Firefox for Google sites instead. It seems very likely that a Linux
>>  Firefox UA string would break Google Hangouts in Mac Safari for
>>  pretty much the same reason.
>
> Yes, you definitely can't send a Linux+Firefox UA string, as that would
> definitely break Hangouts for Safari users.
>
> But I bet you could send a macOS+Firefox UA string, until such time
> that Google fixes its websites to stop sending inferior pages to other
> WebKit browsers. That way, next time they decide to make a change based
> on UA that's going to cause other WebKit browsers to break, Safari
> should break as well and Google should notice before deploying the
> change if they test it at all. (Of course, this is only really needed
> if evangelism fails.)
>
>>  It's not clear to me what the issues are with typekit or slack, or
>>  why you claim to be Chrome instead of Mac Safari on those.
>
> I don't remember exactly why I came up with the Chrome quirk for these
> sites, but I usually try our macOS quirk first and use the Chrome quirk
> next if that fails. The macOS quirk is much safer as it does not
> encourage websites to try to use Chrome-specific JS.
>
> The issue with Typekit is that lots of websites use Typekit for web
> fonts, but Typekit disables itself unless it recognizes the user agent.
> Then users complain that fonts are wrong on a bunch of different
> websites. See https://bugs.webkit.org/show_bug.cgi?id=147296.
>
> Slack just doesn't work at all with our default UA, it displays only an
> unsupported browser page. It works perfectly fine with the UA changed.
>
>>   Maybe claiming to be Mac Safari would reduce future breakage. Or if
>>  not, it would be interesting to know what the issue is.
>>
>>  We may also be able to reach out to some of the problem websites or
>>  help you get contact info.
>
> This would be wonderful. I don't think it's worthwhile to reach out to
> websites like Slack and Whatsapp that are clearly intentionally trying
> to block our users: I'd rather them not realize that we are sending UA
> quirks at all, as they might try harder to block our users if so.

Any ideas why are they doing this?

Maybe they just assume this traffic is coming from bots, and this conflict
can be resolved by simply informing them about existence of other WebKit
ports?

> But
> in other cases, like with Google, we would really appreciate your help
> with evangelism. Let's continue this line of discussion via private
> mail.
>
> Thanks,
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] User agent woes

[Michael Catanzaro]

On Mon, May 8, 2017 at 3:40 PM, Maciej Stachowiak  wrote:
I see, so your Google UA string is a tricky balancing act between the 
weird needs of many sites.


Yup... using a Firefox UA is hardly our preference, it's just the only 
thing I've found that works. (Except with accounts.google.com. ;)


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

Re: [webkit-dev] Another WPT bite

[Geoffrey Garen]

> Another concern is the ease of running tests for developers: drag 
> tests into a browser instead of running a server.

Yeah, it’s a pretty big concern if you can’t just drop a simple test case into 
a browser.

> We can partially accommodate this by rewriting 
> testharness.js/testharnessreport.js urls.
> A significant and growing amount of wpt tests will not behave as expected 
> (other resources loaded, origins, need for specific headers, need for https…)

This might be a reason to prefer WPT tests when you know you’re testing 
something whose behavior depends on http. But in all other cases, the ability 
for a test to be a self-contained file that can run in any browser, upload to a 
bug tracker, and so on, is super valuable.

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

Re: [webkit-dev] Another WPT bite

[youenn fablet]

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

For synchronous tests, I am not sure there is any big difference one way or
the other.
With asynchronous tests, it might be true, but using
testharness.js/promise_test usually improves things there.
 I personally find it easier to not wrap code-to-be-tested into quotes.

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

The thing I specifically asked Youenn to ask is, whether we should
> place a test inside LayoutTests/wpt like LayoutTests/http/tests when
> we want to write a test using testharness.js which requires some sort
> of network code.
>
> Since people have had some opinions about directory structures in the past.
>
>
> It seems like we need a few different directories, here are my opinions on
> them:
>
> (1) Imported web platform tests that don't need a server
> Currently LayoutTests/imported/w3c/web-platform-tests, which seems
> fine.
>

All WPT tests are expected to run behind the WPT server.
That is the way tests are authored and tested elsewhere.
If we have an issue with that, it is best to bring that and fix that
directly in WPT.
I encountered several times small issues due to file:// based origins which
makes me think defaulting to http is a safe choice.

One concern is efficiency. We should study that and improve on that.
Another concern is the ease of running tests for developers: drag
tests into a browser instead of running a server.
We can partially accommodate this by rewriting
testharness.js/testharnessreport.js urls.
A significant and growing amount of wpt tests will not behave as expected
(other resources loaded, origins, need for specific headers, need for
https...)

(2) Imported web platform tests that do need a server
> Probably should be under LayoutTests/imported/w3c/ somewhere, or maybe
> under http/tests/ per point (4)
>

I don't think this will work, web-platform-tests is organized in terms of
features.
There is no clear separation between file based compatible tests and http
based tests like in WebKit.

(3) Custom testharness.js tests that don't need a server
> Probably these should just go in their normal topic-specific
> directories and should not need a special directory
>

Right.
The only case where it might make sense to put such tests in a specific
WPT-enabled directory is if the plan is to upstream these tests at some
point.
Such tests could be added in imported/w3c/web-platform-tests directly but
this requires coordination with resyncing tests at the moment.
In a not-too-far-future, I hope such tests would directly be authored in
imported/w3c/web-platform-tests.


> (4) Custom testharness.js tests that do need a server
> Can these just be a subdirectory of http/tests/? We have websocket and
> ssl/tls tests in there too. Would be nice to not need a separate directory
> for networking tests that to use a particular test framework.
>

I do not have strong feelings there, http/wpt might make sense if it is
found easier to understand to everybody.
I'll update the patch accordingly and will land it sometimes this week if
there is no additional feedback.

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

Re: [webkit-dev] Another WPT bite

[Geoffrey Garen]

> What we're suggesting is to give preferential treatments to
> testharness.js over js-test.js / js-test-pre.js when you were already
> planning to write a test with the latter two scripts.

OK, I think this makes sense.

But I still think the very best kind of test is a flat file with 10-20 lines of 
code in it. Particularly for debugging JavaScript issues, large wrapper 
frameworks get in the way.

> - Tests would be more easily upstreamable to web-platform-tests, which are 
> run by all major browser engines. This would help a lot in terms of 
> interoperability. As previously discussed, Gecko and Blink already do 
> automated export of tests to web-platform-tests. I believe we should do in 
> the same direction and contribute more tests back.

I wonder why these other projects do automated export instead of incorporating 
testharness.js directly.

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

Re: [webkit-dev] Another WPT bite

[Maciej Stachowiak]

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

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

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

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

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

Regards,
Maciej

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

Re: [webkit-dev] Clang tidy

[Maciej Stachowiak]

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

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

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

 - Maciej


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

Re: [webkit-dev] Another WPT bite

[Ryosuke Niwa]

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

The thing I specifically asked Youenn to ask is, whether we should
place a test inside LayoutTests/wpt like LayoutTests/http/tests when
we want to write a test using testharness.js which requires some sort
of network code.

Since people have had some opinions about directory structures in the past.

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

Re: [webkit-dev] Another WPT bite

[Brady Eidson]

> On May 8, 2017, at 10:44 PM, Ryosuke Niwa  wrote:
> 
> On Mon, May 8, 2017 at 10:17 PM, Brady Eidson  wrote:
> 
>> But now talking about testharness.js directly, I object on the grounds of "a
>> file:// regression test is dirt easy to hack on and work with, whereas
>> anything that requires me to have an httpd running is a PITA"
> 
> I think whether we use file:// or http:// is orthogonal point to using
> testharness.js.  Many of the tests Chris and I have written using
> testharness.js are checked into regular LayoutTests/ directories, and
> they work just fine.

Yes, I misunderstood this in Youenn's original message. Good to know!
> 
>> I just object to making it the "recommended way" of writing tests.
> 
> Would you equally object to making js-test.js / js-test-pre.js the
> recommended way of writing tests?

Yes.

> If not, why?

N/A

> What we're suggesting is to give preferential treatments to
> testharness.js over js-test.js / js-test-pre.js when you were already
> planning to write a test with the latter two scripts.

"It's okay to write your test however you'd like. If you were considering using 
js-test, maybe you should consider using testharness instead."

Is that's what's being proposed?

The WebKit project usually doesn't spend much time worrying about highly 
qualified non-binding suggestions. ;)

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