Re: [webkit-dev] Testing iOS/WK1?

[Ali Juma]

On Tue, Oct 23, 2018 at 11:39 AM Frédéric Wang  wrote:

> Hi all,
>
> During the WebKit Contributors Meeting, Simon Fraser suggested that I
> should verify some of the my patches using WK1. Hence I did some
> experiments (again):
>
> * When I run run-webkit-tests, whatever the value specified via
> --platform, the selected expectation is always a "wk2" file and the code
> executed is from WebKit (i.e. WK2 == non-legacy).
>

Try passing the argument "-1":

run-webkit-tests --ios-simulator -1
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Experimental and (new) Internal feature flags

[Ali Juma]

On Wed, Sep 12, 2018 at 5:48 PM Dean Jackson  wrote:

> I just added support for a new category of WebKit2 preference: internal
> debug.
>
> The motivating factor was that people were abusing experimental features
> to add flags for anything they wanted to toggle at runtime, even if our
> users would have no idea what it meant (nor should they ever toggle it).
> Internal features are not public-facing.
>
> My next task will be to remove the ability to set a default value for
> experimental features. They will default to be off (if it really is
> experimental, it shouldn't be on by default). This will apply even to tests
> - see below for how to turn them on at runtime inside WKTR.
>
> Documented here:
> https://trac.webkit.org/wiki/ExperimentalAndInternalFeatureFlags
>
> WebKit provides a way to expose a feature flag to a client application at
> runtime, and have that application toggle the feature. This lets us to
> start work on experimental features without fully exposing them to the Web,
> but allows Web developers to turn them on and test. There are two types of
> exposed features: Experimental and Internal Debug.
>
> The configuration file WebPreferences.yaml controls these features. Just
> set the category value to experimental or internal. Note that you should
> also provide a nice human-understandable description and name.
>
> These are only exposed by WebKit2. If you want your feature to be toggled
> via WebKit1 you'll have to manually add more code.
>
> Experimental Features
> 
>
> These features are designed for Web developers, and are exposed via
> Safari's Develop menu as well as MiniBrowser.
>
> Internal Debug Features
> 
>
> These features are designed for WebKit developers, and are exposed via
> Safari's secret-but-not-really Debug menu. We do not expect Web developers
> to change these settings. They are also exposed by MiniBrowser.
>
> Which should I use?
> 
>
> If a Web developer wouldn't understand what the feature is by name, or it
> is just for internal testing, then you should use an internal feature. For
> example, we don't want users to disable Service Workers, and almost no one
> would know what MDSN ICE Candidates are.
>
> What about testing?
> 
>
> You can turn both experimental and internal features on via headers in
> WebKitTestRunner. Use experimental:FeatureName or internal:FeatureName. For
> example...
>
> 
>

Is there a plan for how to handle web platform tests (where we can't add
such a header)?

Currently, WebKitTestRunner enables all experimental features in tests
(including those disabled by default), so adding an experimental feature
(even one that's disabled by default) is a convenient way to get web
platform test coverage for the feature. If WebKitTestRunner will no longer
do that, we'll need some other way to keep these tests running.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] IntersectionObserver implementation

[Ali Juma]

Hi webkit-dev,

In bug 159475 , there's
some WIP for implementing IntersectionObserver but there doesn't appear to
be any active work. I'd be interested in picking up that work if the WebKit
project is still interested in IntersectionObserver (and if no one is
actively working on it).

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

Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

[Ali Juma]

It's worth noting that https://bugs.webkit.org/show_bug.cgi?id=182629 added
back the OS version to the UA string, at least on trunk (the reasons given
there, in https://bugs.webkit.org/show_bug.cgi?id=182629#c6, sound exactly
like those mentioned by Colin in this thread).

On Thu, Apr 26, 2018 at 1:49 PM Colin Bendell | +1.613.914.3387 <
co...@bendell.ca> wrote:

> On 26 April 2018 at 13:18, Konstantin Tokarev  wrote:
> > 26.04.2018, 20:09, "Colin Bendell | +1.613.914.3387 <(613)%20914-3387>"
> :
> >> On 26 April 2018 at 12:23, Konstantin Tokarev 
> wrote:
> >>>  Not to mention those evil people who reject page loading for user
> agents
> >>>  they don't (want to) support
> >>
> >> How does locking the UA solve the misbehaving parsers in the wild?
> >
> > There will be less information in UA and therefore less reasons for
> developers
> > to do this, instead of using direct feature testing
> >
> >> They will still misbehave and break the user experience. However,
> >> those of us that are trying to optimize the user experience by working
> >> around bugs for specific versions are now handicapped and punished.
> >
> > While parsing UA string handicaps and punishes users of alternative user
> agents.
>
> Can you give me an example where UA parsing is punishing users of
> alternative user agents? Is this a theoretical problem, or a
> widespread problem? I'm not asking to be divisive, but because I know
> for a fact that UA parsing is improving the user experience. I can
> give you dozens of examples where we must resort to UA parsing for the
> betterment of the user (for all flavors of UAs).
>
> Do you have any alternatives other than "more javascript"?
>
> Again I ask, is there room for compromise where we can expose the
> version details in the UA (or some alternative) so that we ensure a
> consistent and optimized user experience?
>
> /colin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Visual Viewport API

[Ali Juma]

Hello webkit-dev,

I've started working on implementing the Visual Viewport API. This API
exposes properties of the visual viewport (the viewport that's affected by
pinch-zoom).

Spec:
https://wicg.github.io/visual-viewport/

Tracking bug:
https://bugs.webkit.org/show_bug.cgi?id=170982

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

Re: [webkit-dev] Remove Credential Management code

[Ali Juma]

Work on this has been stalled because of unresolved spec issues that came
up, specifically:
1) https://github.com/w3c/webappsec-credential-management/issues/96
2) https://github.com/w3c/webappsec-credential-management/issues/95
3) https://github.com/w3c/webappsec-credential-management/issues/94

