Re: [webkit-dev] Rename LayoutTests

> On May 9, 2017, at 10:43 PM, Dan Bernstein wrote: > > >> 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 advan

[webkit-dev] Unsubscribe

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://li

Re: [webkit-dev] Rename LayoutTests

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 m

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Rename LayoutTests

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: > Integ

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] Rename LayoutTests

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 T

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Rename LayoutTests

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

Re: [webkit-dev] Rename LayoutTests

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 t

[webkit-dev] Rename LayoutTests

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 WebCor

Re: [webkit-dev] Exporting WPT tests

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

Re: [webkit-dev] Exporting WPT tests

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 i

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

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 value

Re: [webkit-dev] Another WPT bite

> 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

Re: [webkit-dev] Another WPT bite

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:4

Re: [webkit-dev] Another WPT bite

Forgot to CC webkit-dev. - R. Niwa On Tue, May 9, 2017 at 12:43 PM, Ryosuke Niwa wrote: > On Tue, 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

Re: [webkit-dev] Another WPT bite

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 everyth

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

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

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

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

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

> 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

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

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

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

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

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 (presu

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

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: r

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

> 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

[webkit-dev] Proposal: Remove Vibration API

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

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

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

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

Re: [webkit-dev] Another WPT bite

> On May 9, 2017, at 11:10 AM, Maciej Stachowiak wrote: > >> 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

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

> 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::DidEndMediaPlaybackWithoutUserInterfe

Re: [webkit-dev] Another WPT bite

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

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

Hi, Consider this function: static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event) { switch (event) { case WebCore::AutoplayEvent::DidEndMediaPlaybackWithoutUserInterference: return kWKAutoplayEventDidEndMediaPlaybackWithoutU

Re: [webkit-dev] Another WPT bite

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

Re: [webkit-dev] User agent woes

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

Re: [webkit-dev] User agent woes

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.

Re: [webkit-dev] User agent woes

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

Re: [webkit-dev] Another WPT bite

> Another concern is the ease of running tests for developers: drag&dropping > 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/testharne

Re: [webkit-dev] Another WPT bite

> > > 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/pro

Re: [webkit-dev] Another WPT bite

> 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

> 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

Re: [webkit-dev] Clang tidy

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