[webkit-dev] Unsubscribe

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

Re: [webkit-dev] Rename LayoutTests

2017-05-09 Thread 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,

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Rename LayoutTests

2017-05-09 Thread 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.

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Rename LayoutTests

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

[webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Exporting WPT tests

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

Re: [webkit-dev] Exporting WPT tests

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

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

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[webkit-dev] Proposal: Remove Vibration API

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

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

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

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

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

Re: [webkit-dev] Another WPT bite

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

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

2017-05-09 Thread Michael Catanzaro
Hi, Consider this function: static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event) { switch (event) { case WebCore::AutoplayEvent::DidEndMediaPlaybackWithoutUserInterference: return

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] User agent woes

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

Re: [webkit-dev] User agent woes

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

Re: [webkit-dev] User agent woes

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Clang tidy

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Another WPT bite

2017-05-09 Thread 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,