Given that the spec will likely have to evolve in order to address those
issues, it doesn't seem unreasonable to remove the stubs for now and
possibly re-land modified versions of them later.

On Wed, Sep 6, 2017 at 12:29 PM Sam Weinig  wrote:

> Hey gang,
>
> I’d like to propose removing the Credential Management code from WebCore.
> Work began on supporting this spec in January of this year, but so far,
> only IDLs and stubs have been added.  In May, there was an effort to update
> the IDLs and stubs to the latest spec (https://webkit.org/b/172011) with
> the promise of continued work, but I don’t believe the further work took
> place.
>
> Does anyone have concrete plans to work on this in the short term? If not,
> I think it makes sense to remove it.
>
>
> Thanks,
> - Sam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ali Juma]

Hi all,

Just wanted to check what the current recommended approach is for new WPT
tests. Is it now ok to add new tests directly in
LayoutTests/imported/w3c/web-platform-tests and then upstream them, or
should tests still be added elsewhere first (in LayoutTests/http/wpt?),
upstreamed, and then moved into LayoutTests/imported/w3c/web-platform-tests?

Thanks,
Ali

On Sun, May 21, 2017 at 11:14 PM youenn fablet  wrote:

> Filed https://bugs.webkit.org/show_bug.cgi?id=172435 about that
>
>
> Le dim. 21 mai 2017 à 00:40, Maciej Stachowiak  a écrit :
>
>> On May 18, 2017, at 2:08 PM, Philip Jägenstedt  wrote:
>>
>> On Tue, May 16, 2017 at 5:38 PM youenn fablet  wrote:
>>
>>>
>>> There was a suggestion that LayoutTests/imported/w3c/web-platform-tests
>>> be moved to a shorter path like LayoutTests/web-platform-tests. That would
>>> also make it clear that this folder is not only about one-way-sync.
>>>
>>
>> In Blink we renamed it to LayoutTests/external/wpt/ to avoid the "read
>> only" implications of the old name.
>>
>>
>> If we go forward with two-way sync, I think this is a good name.
>>
>> Regards,
>> Maciej
>>
>>
>> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WPT tests and runtime-enabled features

[Ali Juma]

Hi all,

While a feature is in development behind a runtime-enabled flag, is there a
way to write tests in web-platform-tests that enable the feature when
they're run as part of LayoutTests? Adding "" tags would technically work but seems a bit
questionable.

The point of this would be to be able to use web platform tests as
regression tests while developing a feature, allowing the tests to be
upstreamed sooner and saving having to write them outside of
web-platform-tests first and then move them over later.

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