[webkit-dev] New reviewer: Mike Wyrzykowski

[Dean Jackson via webkit-dev]

Congratulations to Mike Wyrzykowski who is now a WebKit reviewer (github 
username: mwyrzykowski)!

Dean



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Jean-Yves is now a WebKit reviewer

[Dean Jackson via webkit-dev]

拾

Jean-Yves Avenard is now a WebKit reviewer. May the “merge-queue” label serve 
you well, Jean-Yves!

Dean

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

[webkit-dev] Tim Nguyen is now a WebKit reviewer

[Dean Jackson via webkit-dev]

Hi floks,

Tim Nguyen is now a WebKit reviewer! Congratulations Tim!

Dean

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

[webkit-dev] Kimmo Kinnunen is a WebKit Reviewer

[Dean Jackson via webkit-dev]

I'm happy to announce that Kimmo Kinnunen is now a WebKit Reviewer. 
Congratulations Kimmo!

Dean



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on Azimuth/Altitude for Pointer Events

[Dean Jackson]

Hi,

Since I was the originator of https://github.com/w3c/pointerevents/issues/274 
 I guess I should reply :)

Yes, we support this addition (and we already have an implementation on iOS, 
which we'll update if necessary).

Dean

> On 29 Jul 2020, at 04:30, Liviu Tinta  wrote:
> 
> Hello WebKit-dev,
> 
> I'd like to ask for Webkit's official position on adding Azimuth/Altitude to 
> Pointer Events as described in [1]. The proposal was discussed by the Pointer 
> Events Working Group and Pointer Events specification was updated [2]. The 
> discussion and specification update happened in [3], [4], [5], [6], [7], [8], 
> [9].
> Mozilla standards-position: 
> https://github.com/mozilla/standards-positions/issues/411 
> 
> TAG Review: https://github.com/w3ctag/design-reviews/issues/537 
>  
> 
> [1] Explainer: 
> https://docs.google.com/document/d/1BkJDlHJvR6jndtJys7IYuqwITgVi6P9iOnfA0z5Cu04/edit#heading=h.5irk4csrpu0y
>  
> 
> [2] Pointer Events : 
> https://w3c.github.io/pointerevents/#dom-pointerevent-altitudeangle 
> 
> [3] PE Issue 321:  https://github.com/w3c/pointerevents/issues/321 
> 
> [4] PE Issue 320: https://github.com/w3c/pointerevents/issues/320 
> 
> [5] PE Issue 274: https://github.com/w3c/pointerevents/issues/274 
> 
> [6] PE PR 316: https://github.com/w3c/pointerevents/pull/316 
> 
> [7] PE PR 322: https://github.com/w3c/pointerevents/pull/322 
> 
> [8] PE PR 323: https://github.com/w3c/pointerevents/pull/323 
> 
> [9] PEWG minutes: https://www.w3.org/2020/05/27-pointerevents-minutes.html 
> 
> 
> Thank you,
> Liviu Tinta
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebXR on WebKit

[Dean Jackson]

Hi Sergio! Thanks for the patch and apologies for the silence. I'll take a look.

Dean

> On 12 Mar 2020, at 20:21, Sergio Villar Senin  wrote:
> 
> Not sure how to interprete silence. BTW patch[*] is now ready to be
> reviewed as all EWS are happy with it.
> 
> BR
> 
> [*] https://bugs.webkit.org/show_bug.cgi?id=208702
> 
> O Ven, 06-03-2020 ás 12:56 +0100, Sergio Villar Senin escribiu:
>> Hi,
>> 
>> I've just uploaded a patch[1] (based on previous work from my
>> colleague
>> Žan Doberšek) which brings a very basic WebXR[2] support for WebKit.
>> Right now is just IDLs, stubs and pretty basic platform code, mostly
>> empty implementations anyway.
>> 
>> You can see WebXR[3] as the evolution of the deprecated WebVR API
>> (which I recently removed from the tree). The idea is bringing the
>> experience of mixed reality worlds (from VR to AR) to the Web by
>> using
>> the appropriate devices.
>> 
>> This new spec was not born in a semi-deprecated state as WebVR did.
>> It's currently partially shipped in Chrome/Edge[4]. Firefox has not
>> shipped it yet but Mozilla has been one of the original authors of
>> the
>> specs with some proposals dating back to 2017. There is ongoing work
>> to
>> support the spec[5].
>> 
>> It's worth mentioning that there are already several WPT tests[6] for
>> the feature (my plan is to import them ASAP and make them work as
>> APIs
>> are implemented).
>> 
>> Another important difference from the WebVR era is that right now we
>> have a multiplatform Khronos standarized API for accessing VR/AR
>> devices and platforms called OpenXR[7]. My plan is to implement all
>> the
>> platform code using OpenXR as a reference. This would allow us to use
>> even the same platform code for different ports. AFAIK there is no
>> OpenXR implementation and loader available at the moment for
>> MacOS/iOS
>> but I guess it'll eventually happen (in any case the platform code
>> could be implemented without using OpenXR of course).
>> 
>> Privacy has been always a concern in the WebKit project and now it
>> gained the status of project goal. That's why I'd also like to
>> mention
>> here that privacy was also considered[8] since the very
>> beginning. For example, when I attended the TPAC F2F meeting of the
>> WebXR WG there was a joint session with the privacy CG where
>> fingerprinting and other potential threat vectors were discussed.
>> 
>> Last but not least, I'll focus this early stages of development in
>> the
>> WPE port, meaning that for example I'll be maintaining just the WPE
>> build configuration (other ports won't be affected). My plan is to
>> extend the support to other ports as the implementation matures.
>> 
>> Opinions?
>> 
>> BR
>> 
>> [1] https://bugs.webkit.org/show_bug.cgi?id=208702
>> [2] https://immersive-web.github.io/webxr/
>> [3] https://github.com/immersive-web/webxr/blob/master/explainer.md
>> [4] https://caniuse.com/#search=webxr
>> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1614496
>> [6] 
>> https://wpt.fyi/results/webxr?label=experimental=master
>> [7] https://www.khronos.org/openxr/
>> [8] https://github.com/immersive-web/privacy-and-security
>> 
>> ___
>> 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



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Clearing old reviews from the queue

[Dean Jackson]

> On 16 Feb 2020, at 17:46, Alexey Proskuryakov  wrote:
> 
> 
> 
>> 16 февр. 2020 г., в 7:52, Dean Jackson  написал(а):
>> 
>> Does anyone oppose clearing all review requests that are older than 6 
>> months? (or 1 year?)
> 
> Looking at ancient patches in the review queue, quite a few look like they 
> should still work (e.g. adding new tests). So said that we are not keeping up 
> with reviews, even for simple patches.

It is very sad.

> 
>> I tried to use the bugzilla API to do this, but I couldn't work out how to 
>> detect the attachment state properly. I looked at the source code for the 
>> queue page and it uses custom SQL :)
> 
> What were you trying to do, and how far did you get?

I started explaining to you where I failed, which caused me to read the 
documentation again, and I think I've now got it. I thought that the review 
status was kept in a side table, but it's not.

Basically I now have a script that:

- for each open bug
  - for each attachment
- if !is_patch, continue
- if is_obsolete, continue
- for each flag
  - if name is "r" and status is "?"
- if creation_time is older than 1 year
  - Set flag to r- and leave a "sorry we missed you" message
- if creator is "a...@webkit.org <mailto:a...@webkit.org>"
  - Set flag to r+

So, if we're happy with the 1 year timeout, I'll run this.

Dean

> 
> - Alexey
> 
>> (It's easy to do with the GitHub API)
>> 
>> Dean
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on Badging API

[Dean Jackson]

Not speaking for all of WebKit, and definitely not all of Apple, but I think 
this seems like a good idea.

I'm not sure I get the distinction between app badges and document badges 
though. I'd also like to see some specification text describing how the browser 
should ignore multiple set/clear operations executed in rapid succession (e.g. 
to create a blinking badge) - maybe the limit is one badge operation per minute 
or something?

Also, given that the main use case for this would be alerting the user to a 
notification, it seems like it should be able to link it directly to that. This 
would provide the ability for a push notification to trigger the badge without 
ever firing up the page context.

Dean

> On 19 Jan 2020, at 4:26 pm, Matt Giuca  wrote:
> 
> Hi WebKit team,
> 
> I have previously proposed the Badging API (https://github.com/WICG/badging 
> ) to provide websites with a mechanism to 
> set a badge (a small dot or number) on the current document's tab, or for 
> installed applications, on the app icon in the system shelf or home screen.
> 
> Would WebKit / Safari be interested in implementing the API now or in the 
> future?
> 
> We are planning to ship in Chromium soon:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ
>  
> 
> 
> Regards
> 
> Matt Giuca
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Clearing old reviews from the queue

[Dean Jackson]

Does anyone oppose clearing all review requests that are older than 6 months? 
(or 1 year?)

I tried to use the bugzilla API to do this, but I couldn't work out how to 
detect the attachment state properly. I looked at the source code for the queue 
page and it uses custom SQL :)

(It's easy to do with the GitHub API)

Dean



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Step 1 of Plugin removal: Deleting NPAPI (and thus Flash support)

[Dean Jackson]

> On 13 Jan 2020, at 20:14, Carlos Garcia Campos  wrote:
> 
> El lun, 13-01-2020 a las 05:30 +1100, Dean Jackson escribió:
>> Dear Non-Apple ports,
>> 
>> Running Flash has been more difficult over the past few years as part
>> of a (semi-) coordinated effort by browsers and Adobe. The plan is to
>> remove support for Flash + NPAPI by the end of this year. See the
>> links below. 
>> 
>> I'd like to remove our NPAPI code soon, but I want to make sure the
>> other ports are ok with this. Please speak up if you have a reason to
>> keep it in.
> 
> WPE has never supported NPAPI plugins and the GTK port removed the
> support for GTK2 plugins (flash) already in our current stable version.
> Plugins not using GTK at all (or using GTK3) are still supported by GTK
> port (some of them only under X11, though). I'm ok with removing the
> NPAPI plugins support in the GTk port, but we are at the end of the
> release cycle, so I prefer if we remove the feature right after we
> branch for the next stable version (scheduled for the 1st February). I
> could even branch earlier if needed.

Waiting until February is totally ok with me. Good luck with your release.

Dean

> 
>> [Note that we will still have some plugin code e.g. our internal
>> PDFPlugin, just no support for externally installed plugins]
>> 
>> Dean
>> 
>> * Adobe's end of life for Flash - 
>> https://theblog.adobe.com/adobe-flash-update/
>> * Chrome removing Flash support by end of 2020 - 
>> https://sites.google.com/a/chromium.org/dev/flash-roadmap
>> * Google removing support for Flash by end of 2020 - 
>> https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/
>> * Mozilla removing NPAPI by end of 2020 - 
>> https://developer.mozilla.org/en-US/docs/Plugins/Roadmap
>> * Mozilla only uses NPAPI for Flash - 
>> https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
>> 
> 
> Thanks!
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>


smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Step 1 of Plugin removal: Deleting NPAPI (and thus Flash support)

[Dean Jackson]

Dear Non-Apple ports,

Running Flash has been more difficult over the past few years as part of a 
(semi-) coordinated effort by browsers and Adobe. The plan is to remove support 
for Flash + NPAPI by the end of this year. See the links below. 

I'd like to remove our NPAPI code soon, but I want to make sure the other ports 
are ok with this. Please speak up if you have a reason to keep it in.

[Note that we will still have some plugin code e.g. our internal PDFPlugin, 
just no support for externally installed plugins]

Dean

* Adobe's end of life for Flash - https://theblog.adobe.com/adobe-flash-update/
* Chrome removing Flash support by end of 2020 - 
https://sites.google.com/a/chromium.org/dev/flash-roadmap
* Google removing support for Flash by end of 2020 - 
https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/
* Mozilla removing NPAPI by end of 2020 - 
https://developer.mozilla.org/en-US/docs/Plugins/Roadmap
* Mozilla only uses NPAPI for Flash - 
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Dean Jackson]

> On 13 Sep 2018, at 13:49, youenn fablet  wrote:
> 
> When implementing a new feature, the first thing we usually do is having an 
> experimental flag turned off by default. At some point, we turn on the 
> experimental flag for tests. When ready, the flag is turned on by default.

This isn't true. What we have is pretty strange.

WKTR turns on all experimental features, no matter what their default is.

This is a bit crazy because it means we're potentially developing three 
different configurations, and testing the one that none of us ever live on.

1. Dev build with experimental features as their default
2. Testing with experimental features all on
3. Shipping, where we hopefully remember to turn off any experimental features 
that default to on.

Dean

___
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

[Dean Jackson]

> On 13 Sep 2018, at 09:03, youenn fablet  wrote:
> 
> 
> What about testing?
> 
> 
> You can turn both experimental and internal features on via headers in 
> WebKitTestRunner. Use experimental:FeatureName or internal:FeatureName. For 
> example...
> 
> 
> 
> It seems tedious to add such things to every test.
> That would also mean we would need to remove these lines to every test when 
> we activate the flag by default or when we remove the flag.

It's just a find and replace. I modified hundreds of tests in this manner (I 
didn't actually have to, since the headers were turning on something that was 
already on, but I did it anyway)

> 
> As of WPT, modifying tests on the fly at import time is doable but it goes 
> against the idea of making WPT import/export simpler so I hope we can find 
> something better.
> 
> testharnessreport.js might help activating flags specifically for WPT.

These features are not tweakable from the Web API, but from the client API. JS 
is too late.

> Since an experimental feature flag should not remain off for a long time, a 
> per-experimental-feature file listing the tests to which activate the feature 
> could be considered.

That clashes with Ryosuke's point that moving tests shouldn't change behaviour.

The larger problems are:

- We don't want experimental features to be on in shipping browsers. It might 
be ok for them to be always on in tests, but then MiniBrowser would be 
different from WKTR. At the moment they are always on in tests, and use their 
default value in MiniBrowser (and shipping).

- Internal features can either be on or off by default, because we don't expect 
users to toggle them. The tests should reflect their default value. You use the 
header to test the non-default case.

So what we have right now is probably ok. The issue is with things I moved from 
experimental to internal and that have a default value of off. I think it is 
perfectly fine for those features to require test headers, since they clearly 
aren't ready.

Note that even if I turned off all experimental features outside of testing, 
MiniBrowser and Safari remember if you enable the feature.

Dean


___
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

[Dean Jackson]

> On 13 Sep 2018, at 08:50, Ryosuke Niwa  wrote:
> 
> 
> On Wed, Sep 12, 2018 at 3:09 PM Dean Jackson  <mailto:d...@apple.com>> wrote:
>> On 13 Sep 2018, at 08:05, Ali Juma > <mailto:aj...@chromium.org>> wrote:
>> 
>> 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.
> 
> I thought about this. I see three options:
> 
> 1. Continue to enable all experimental features in testing. The downside is 
> that we're testing something different to what we ship.
> 
> 2. Have the default value only apply to testing, not to shipping. For 
> Internal Features, instead of enabling them all, I had them revert to their 
> default value.
> 
> 3. Have some way to add the headers after importing the WPT test.
> 
> For now, I added headers to the WPT code, because there already were a bunch 
> of tests that had such headers.
> 
> Is that automated? We don't want get into a state where we'd have to manually 
> add those headers whenever we re-import tests.

It isn't.

I think maybe we should go for option 2 at the moment.

Or, ultimately, have a per-directory configuration file that could enable 
features.

Dean


___
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

[Dean Jackson]

> On 13 Sep 2018, at 08:05, Ali Juma  wrote:
> 
> 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.

I thought about this. I see three options:

1. Continue to enable all experimental features in testing. The downside is 
that we're testing something different to what we ship.

2. Have the default value only apply to testing, not to shipping. For Internal 
Features, instead of enabling them all, I had them revert to their default 
value.

3. Have some way to add the headers after importing the WPT test.

For now, I added headers to the WPT code, because there already were a bunch of 
tests that had such headers.

Dean

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

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

[Dean Jackson]

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



Dean

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

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Dean Jackson]

> On 30 Aug 2017, at 8:16 am, Geoffrey Garen  wrote:
> 
> Interesting.
> 
> The majority cases here are 7 or fewer files. I don’t see much difference 
> between these cases and our existing benchmark for one file, where Keith 
> described the build time delta as "barely noticeable".

Was this a .cpp file or a .h file?

I assume that under a unified system, changing a single .cpp file means more 
total code compiled but the same number of files. Changing a single .h file 
would hopefully mean fewer files compiled, but potentially a lot more total 
code.

Does the "you'll hardly notice the difference" rule apply in both cases?

Dan, how did you gather the data below (i.e. how did you count the number of 
files compiled)?

Dean


> 
> For the minority cases that are 23 - 75 files, these challenge Keith’s 
> description that "most of the build time in incremental builds is scanning 
> dependencies” — assuming that you get unlucky enough for none of the files to 
> bundle together.
> 
> If possible, it would be helpful to know if these files were in the same 
> folders or not.
> 
> Alternatively, we can approximate the answer by benchmarking svn up for 
> individual revisions.
> 
> Geoff
> 
>> On Aug 29, 2017, at 2:21 PM, Dan Bernstein > > wrote:
>> 
>> 
>> 
>>> On Aug 29, 2017, at 1:39 PM, Geoffrey Garen >> > wrote:
>>> 
 I see. The right question to ask would have been how much change occurs in 
 their working copy between consecutive incremental builds.
>>> 
>>> If you want to help make our benchmark righter, please do share any data 
>>> you have about the average content of an incremental build that is distinct 
>>> from a daily svn up.
>> 
>> Here is the data from three WebKit contributors surveyed today. For each 
>> contributor, each line corresponds to a single consecutive incremental build 
>> they’ve performed today, and the number shown is the number of files that 
>> were compiled in that build:
>> 
>> A
>> B
>> C
>> 41
>> 4
>> 1
>> 2
>> 1
>> 1
>> 
>> 1
>> 1
>> 
>> 4
>> 7
>> 
>> 4
>> 58
>> 
>> 5
>> 27
>> 
>> 3
>> 23
>> 
>> 4
>> 61
>> 
>> 5
>> 3
>> 
>> 7
>> 75
>> 
>> 1
>> 2
>> 
>> 6
>> 1
>> 
>> 4
>> 2
>> 
>> 4
>> 1
>> 
>> 4
>> 47
>> 
>> 5
>> 
>> 
>> 3
>> 
>> 
>> I hope this helps. It certainly gives me an idea of what a righter benchmark 
>> would be.
> 
> ___
> 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] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Dean Jackson]

> On 29 Aug 2017, at 10:37 am, Keith Miller  wrote:
> 
> Are you growing tired of long cat naps while waiting 45 minutes for WebKit to 
> build? (I’ve definitely never done this 蘿!)

Never.

> Do you want WebKit to build up to 3-4x faster on a clean build?*

Of course.

> Does seeing your incremental build… stay the same sound good?

Yes!

I don't have any knowledge of build systems or how to make things faster, but I 
do want to mention things that are important to my workflow that I hope this 
change won't make worse. I'm a little worried that this appears to be moving 
away from Xcode in a manner that will make development more difficult. Maybe 
I've misunderstood some of the suggestions.

I want to:

- be able to do most (all) of my editing in Xcode
- have code completion and symbol navigation work very nicely in Xcode
- build and run from Xcode
- build and run from Xcode much faster than I can today
- use Xcode's debugger UI
- sometimes have just a single project open in Xcode (e.g. WebCore) and build 
only that part (so I can skip it even having to think about other parts)

Will the new magic build system offer these? Will it break any of them?

If calling build can mean a new Xcode project is created, will I be able to 
open it and have a nice project structure, with the original files I want to 
edit, not the unified sources.

Dean




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

Re: [webkit-dev] CSS Typed OM

[Dean Jackson]

> On 19 Aug 2017, at 5:44 am, Olmstead, Don  wrote:
> 
> I'd like to begin an implementation of CSS Typed OM (CSSOM) and wanted to 
> gauge interest for supporting the feature.

Go for it! While the specification is probably not completely stable, I think 
it is worth starting now.

Dean

>  
> CSSOM provides typed style access to improve performance by removing the need 
> to do lots of string parsing. Its also the basis of other Houdini 
> specifications so working through it will enable those specifications to be 
> implemented.
>  
> If there's interest I can begin implementation after finishing up some 
> outstanding patches. Any particular pointers on good places to begin are 
> greatly appreciated as this is the first feature we here at Sony have 
> attempted.
>  
> Thanks
> Don
>  
> Spec:
> https://drafts.css-houdini.org/css-typed-om/ 
> 
>  
> WebKit Bugzilla:
> https://bugs.webkit.org/show_bug.cgi?id=175733 
> ___
> 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] WebVR on WebKit

[Dean Jackson]

> On 2 Aug 2017, at 19:55, Sergio Villar Senin  wrote:
> 
> 
> Our main interest is to eventually have some implementation working on
> WebKitGtk and/or WPE on Linux but obviously there is a lot of cross-
> platform work that needs to be done as well. Our initial idea would be
> to use the OpenVR API as Valve released a Linux version of their SDK
> some months ago. Looks like a safe bet as other vendors like Firefox or
> Chromium already include it in their trees as third party.

I agree with the idea to assume use of the OpenVR SDK at the moment. It
is the only major VR SDK that is available for macOS, Linux and Windows.

So maybe our platform API should be very similar to the OpenVR API?
I haven't looked at other SDKs like Oculus, but hopefully it isn't too
different.

Dean


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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Dean Jackson]

> On 24 Jul 2017, at 22:44, Brian Burg  wrote:
> 
> Hi WebKittens,
> 
> In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, 
> and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
> 
> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build 
> systems by default, and we have not experienced any fallout from shipping 
> these features in Safari Technology Preview. I think it’s time to remove the 
> feature flag. Are there any objections? Is there a port in-tree that’s 
> compiling without this feature?
> 
> If I don’t hear anything, the flag’s removal will be tracked in 
> .

In general I think we should be more enthusiastic about removing feature flags 
that are guarding core parts of the Web platform. Web Timing is a great 
example. 

Some others I see:

ENABLE_CANVAS_PATH
ENABLE_CSS_COMPOSITING
ENABLE_CSS_SELECTORS_LEVEL4
ENABLE_FETCH_API
ENABLE_GEOLOCATION
ENABLE_INDEXED_DATABASE
ENABLE_STREAMS_API
ENABLE_CSS_SCROLL_SNAP
ENABLE_WEBGL
ENABLE_WEB_AUDIO
ENABLE_WEB_SOCKETS

Dean

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

Re: [webkit-dev] WebKit opengl

[Dean Jackson]

> On 19 Jul 2017, at 12:21, Nagendra K  wrote:
> 
> Current build of WebKit using opengl and with custom port, all apps will 
> directly use the opengl calls to draw, making the opengl independent of 
> WebKit.
> So if I upgrade the WebKit, will the latest WebKit require opengl for any of 
> the new features or can we use opengl delinking WebKit.

I don't understand what you are asking, sorry.

It's possible to make a port of WebKit that doesn't rely on OpenGL. I think the 
Windows port is one example. Technically Apple's iOS/macOS ports only directly 
require OpenGL for WebGL support.

Dean


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

Re: [webkit-dev] Opengl support in webkit

[Dean Jackson]

> On 21 Jul 2017, at 13:47, Nagendra K  wrote:
> 
> Hi ,
> 
> Does WebKit engine mandate to use any version of opengl?
> Can we link any opengl which my platform has.

As long as your OpenGL is compatible with OpenGL 4.0 and above, or OpenGL ES 
2.0 and above, I think you'll be fine.

Dean

>  
> Could see that for opengles2 is there with a flag in if condition and else 
> condition to gl.h.
> So if else is used, can I link to any opengl version which my platform has ?
> 

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

Re: [webkit-dev] Removing support for CSS regions

[Dean Jackson]

I've been told that Amazon's Kindle Cloud Reader uses CSS Regions if available, 
and gets a significant performance boost. It has a fallback though.

Also, it would be worth checking at least Apple's iBooks store for any content 
that might have used regions. It would be a shame if purchased books stopped 
working :)

Dean


> On 31 Jul 2017, at 10:49, Andreas Kling  wrote:
> 
> Hi folks,
> 
> Some time has passed, and it seems that adoption of CSS regions on the web is 
> not gonna happen.
> 
> Blink has long since removed their support.
> Firefox never supported it AFAIK.
> (The new) IE has some amount of support behind a prefix, but no plans to 
> unprefix AFAIK.
> 
> I think it’s time we remove the code from WebKit, and relieve ourselves of 
> the maintenance burden.
> This should also open up numerous opportunities for clean-up and optimization.
> 
> If you know of any reason to keep the feature, such as a major website or 
> WebKit client depending on it, do speak up now!
> 
> The removal work will be tracked in this bug:
> https://bugs.webkit.org/show_bug.cgi?id=174978
> 
> Cheers,
> kling
> ___
> 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] WebGL bug related to PNG textures with zero alpha channel

[Dean Jackson]

Looks like we have a bug in premultiplication. We'll look at it.

Dean

> On Dec 12, 2016, at 6:52 AM, Ivan Lyubovnikov  wrote:
> 
> Hi, all! Can anyone take a look at the bug related to WebGL and PNG textures: 
> https://bugs.webkit.org/show_bug.cgi?id=165297? We've been able to reproduce 
> this issue for a long time and it makes it a bit difficult to use that 
> textures under iOS - this usually requires some workarounds/hacks.
> Thanks in advance!
> 
> Ivan.
> ___
> 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] Experimental features enabled at runtime

[Dean Jackson]

> On 6 Nov. 2016, at 10:03 am, Ryosuke Niwa  wrote:
> 
> I DO want to enable experimental features to be enabled in Safari Technology 
> Preview and WebKit nightly builds by default because that's sort of the whole 
> point of having those versions of Safari in the first place.

I might be the only one with this point of view (and it explains the confusion 
since I added the code), but "Experimental" means exactly that: it isn't ready 
to be enabled by default. If it can be enabled by default, it isn't 
experimental.

Safari Technology Preview is meant to be used as a full-time browser. It has to 
be stable. Yes, it has features that haven't yet shipped in main Safari, but 
they should not be dangerous. The idea of the Experimental Features is that 
developers can easily choose to enable them, just like they do on other 
browsers.

I don't understand why we'd pick a different behaviour than Chrome, Firefox, 
etc in this case. Developers understand this situation.

Dean

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

Re: [webkit-dev] WebKit GPU rendering possibility

[Dean Jackson]

> On 5 Nov. 2016, at 12:34 am, Rogovin, Kevin  wrote:
> 
> One question, what happens with WebGL 2.0 support on WebKit? I ask because 
> WebGL 2.0 is essentially OpenGL ES 3.x for JavaScript.

We've started on a WebGL 2.0 implementation.

Dean

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

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

[Dean Jackson]

I propose we make it official that the Web Inspector Coding Style is what must 
be used for all JavaScript and CSS that count as source code in the project.
https://trac.webkit.org/wiki/WebInspectorCodingStyleGuide

Now that JavaScript is used in more places (JS builtins, some parts of the DOM, 
media controls) it would be nice to make it all consistent. Note that the page 
above can't decide if it is just JS or both JS and CSS, but I think it should 
be both.

This would not include LayoutTests or PerformanceTests. It's the wild west in 
there - you can do whatever you want.


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

Re: [webkit-dev] REQUEST_ANIMATION_FRAME on all ports?

[Dean Jackson]

> On Jun 8, 2016, at 2:23 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 08.06.2016, 23:59, "Dean Jackson" <d...@apple.com>:
>> Do the EFL and GTK ports always enable this feature? If so, I'm going to 
>> remove the compile flag.
> 
> While I'm not opposed to this change, it looks like its maintenance cost is 
> near zero.

I think we should remove guards for features that are (now) core to the Web.

Dean

> Last time I was building with it disabled it was not broken, though it didn't 
> receive any compilation fixes for at least 2 years!
> 
> https://bugs.webkit.org/show_bug.cgi?id=155882
> https://lists.webkit.org/pipermail/webkit-dev/2014-March/026366.html
> 
> -- 
> Regards,
> Konstantin

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

[webkit-dev] REQUEST_ANIMATION_FRAME on all ports?

[Dean Jackson]

Do the EFL and GTK ports always enable this feature? If so, I'm going to remove 
the compile flag.

Dean

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

Re: [webkit-dev] canvas and sRGB

[Dean Jackson]

> On 3 May 2016, at 8:10 AM, Rik Cabanier <caban...@gmail.com> wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 2:59 PM, Dean Jackson <d...@apple.com 
> <mailto:d...@apple.com>> wrote:
> 
>> On 3 May 2016, at 7:04 AM, Rik Cabanier <caban...@gmail.com 
>> <mailto:caban...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, May 2, 2016 at 1:58 PM, Simon Fraser <simon.fra...@apple.com 
>> <mailto:simon.fra...@apple.com>> wrote:
>>> On May 2, 2016, at 1:45 PM, Rik Cabanier <caban...@gmail.com 
>>> <mailto:caban...@gmail.com>> wrote:
>>> 
>>> All,
>>> 
>>> with the release of DCI-P3 screen, WebKit began supporting the display of 
>>> high gamut images.
>>> Specifically, if you have an image with a DCI-P3 profile, its pixels render 
>>> untouched on the new displays.
>>> 
>>> However, if you try do do any sort of canvas manipulation, you will see 
>>> that the colors are being compressed to sRGB and you will lose the depth of 
>>> the color.
>>> 
>>> Was it an oversight to always create the canvas imagebuffer in sRGB? [1]
>> 
>> No, this was a deliberate choice. We can't change author expectations for 
>> what getImageData() return.
>> 
>> Now we see different visual output which is also not what an author expects 
>> :-(
> 
> Since there is no way to create a canvas element with pixel data that is 
> interpreted to be in anything other than sRGB, this behaviour seems expected 
> to me. I'm not sure what else could happen? We couldn't magically make all 
> the canvas elements in the page use P3. If we did that, they wouldn't match 
> the CSS content.
> 
> I don't see why that would be. CSS colors and tagged/untagged images would be 
> color corrected while being drawn just like it happens in HTML.
> get/putImageData would of course be uncorrected as it works on raw pixels.

That's the problem. If we did what you suggest a paint with rgba(255, 0, 0, 1) 
would not be the same as putting [255, 0, 0, 255] into the buffer via 
ImageData, and no page in the world would expect that. And there would also be 
no way to paint into the canvas to match colours outside of sRGB.

I think we did the right thing for now. The complete solutions are coming.

Dean


>  
> The fix is coming: a way to tag the colorspace of the canvas element.
> 
> That's great! Do you have an idea how far off that proposal is?
>  
>> Can you elaborate what is unexpected with getImageData? Is it that css "red" 
>> no longer returns 100% red pixels?
>>> If this is as-designed, how can we work around this limitation?
>> 
>> With possible future enhancements to the canvas spec that allow authors to 
>> request backing store with a different format and/or color profile.
>>> 
>>> PS
>>> I asked the same question on WhatWG. [2]
>>> 
>>> 
>>> 1: 
>>> https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73
>>>  
>>> <https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73>
>>> 2: 
>>> https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html
>>>  
>>> <https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html>
>> Simon
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 

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

Re: [webkit-dev] canvas and sRGB

[Dean Jackson]

> On 3 May 2016, at 7:04 AM, Rik Cabanier  wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 1:58 PM, Simon Fraser  > wrote:
>> On May 2, 2016, at 1:45 PM, Rik Cabanier > > wrote:
>> 
>> All,
>> 
>> with the release of DCI-P3 screen, WebKit began supporting the display of 
>> high gamut images.
>> Specifically, if you have an image with a DCI-P3 profile, its pixels render 
>> untouched on the new displays.
>> 
>> However, if you try do do any sort of canvas manipulation, you will see that 
>> the colors are being compressed to sRGB and you will lose the depth of the 
>> color.
>> 
>> Was it an oversight to always create the canvas imagebuffer in sRGB? [1]
> 
> No, this was a deliberate choice. We can't change author expectations for 
> what getImageData() return.
> 
> Now we see different visual output which is also not what an author expects 
> :-(

Since there is no way to create a canvas element with pixel data that is 
interpreted to be in anything other than sRGB, this behaviour seems expected to 
me. I'm not sure what else could happen? We couldn't magically make all the 
canvas elements in the page use P3. If we did that, they wouldn't match the CSS 
content.

The fix is coming: a way to tag the colorspace of the canvas element.

Dean

> 
> Can you elaborate what is unexpected with getImageData? Is it that css "red" 
> no longer returns 100% red pixels?
>> If this is as-designed, how can we work around this limitation?
> 
> With possible future enhancements to the canvas spec that allow authors to 
> request backing store with a different format and/or color profile.
>> 
>> PS
>> I asked the same question on WhatWG. [2]
>> 
>> 
>> 1: 
>> https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73
>>  
>> 
>> 2: 
>> https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html 
>> 
> 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] About unprefixing CSS Grid Layout (implementation status summary included)

[Dean Jackson]

> On 28 Apr 2016, at 4:28 AM, Sergio Villar Senin  wrote:
> 
> On 27/04/16 17:59, Simon Fraser wrote:
>>> On Apr 27, 2016, at 4:39 AM, Manuel Rego Casasnovas  wrote:
>>> 
>>> Hi,
>>> 
>>> as announced yesterday it seems that the WebKit prefixing policy has
>>> been updated [1].
>>> 
>>> Right now CSS Grid Layout implementation is prefixed in WebKit and
>>> behind a compilation flag.
>>> We'd like to ask about the possibility to unprefix it and put it behind
>>> a runtime flag (probably removing the compilation flag too).
>> 
>> I approve of this proposal.
>> 
>> Simon
> 
> Awesome. We'll unprefix it ASAP (adding the runtime flag and removing
> the build one).

Please leave the build flag around. We probably need a bigger discussion
on this, but for now we should have both a runtime flag and a build flag
just in case a browser ships and doesn't want the feature compiled at all
(reducing binary size).

Dean

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

Re: [webkit-dev] Unprefixing hyphens property?

[Dean Jackson]

> On 26 Jan 2016, at 2:53 AM, Michael Catanzaro  wrote:
> 
> Mozilla has unprefixed the CSS hyphens property as of Firefox 43. Is
> there any interest in unprefixing it for WebKit?

We're interested in unprefixing everything, but we generally like
to know if:

- there is good test coverage (e.g. the web-platform-tests)
- we pass a lot of the tests

Dean

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

Re: [webkit-dev] Unprefixing intrinsic size keywords (-webkit-min-content et al)

[Dean Jackson]

 On 7 Aug 2015, at 2:44 AM, Christian Biesinger cbiesin...@chromium.org 
 wrote:
 
 Hi all!
 
 We (blink) would like to unprefix the intrinsic sizing keywords:
 https://drafts.csswg.org/css-sizing/#width-height-keywords
 
 We support them for widths and for heights (though they all do the
 same thing for heights)
 
 We were wondering what Webkit's plan for those keywords is -- are you
 also interested in unprefixing? Are you happy with the keywords as
 specced? Would you rather stop supporting them?

Is there a test suite?

I think WebKit should unprefix these keywords.

Dean


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

Re: [webkit-dev] CSS4 Media Queries

[Dean Jackson]

 On 23 Oct 2014, at 5:08 pm, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Fri, Oct 17, 2014 at 4:55 PM, Dean Jackson d...@apple.com wrote:
 Hi floks,
 
 I'm going to start implementing a small part of CSS4 Media Queries. I'll put 
 it behind a feature flag.
 
 I'm starting with http://dev.w3.org/csswg/mediaqueries-4/#inverted because 
 Apple wants to discuss it at the W3C TPAC meetings. We don't have any 
 intention to ship the feature yet - it's just for experimentation and 
 evaluation. I suggest other ports disable it if they plan on releasing from 
 trunk.
 
 I've put MQ stuff related to the inversion/high-contrast/etc on the
 agenda wiki, so it'll definitely be discussed.

As a followup, inverted-colors and monochrome are now implemented on Apple 
ports. I ended up not using a prefix or feature flag because I’m hoping that 
there won’t be any breaking changes.

Dean

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

[webkit-dev] CSS4 Media Queries

[Dean Jackson]

Hi floks,

I'm going to start implementing a small part of CSS4 Media Queries. I'll put it 
behind a feature flag.

I'm starting with http://dev.w3.org/csswg/mediaqueries-4/#inverted because 
Apple wants to discuss it at the W3C TPAC meetings. We don't have any intention 
to ship the feature yet - it's just for experimentation and evaluation. I 
suggest other ports disable it if they plan on releasing from trunk.

Dean

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

Re: [webkit-dev] CSS4 Media Queries

[Dean Jackson]

 On 18 Oct 2014, at 10:55 am, Dean Jackson d...@apple.com wrote:
 
 I'm going to start implementing a small part of CSS4 Media Queries. I'll put 
 it behind a feature flag.
 
 I'm starting with http://dev.w3.org/csswg/mediaqueries-4/#inverted because 
 Apple wants to discuss it at the W3C TPAC meetings. We don't have any 
 intention to ship the feature yet - it's just for experimentation and 
 evaluation. I suggest other ports disable it if they plan on releasing from 
 trunk.

I should have added that I have no idea how to actually implement it on other 
platforms, or if screen inversion is supported. So it won't evaluate to true 
until there is platform code backing it anyway.

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

[webkit-dev] Removing ENABLE guard for @supports (CSS3_CONDITIONAL_RULES)

[Dean Jackson]

We've had support for @supports for a while. I'm planning to remove the 
compile-time guard for the feature.
(Note: Safari on iOS 8 and the public Yosemite builds currently have it turned 
off)

Does anyone disagree?

https://bugs.webkit.org/show_bug.cgi?id=137571

Dean

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

Re: [webkit-dev] Easy bugs for grab

[Dean Jackson]

FWIW, I've set a personal goal to unprefix one thing a week, until it gets hard 
:)

If you want to unprefix something, let me know and I'll help (and count your 
work towards my goal!!)

Dean

 On 23 Sep 2014, at 6:28 pm, Benjamin Poulain benja...@webkit.org wrote:
 
 Hello WebKittens,
 
 From time to time, people ask for easy bugs to fix.
 
 Looking at various specs, I see some new features and easy fixes available. 
 For example:
 -Unprefix cursor zoom-in and zoom-out (easy): 
 http://www.w3.org/TR/css3-ui/#cursor
 -Element.closest (easy): https://dom.spec.whatwg.org/#dom-element-closest
 -Fix the visualization of :nth-child(An+B of selector) in the Inspector 
 (probably easy).
 -Unprefix your favorite CSS property (easy to hard depending on the property).
 -etc, etc.
 
 If you want to work on an amazing opensource project, here is an opportunity 
 to get started. Shoot me an email if you want to implement one of the ideas 
 above.
 
 If nobody wants those, I'll just fix them :)
 
 Benjamin
 ___
 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] FFT normalization in RealtimeAnalyser

[Dean Jackson]

Fixed in r172816.

Dean

 On 15 Aug 2014, at 1:56 am, Info i...@wothke.ch wrote:
 
 This seems to be a bug... that has been fixed in Chromium: see 
 chromium\src\third_party\WebKit\Source\modules\webaudio
 
 
 Zitat von Info i...@wothke.ch:
 
 In order to understand the idiotic differences between the data ranges of 
 the AnalyzerNode's getFloatFrequencyData() and getByteFrequencyData() APIs I 
 finally found myself analyzing the WebKit sources: 
 https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/webaudio/RealtimeAnalyser.cpp
 
 What surprises me there is the:
const double magnitudeScale = 1.0 / DefaultFFTSize;
 which is used to normalize the FFT results (see 
 RealtimeAnalyser::doFFTAnalysis()).
 
 Should the correct scaling factor not rather be: 2/actualFftSize?
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] FeatureDefines.h and .xcconfig

[Dean Jackson]

Just answering this bit because the consensus seems to be to go for the single 
header file.

 On 7 Aug 2014, at 9:57 pm, Laszlo Gombos laszlo.gom...@webkit.org wrote:
 
  While FeatureDefines.h says Use this file to list _all_ ENABLE() macros 
  it also says The feature defaults in this file are only taken into account 
  if the (port specific) build system has not enabled or disabled a 
  particular feature, which is not true.
 
 Can you elaborate on why this is not true or perhaps suggest better wording ? 
 Setting any ENABLE_FEATURE_NAME macro to an empty string in xcconfig is 
 explicitly disabling a feature in the build system (see also the comment in 
 e.g. WebCore/Configurations/FeatureDefines.xcconfig)

It doesn't explicitly disable it.

If the .xcconfig says:

ENABLE_FEATURE_NAME=;

Xcode will start a build without that flag defined at all (as an environment 
variable). Notice that the last line in the .xcconfig is FEATURE_DEFINES = 
long list and the empty string won't provide any data here.

Then FeatureDefines.h comes along and says:

#if !defined(ENABLE_FEATURE_NAME)
#define ENABLE_FEATURE_NAME 1
#endif

Dean


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

[webkit-dev] FeatureDefines.h and .xcconfig

[Dean Jackson]

Hi floks,

Things are a bit confusing in the OS X and iOS build configurations because we 
have both a FeatureDefines.h and a set of .xcconfig files, often defining the 
same thing, and sometimes inconsistently (or at least I've made the mistake of 
turning a feature off in one place when the other place turned it back on).

Obviously it would be good to have only one location for feature enabling.

While FeatureDefines.h says Use this file to list _all_ ENABLE() macros it 
also says The feature defaults in this file are only taken into account if the 
(port specific) build system has not enabled or disabled a particular feature, 
which is not true.

My proposal is to stop using FeatureDefines.h for the Apple ports (*) and move 
completely to .xcconfig files. 

Notes:

- Some scripts launched by Xcode might use the ENABLE_WHATEVER environment 
variables (which FeatureDefines.h can't provide)

- The xcconfig files will probably have to be of the form ENABLE_WHATEVER=0 to 
disable a feature, rather than just leaving it blank.

- We'd have to change from #ifdef to #if in places.

- You'd always have to edit 4 files to toggle a feature :(

- Generating the FeatureDefines.xcconfig from FeatureDefines.h might be cool, 
but we have a fair amount of release-specific logic in there (e.g. only enabled 
on 10.9).

Is this a terrible idea? Please suggest a better one!

Dean

(*) I think Apple's Windows port should probably continue with FeatureDefines.h 
because it doesn't use Xcode.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore GPU module

[Dean Jackson]

The Loop-Blinn code is dead and should be removed from WebKit. I believe Ken 
Russell implemented it to help with some Chrome/Skia drawing performance, but 
since then Skia itself updated to use a similar GPU-accelerated approach.

Dean

On 18 Jun 2014, at 6:07 pm, Michael IV explomas...@gmail.com wrote:

 Hi All.I have been investigating into WebKit text rendering details and I 
 found Loop-Blinn implementation in GPU directory of WebCore.I have tested it 
 and it kind of works ok for convex shapes rendering which probably should be 
 ok for text glyphs outline as well.
 But I have got a couple of question regarding this module:
 1)Is it used by the browsers to render text or 2d shapes?
 2)Is it actually ready for real-life usage?
 3)How anti  aliasing is handled?I mean ,I found that only curves are 
 anti-aliased(internally by the shader) but the straight line outlines need 
 proper MSAA which can be pretty expensive or even unavailable  on some 
 platforms.
 
 Also I found a bug: when drawing a path with two overlapping convex shapes 
 ,the hole created on the overlap region which is aliased.
 -- 
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Dean Jackson]

On 6 May 2014, at 11:13 am, Rik Cabanier caban...@gmail.com wrote:

 On Mon, May 5, 2014 at 5:52 PM, Simon Fraser simon.fra...@apple.com wrote:
 It allows attackers to know even more about my system, exposing more data for 
 fingerprinting.
 
 People can already approximate this today. Approximations are fuzzy so this 
 might hurt performance if you're not a popular platform or change how the 
 browser implements workers.

There is a difference between approximation and clear detection. During 
discussion of a related feature on the WebGL list (for exposing the GPU 
information to the page), I noted at the time that it would allow any page in 
the world to detect you'd spent X thousand dollars on a Mac Pro in the last 30 
days. Being able to detect the number of cores provides more info - e.g. you 
spent X + Y thousand dollars for the upgrade.

Let's not show that user ads for vacations in Compton... let's show them the 
Bahamas instead.

  
 Do you really want a page to know that you have a  fancy-pants 24-core Mac 
 Pro rather than a little Mac mini?
 
 Yes!
 If I have 24 cores ready to do work and the page can put them to use, I would 
 like it to do so.
 At the same time, if I just have a old mac mini, I don't want the page to 
 launch 24 workers as that will exhaust my memory and cause contention. 

But as Oliver said, maybe I don't want the page to use all cores.

Dean



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

[webkit-dev] remove ENABLE(REQUEST_ANIMATION_FRAME)

[Dean Jackson]

Does anyone still build with requestAnimationFrame disabled?

Dean

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

Re: [webkit-dev] remove ENABLE(REQUEST_ANIMATION_FRAME)

[Dean Jackson]

Thanks. In which case I plan to remove the guard in a day or so. Speak up now 
if you object.

(And to be perfectly clear, I’m not removing requestAnimationFrame itself :)

Dean

On 19 Mar 2014, at 10:54 am, 송진우 jin...@webkit.org wrote:

 It is enabled in EFL port. :)
 
 Jinwoo
 
 2014년 3월 19일 수요일, Dean Jacksond...@apple.com님이 작성한 메시지:
 Does anyone still build with requestAnimationFrame disabled?
 
 Dean
 
 ___
 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] Determining the device pixel density of target device

[Dean Jackson]

Greetings AgentX, if that is your real name,

On 5 Mar 2014, at 3:59 pm, AgentX pulkit.mehra@gmail.com wrote:

 I was working with *responsive images* in Webkit and I came across this
 *‘deviceScaleFactor’* attribute with determines the pixel density on the
 target device.
 I was unable to find out how does Webkit determine it, that is which
 functions does it use and where can I find them in the Source Code? All I
 was able to find was that it used a function *‘page-deviceScaleFactor()’*
 which somehow returned the scale factor but I was unable to find the exact
 function which actually computes the scale factor.
 
 Any help here would be highly appreciated!!

As the longer email response suggested, the deviceScaleFactor is initialised
by the hosting application. For example, in WebKit1 on OS X, you can see it 
set in WebView.

WebKit itself does not detect the hardware scaling factor.

Dean

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

Re: [webkit-dev] WebGlRendering Context Restored and Lost

[Dean Jackson]

Hi Rakesh,

On 21 Feb 2014, at 2:18 pm, Rakesh Sadhu rakeshsa...@hotmail.com wrote:

 I have a question, When a glcontext is lost and again restored , what should 
 be the behaviour of associated extensions ?

When a ContextLost occurs on a WebGLRenderingContext all extensions should be 
reset, as described by the specification (with the exception of the special 
extension that can manually trigger a ContextLost). This doesn’t necessarily 
mean the values get NULLed (since you may have an existing reference), just 
that they will fire exceptions if you use them.

I have an in-progress pull request on a test case for this, on the Khronos 
github repository.

BTW - this question is probably best suited to the WebGL mailing lists, unless 
you think there is a WebKit bug.

Dean

 I have a test case  
 http://www.khronos.org/registry/webgl/sdk/tests/conformance/context/context-lost-restored.html,
 and in it I am confused to see  that upon context restoration , test case 
 expects extension 's related API's to be NULL .
 
 here is the  js code snippet from above mentioned link:
 
 
 function testOESVertexArrayObject() {
   if (OES_vertex_array_object) {
 // Extension must still be lost.
 shouldBeNull(OES_vertex_array_object.createVertexArrayOES());  // WHY 
 
 // Try re-enabling extension
 
 old_OES_vertex_array_object = OES_vertex_array_object;
 OES_vertex_array_object = reGetExtensionAndTestForProperty(gl, 
 OES_vertex_array_object, false);
 shouldBeTrue(OES_vertex_array_object.createVertexArrayOES() != null);
 shouldBeTrue(old_OES_vertex_array_object.createVertexArrayOES() == 
 null);
   }
 }
 
 function testExtensions() {
   testOESTextureFloat();
   testOESVertexArrayObject();
   // Only the WEBGL_lose_context extension should be the same object after 
 context lost.
   new_WEBGL_lose_context = reGetExtensionAndTestForProperty(gl, 
 WEBGL_lose_context, true);
 }
 
 
 ///  this function is a callback function , which is attached to 
 addeventlistener in above mention link//
 
 function testRestoredContext()
 {
 debug(Test restored context);
 shouldBeFalse(contextRestoredEventFired);
 contextRestoredEventFired = true;
 shouldBeFalse(gl.isContextLost());
 shouldBe(gl.getError(), gl.NO_ERROR);
 
 // Validate that using old resources fails.
 testResources(gl.INVALID_OPERATION);
 
 testRendering();
 
 // Validate new resources created in testRendering().
 testResources(gl.NO_ERROR);
 
 testExtensions();
 
 debug();
 }
 
 Our Webkit Nightly Build  fails 
 shouldBeNull(OES_vertex_array_object.createVertexArrayOES())
 which it should fail , however khronous test case suite expects it to PASS , 
 adn i tested this on chrome on windows, that passes :(
 
 
 Kindly put some light here..
 regards
 rsadhu
 
 
 regards
 RSadhu
 ___
 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] On web-exposing features disabled at runtime

[Dean Jackson]

On 14 Feb 2014, at 12:17 am, Sergio Villar Senin svil...@igalia.com wrote:

 En 11/02/14 21:04, Maciej Stachowiak escribiu:
 
 Why not enabling the feature entirely on trunk? (and disable it when
 shipping product by disabling the compile time flag?).
 I think feature doing that tends to become stable a lot quicker.
 Occasionally a feature is so experimental you don't even want it in nightly 
 builds - it would cause too much instability.
 
 But it's true, a lot of the time a feature is ready for testing in nightlies 
 or developer builds, but should not be shipped just yet. I think a runtime 
 flag is actually a good way to do that. The code that will actually compile 
 and ship can more easily be tested that way (by testing with both modes of 
 the flag).
 
 So if I understood correctly the idea would be to bring the feature flag
 back and at the same time switch the runtime flag on by default for all
 the ports right?

FWIW this is what we agreed to do at the contributor’s meeting last year.

Enable by default in ToT (and thus nightly builds).
Compile-time disable on a shipping branch if you don’t want to expose it.

It’s not a hard rule though.

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

Re: [webkit-dev] WebGL backends

[Dean Jackson]

On 10 Feb 2014, at 9:27 am, Steven Coul (scoul) sc...@cisco.com wrote:

 
 Would this be simplify as in tidy up existing code, get down to a simple 
 subset of required functionality, and maybe abstracting the (E)GL part?
 
 Or are you considering a simplification by just saying it will be EGL version 
 X, and OpenGL version Y from now on and nothing else?

No, I was just hoping there was a chance to reduce the number of 
implementations, but it seems they are all actively used.

There might still be an opportunity to collect shared functionality (Alex 
mentioned Windows) but that was the existing design goal anyway, so it would be 
minor changes if any.

Thanks to everyone who responded.

Dean

 
 
 Steve Harry Coul
 sc...@cisco.com
 
 
 
 On Feb 9, 2014, at 2:59 PM, Dean Jackson d...@apple.com wrote:
 
 Hi floks.
 
 I’m looking into simplifying our WebGL code, particularly our 
 GraphicsContext3D implementations. Apple uses either the OS X or iOS OpenGL 
 backend for its ports, but it isn’t clear to me what backend the other ports 
 are using.
 
 Could the other port developers please reply to let me know how you’re 
 accessing OpenGL?
 
 Thanks,
 
 Dean
 
 ___
 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] WebGL backends

[Dean Jackson]

Hi floks.

I’m looking into simplifying our WebGL code, particularly our GraphicsContext3D 
implementations. Apple uses either the OS X or iOS OpenGL backend for its 
ports, but it isn’t clear to me what backend the other ports are using.

Could the other port developers please reply to let me know how you’re 
accessing OpenGL?

Thanks,

Dean

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

Re: [webkit-dev] The SrcN responsive images proposal

[Dean Jackson]

[And the holy book sayeth cursed is she who participates in standards email, 
doomed forever to receive email in CC and being unable to sleep at night. ]

On 7 Nov 2013, at 17:43, Tab Atkins Jr. jackalm...@gmail.com wrote:

 A proposal for a new paradigm of using multiple attributes deserves some 
 resistance, careful consideration and exploration of alternatives. I feel my 
 factual example of path d was flippantly tossed aside. So I responded in 
 jest.
 
 Apologies if you believed my response was flippant; it was short, but
 serious and to the point.  I explained why the path d example wasn't
 very good - it's a single (albeit way overcomplicated) list of
 commands.  The src-N attributes already contain lists, so they're
 comparable.  I'm objecting to combining the src-N attributes into a
 single attribute because that produces a *list of lists*, which is a
 significant step further in mental complexity.

one of the things I liked about srcset is that in the most urgent case it is 
simply one extra attribute with one higher resolution image. 

once we get into structure and ordering and multiple options and art direction 
any of these attribute solutions looks horrible. I don't care whether it is one 
attribute or 99, it's a pain to understand. if you want structure, use markup. 
I'm tempted to think the picture element is a better solution for these 
advanced cases. 

fwiw path d is an attribute because we expected thousands of values in that and 
structure would have been too unwieldy. 

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

Re: [webkit-dev] The SrcN responsive images proposal

[Dean Jackson]

On 5 Nov 2013, at 9:55 am, Timothy Hatcher timo...@apple.com wrote:

 On Nov 5, 2013, at 2:18 AM, John Mellor joh...@chromium.org wrote:
 
 img srcset=(min-width: 640px) 0.5x ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x 
 ph...@2x.jpg || 0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x 
 photo-c...@2x.jpg
 
 I prefer this over multiple attributes. It is a syntax that needs little 
 explanation before you can read it and use it. It also expands the existing 
 srcset instead of confusing things with other attributes.
 
 srcN is also too fiddly. If you want to add a higher precedent srcN, you need 
 to reorder all the existing srcN attribute names. With srcset you just need 
 to edit a single attribute's value, adding a logic operator between the rules.

This is a great point.

Also, we should be mindful that whatever solution should be vaguely applicable 
to other contexts where you’re selecting resources based on resolution, etc, 
such as video and CSS properties. I don’t want an explosion of attributes 
everywhere, and I don’t even know how you’d do that in CSS (background-image-1, 
background-image-2, …)

Dean

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

[webkit-dev] Mihnea-Vlad Ovidenie is now a reviewer

[Dean Jackson]

My Fellow Community,

I’m happy to announce that Mihnea is a WebKit reviewer. As you might now, 
Mihnea has done a lot of work in layout, particularly CSS Regions and 
Exc^H^H^HShapes.

Please send him all your patches!! :)

Dean

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

Re: [webkit-dev] Animations feature flag

[Dean Jackson]

On 17 Oct 2013, at 2:22 am, Dirk Schulze dschu...@adobe.com wrote:

 Did you already open a master bug for the upcoming changes? Can you add a 
 link please?

Good point! http://webkit.org/b/122912

Dean

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

Re: [webkit-dev] Animations feature flag

[Dean Jackson]

On 17 Oct 2013, at 6:35 am, Dean Jackson d...@apple.com wrote:

 
 On 17 Oct 2013, at 2:22 am, Dirk Schulze dschu...@adobe.com wrote:
 
 Did you already open a master bug for the upcoming changes? Can you add a 
 link please?
 
 Good point! http://webkit.org/b/122912

I forgot to add that there is now a bugzilla component for Animations. This 
should
hold all the new things, as well as bugs in CSS transitions and animations (and
SVG animations I guess).

Dean

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

[webkit-dev] Animations feature flag

[Dean Jackson]

Hi floks,

I’m about to add a flag WEB_ANIMATIONS, behind which I’ll start:

- Implementing an animation engine that matches the model in W3C’s Web 
Animation spec
- Allowing CSS and SVG animations to use the new engine
- Exposing enough internal JS API to allow improved testing (currently a very 
weak point for us)
- Possibly looking at implementing parts of the public API

The last point was controversial when it was raised here a while ago. We should
discuss it again when we have something to implement upon.

There will also be a runtime flag to enable the new engine. With the flag 
disabled,
nothing should break. Eventually we’ll be able to toggle the flag and have a 
better
animation engine.

Dean

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

Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag

[Dean Jackson]

Yeah, as we agreed at the contributor’s meeting, if we think a feature is ready 
for experimentation, and we think it will eventually be enabled (e.g. there is 
a stable-ish spec), then we turn it on for nightly builds.

I assume that this doesn’t break any existing decoration code?

Dean

On 5 Oct 2013, at 4:24 am, Sam Weinig wei...@apple.com wrote:

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

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

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Dean Jackson]

On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org wrote:

 On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:
 
 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know there
 has been a push to move away from vendor prefixes lately, so if there are no
 objections, I propose we use the unprefixed version.
 
 
 I think that's what Mozilla and Google are doing but I don't think we
 necessary have to follow the suit.
 
 FYI, because IMO this is an important clarification - Mozilla and
 Google use unprefixed versions only *behind a (runtime) flag*, until
 the spec is stable. That way experimental features are not exposed to
 the web at large until it is unlikely that the spec will change, to
 avoid cross-browser compatibility risks.

We decided on a slightly different approach, which is to prefix things
but enable them by default in nightly builds. That way a port must still
decide at their shipping time whether or not to enable the feature.

In the Moz + Google case, the experimental form is exposed unprefixed to a small
number of users on the Web. In our case, the experimental form is exposed
prefixed. We concluded that we’ve changed things enough times while prefixed
that it was worth the extra “this is experimental and may change” notice.

Dean


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

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Dean Jackson]

On 5 Oct 2013, at 6:22 am, Adam Barth aba...@webkit.org wrote:

 On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote:
 On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org 
 wrote:
 On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:
 
 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know 
 there
 has been a push to move away from vendor prefixes lately, so if there are 
 no
 objections, I propose we use the unprefixed version.
 
 I think that's what Mozilla and Google are doing but I don't think we
 necessary have to follow the suit.
 
 FYI, because IMO this is an important clarification - Mozilla and
 Google use unprefixed versions only *behind a (runtime) flag*, until
 the spec is stable. That way experimental features are not exposed to
 the web at large until it is unlikely that the spec will change, to
 avoid cross-browser compatibility risks.
 
 We decided on a slightly different approach, which is to prefix things
 but enable them by default in nightly builds. That way a port must still
 decide at their shipping time whether or not to enable the feature.
 
 In the Moz + Google case, the experimental form is exposed unprefixed to a 
 small
 number of users on the Web. In our case, the experimental form is exposed
 prefixed. We concluded that we’ve changed things enough times while prefixed
 that it was worth the extra “this is experimental and may change” notice.
 
 Does this imply that you'll remove the prefixes before shipping the
 features in a production release?

I can’t speak for anyone other than the Apple port, and even there I’m
definitely not the official word on the topic, but I don’t think that is
implied. It’s likely going to depend on perceived stability of the feature,
testing, community feedback, etc.

The important thing is that our goal is to get to the unprefixed stable form
as soon as possible.

Also, our prefixing/unprefixing rules are not set in stone. I think the 
community
will evaluate them case by case.

Dean


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

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Dean Jackson]

On 5 Oct 2013, at 6:45 am, Adam Barth aba...@webkit.org wrote:

 Also, our prefixing/unprefixing rules are not set in stone. I think the 
 community
 will evaluate them case by case.
 
 I would encourage you (and others) not to ship new vendor-prefixed
 APIs in production releases.  If the feature isn't stable enough to
 ship without a prefix, it's also harmful to the web ecosystem to ship
 with a vendor prefix.

We’re well aware of the risks and benefits. This ain’t our first
time at the rodeo.

Dean

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

Re: [webkit-dev] XML Serialization Issues

[Dean Jackson]

I believe the tests you added are not reliable across runs. In particular, the 
unique id you generate
isn’t necessarily always the same, but your -expected.txt is just a dump of the 
DOM.

I filed: http://webkit.org/b/120490, but I only mentioned one test. Since then 
I’ve seen more fail.

Dean

On 30 Aug 2013, at 3:25 am, Rob Buis rwlb...@gmail.com wrote:

 Fixed.
 
 More seriously, all bugs mentioned below are fixed/closed, please open
 new ones for any regressions/improvements.
 Cheers,
 
 Rob.
 
 On 19 June 2013 14:44, Alex Milowski a...@milowski.com wrote:
 I was working on using MathJax [1] to turn MathML into SVG and ran into some
 serious serialization issues.  In summary, as MathJax programmatically
 creates SVG renderings of the MathML, when it creates XLink attributes, it
 doesn't seem to define a prefix.  While this works for rendering, it does
 when you try to extract a serialization of the SVG.
 
 That is, MathJax creates SVG 'use' elements like (assuming SVG as the
 default namespace):
 
 use xlink:href=#MJMATHI-78 xmlns:xlink=http://www.w3.org/1999/xlink/
 
 but instead I get:
 
 use href=#MJMATHI-78 xmlns=http://www.w3.org/1999/xlink/
 
 which makes the SVG incorrect as the 'use' element is now in the xlink
 namespace.
 
 You can work around this by manually setting the prefix property on each
 xlink:href attribute.
 
 Looking into why this happens, I can see that the serializer seriously
 broken in a number of ways when the DOM is constructed with incomplete (e.g.
 missing namespace declarations) or inconsistent information (e.g. same
 prefix used for different namespaces in the same context).
 
 I found at least 6 bugs outstanding (#16739 [2], #16496 [3], #19121 [4],
 #22958 [5], #83056 [6], #106531 [7]) and filed a new one (#117764 [8]).
 Some of these date back to 2007 (6 years ago!).
 
 These bugs break down to these categories:
 
 1. Default namespace issues: #16739, #106531, #16496
 2. Conflicting prefix mappings: #117764, #19121
 3. Namespace attribute issues: #22958, #83056, #117764
 
 In looking at the code (MarkupAccumulator.cpp), they all suffer from one of
 two problems:
 
 1. The computed prefix used isn't properly used for the declaration.
 
 2. The generated namespace mappings aren't properly stored, scoped, or dealt
 with when they are inconsistent.
 
 There is an general assumption in the code that certain prefixes should
 always be used for certain namespaces.  Unfortunately, it does so without
 looking to see whether there is a conflict already in scope.  Also, when the
 namespace is not recognized and there is no prefix, a prefix needs to be
 generated for the serialization.
 
 Having written several robust XML Serializers for other projects, this can
 all be fixed in a straightforward way.  I've looked at the code and know
 what should be done.  The changes are probably modest.
 
 Unfortunately, I can't spend the time to directly write and test the code
 till probably after November.  :(
 
 I am certainly willing to help, explain my strategy, advise, test, etc. if
 there was another willing developer out there who would like to see these
 bugs closed.
 
 [1] http://www.mathjax.org/
 [2] https://bugs.webkit.org/show_bug.cgi?id=16739
 [3] https://bugs.webkit.org/show_bug.cgi?id=16496
 [4] https://bugs.webkit.org/show_bug.cgi?id=19121
 [5] https://bugs.webkit.org/show_bug.cgi?id=22958
 [6] https://bugs.webkit.org/show_bug.cgi?id=83056
 [7] https://bugs.webkit.org/show_bug.cgi?id=106531
 [8] https://bugs.webkit.org/show_bug.cgi?id=117764
 
 
 --
 --Alex Milowski
 The excellence of grammar as a guide is proportional to the paucity of the
 inflexions, i.e. to the degree of analysis effected by the language
 considered.
 
 Bertrand Russell in a footnote of Principles of Mathematics
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Fuzzinator, a mutation based web fuzzer

[Dean Jackson]

On 27/06/2013, at 2:48 AM, Renáta Hodován hodo...@inf.u-szeged.hu wrote:

 On 06/26/2013 12:30 AM, Zoltan Horvath wrote:
 Hey Reni,
 
 This project sounds cool! I think you will answer some of my questions in 
 your blog post, so I don't ask just one now...
 
 Do you know the date it's going to be published?
 
 Hopefully next week you can read it ;)

Is it out yet?

Dean

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

Re: [webkit-dev] Intent to Enable CSS Exclusions in Nightlies

[Dean Jackson]

On May 9, 2013, at 6:13 PM, Mark Rowe mr...@apple.com wrote:

 The only platform for which nightly builds are produced is OS X. Do you 
 intend to enable it for all platforms on tip of tree, or just for those from 
 which nightly builds are built?
 
 What I'm getting at is that I'm confused as to why you mentioned nightly 
 builds at all in your initial email if you're enabling it for all platforms.

We had a discussion about this at the contributor's meeting. I sent a draft 
resolution, which Bear linked to.

The idea is that people would send an email to the list when a feature is about 
to be enabled by default (at compile time, and at run time if they have such a 
flag, although we're trying to avoid that). It then is testable in Nightly 
builds.

So the goal is to allow people to use and test the feature. The fact that OS X 
is the only platform producing Nightly builds makes this a little weird, 
because it means you really only have to enable for OS X, but let's assume more 
platforms join the nightly party at some point.

Dean

 
 - Mark
 
 On May 9, 2013, at 17:49, Bear Travis betra...@adobe.com wrote:
 
 Hi Mark,
 
 Yes, my understanding of the policy [1] was that this was done at tip of 
 tree.
 
 -Bear
 
 [1] https://lists.webkit.org/pipermail/webkit-dev/2013-May/024850.html
 
 From: Mark Rowe mr...@apple.com
 Date: Thursday, May 9, 2013 5:25 PM
 To: Adobe betra...@adobe.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Intent to Enable CSS Exclusions in Nightlies
 
 
 On 2013-05-09, at 17:21, Bear Travis betra...@adobe.com wrote:
 
 Hi WebKit,
 
 The CSS Exclusions  Shapes [1] feature is currently behind a runtime flag 
 that I would like to enable by default in the WebKit nightlies.
 
 Can you clarify what it means to enable something by default in the WebKit 
 nightlies”? Do you mean enabling it by default on tip of tree?
 
 - Mark
 
 
 ___
 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] Enabling new features in WebKit + prefixing

[Dean Jackson]

This is a brief summary of yesterday's discussion at the contributors' meeting. 
If there is no strong disagreement here then I'll add this to the wiki.

New Features


- The rule of sending an email to webkit-dev when you're about to start work on 
a new feature remains in place. The idea here is that the community can support 
or object to the feature even being in the tree.

- Once the implementation of the feature is ready for use, send another email 
to webkit-dev announcing your intentions to enable the feature in nightly 
builds. How do you know when something is ready for use?

  + You want external developers to play with it and provide feedback (either 
to WebKit or a standards body)
  + Bugs and (some) crashes are ok, although it would be great if they were 
minimised.
  + Security and privacy issues are **NOT** ok. e.g. if the specification 
describes a security issue with no known solution, or if the known solution has 
not yet been implemented, then the feature should not be enabled.

If there is general agreement on the list then go ahead and enable the feature 
for nightlies. Port owners now have the responsibility to disable it for their 
shipping branches.

- If you're in a middle ground then you may consider enabling the feature for 
compilation, but protecting it behind a runtime flag that is disabled by 
default. Again, you should send an email to webkit-dev announcing this. An 
example of this would be a feature where security issues have been suggested 
but not confirmed.


Prefixing
-

- We still recommend prefixing on most new features while they are unstable. 
e.g. CSS properties and property values, if necessary. This is different from 
the Blink and Mozilla approach (which is to not prefix).

- We will now avoid prefixing on our file names. e.g. WebKitCSSMatrix should be 
just CSSMatrix. This might need some changes in the binding generators.

- If possible, prefer no prefixing in IDL and event names. Of course, for a 
truly new Web-exposed feature, this might be impossible.


Unprefixing
---

- We want to unprefix things as soon as we can. This relates back to the 
stability point above, which is hard to determine. Blink are trying to track 
stability here - [1].

- We think there are many things in WebKit that can now be unprefixed. Alexis 
did a great job unprefixing CSS transitions - follow his lead.

- We will continue to support the prefixed properties for some amount of time, 
decided on a case-by-case basis.

[1] http://www.chromestatus.com/features



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

[webkit-dev] Alexandru Chiculita is now a WebKit reviewer

[Dean Jackson]

I'm happy to announce that Alex is now a WebKit reviewer. Congratulations Alex!

Alex has done a lot of work in CSS Filters, amongst other places. For those who 
want to see him in action, here is his recent presentation at W3Conf:

   http://achicu.github.com/css-presentation/
   http://www.youtube.com/embed/D7gsp7RnDfc

Dean

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

Re: [webkit-dev] CSS filter behavior change - what is our policy?

[Dean Jackson]

On 15/03/2013, at 4:45 AM, Noam Rosenthal n...@webkit.org wrote:

 How do we go about rendering behavior changes that affect features that are 
 enabled on shipping browsers?
 
 I'm specifically referring to http://trac.webkit.org/changeset/139770 
 The brightness filter is enabled by default on chrome and Safari if I 
 remember correctly, and now pages that use brightness(0) would have their 
 element blackened, while before those elements would have been left 
 unchanged. This is of course correct so I can't claim it's a bug, but still 
 it would break existing websites, even if not many.
 
 Do we see CSS filters as being bleeding edge enough where we don't care? Do 
 we have a way to warn web developers about this? They'd basically have to 
 check Chrome/Safari/Other version in order to work around the problem, as 
 there's no media query for check if brightness behaves correctly.

I think in this case it was enough of a combination of bleeding edge + 
definite bug (where bleeding edge is determined by it being a prefixed property 
that isn't even at the candidate recommendation stage as well has young enough 
to not have widespread use). But you raise a good point - I would have been 
more reluctant to make this change as time passed.

Dean

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

Re: [webkit-dev] New web-facing canvas feature: opaque attribute

[Dean Jackson]

On 15/03/2013, at 6:50 AM, Dana Jansens dan...@chromium.org wrote:

 On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson d...@apple.com wrote:
 I'm not sure I like this proposal. Why is canvas special? Why doesn't img 
 get an opaque attribute (or flag)? Why not every element?
 
 There is ongoing work to infer opaqueness in every other kind of element when 
 possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634

Yes, I'd prefer to infer it rather than specify it. For example, I could infer 
that a canvas is opaque if it has a non-transparent CSS background-color.

Dean

  
 
 I don't think the performance benefit, which is mostly going to be on very 
 limited hardware, is worth changing the rendering model that is consistent 
 across every other part of the Web.
 
 Dean
 
 On 15/03/2013, at 4:53 AM, Stephen White senorbla...@chromium.org wrote:
 
 Hi Dirk,
 
 There have been at least five options considered, with contributions from 
 Chromium, Adobe and Mozilla so far.  The moz-opaque idea was first floated 
 by Robert O'Callahan from Mozilla, and Ian Hickson offered to spec it if 
 another browser vendor wanted to implement it.  I took him up on that offer, 
 and have made my humble effort to massage it into a concrete proposal in the 
 linked message above.
 
 After proposing it here, the alternative suggestion is to sync it up with 
 the WebGL syntax, and use a context creation object at getContext() time 
 rather than an attribute on the canvas element.  I have no strong feelings 
 about this either way, and I'm working on a patch to try out the WebGL 
 approach (I already have a WebKit patch which implements the 
 platform-independent parts of the opaque attribute approach).  However, if 
 we do go that way, I'd prefer not to make this proposal conditional on 
 changes to the WebGL spec, concerns which I've outlined over on what-wg.
 
 Stephen
 
 
 On Wed, Mar 13, 2013 at 12:30 PM, Dirk Schulze dschu...@adobe.com wrote:
 This is a very long thread and I did not see any conclusions or agreement on 
 this thread. Can you summarize the topic and the status on the acceptance 
 level please?
 
 Greetings,
 Dirk
 
 On Mar 13, 2013, at 9:15 AM, Stephen White senorbla...@chromium.org wrote:
 
  Hi WebKittens,
 
  I'm planning to implement the canvas opaque attribute, as proposed here: 
   
  http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html.
 
  This is an attribute that causes the allocation of an opaque backing store 
  for canvas, allowing optimizations at the time the canvas is composited 
  into the page, such as disabling blending and culling obscured content.  
  It is based on the moz-opaque attribute currently shipping in Firefox.
 
  I'll be placing the feature behind the build-time flag 
  ENABLE(OPAQUE_CANVAS).
 
  Let me know if you have any comments or concerns.
 
  Stephen
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 

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

Re: [webkit-dev] New web-facing canvas feature: opaque attribute

[Dean Jackson]

On 15/03/2013, at 7:45 AM, Kenneth Russell k...@google.com wrote:

 On Thu, Mar 14, 2013 at 1:38 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Thu, Mar 14, 2013 at 12:55 PM, Dean Jackson d...@apple.com wrote:
 
 
 On 15/03/2013, at 6:50 AM, Dana Jansens dan...@chromium.org wrote:
 
 On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson d...@apple.com wrote:
 
 I'm not sure I like this proposal. Why is canvas special? Why doesn't
 img get an opaque attribute (or flag)? Why not every element?
 
 
 There is ongoing work to infer opaqueness in every other kind of element
 when possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634
 
 
 Yes, I'd prefer to infer it rather than specify it. For example, I could
 infer that a canvas is opaque if it has a non-transparent CSS
 background-color.
 
 
 I like this approach. It means that developers don't have to explicitly use
 this feature to get the performance benefits.
 
 In fact, this is the preferred performance optimization approach on the Web.
 We don't provide explicit APIs to optimize performance. We make sensible
 APIs which allows us to implement more optimizations on common cases behind
 the scene.
 
 Not to put words in Stephen's mouth, but as I understand it, the main
 reason for adding this attribute is to enable higher-quality,
 LCD-antialiased text on canvases.
 
 Without it, it's impossible (or, at least, very difficult and low
 performance) to infer whether it's legal to use LCD antialiasing. Most
 ports' Canvas 2D implementations are GPU-accelerated, and it would be
 necessary to test all pixels underneath the text to ensure they are
 fully opaque before drawing the text. This would require a readback of
 the canvas's contents from the GPU, which would perform very poorly.

Yes, we get complaints about this all the time. But it seems to reenforce
my point that canvas is not special here. I expect more text to be 
rendered in non-canvas elements than canvas, and those elements could
be GPU-accelerated as well (they often are on Apple platforms).

However, your point does mean that simply testing the CSS background-color
will not work in all cases. For example, drawing a canvas into another
canvas. But in that case, unless you're drawing 1:1 and on a pixel boundary,
your subpixel antialiasing is going to be screwy anyway.

Dean

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

Re: [webkit-dev] New web-facing canvas feature: opaque attribute

[Dean Jackson]

On 15/03/2013, at 7:55 AM, Gregg Tavares g...@google.com wrote:

 
 
 
 On Thu, Mar 14, 2013 at 1:38 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Thu, Mar 14, 2013 at 12:55 PM, Dean Jackson d...@apple.com wrote:
 
 On 15/03/2013, at 6:50 AM, Dana Jansens dan...@chromium.org wrote:
 
 On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson d...@apple.com wrote:
 I'm not sure I like this proposal. Why is canvas special? Why doesn't img 
 get an opaque attribute (or flag)? Why not every element?
 
 There is ongoing work to infer opaqueness in every other kind of element 
 when possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634
 
 Yes, I'd prefer to infer it rather than specify it. For example, I could 
 infer that a canvas is opaque if it has a non-transparent CSS 
 background-color.
 
 The content of the canvas has to be blended with the background color so that 
 doesn't help optimization. If there's a background color you first have to do 
 a full blend of the contents of the canvas with the background color. Where 
 as if the canvas has no alpha then that step can be avoided.

We're probably getting a bit off the general topic here, but why don't you 
consider the background color as a fillRect(0, 0, width, height) on the empty 
canvas? As has been said, this doesn't change the behaviour of the 
painting/blending operations in the canvas itself, just how it is composited 
into the document.

I guess we should take this conversation to the HTML list.

Dean

 
  
 
 I like this approach. It means that developers don't have to explicitly use 
 this feature to get the performance benefits.
 
 In fact, this is the preferred performance optimization approach on the Web. 
 We don't provide explicit APIs to optimize performance. We make sensible APIs 
 which allows us to implement more optimizations on common cases behind the 
 scene.
 
 - R. Niwa
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 

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

Re: [webkit-dev] New web-facing canvas feature: opaque attribute

[Dean Jackson]

On 15/03/2013, at 8:06 AM, Gregg Tavares g...@google.com wrote:

 Because it's not the same as fillRect(0, 0, width, height) on an empty 
 canvas. The canvas itself has alpha (unless we add the option to not have it 
 as has been proposed). The contents of the canvas has to stay as the user 
 created it. If I draw with rgba(255,255,0, 0.5) I expect if I read data out 
 of the canvas or draw that canvas into another canvas I'll get that color, 
 not the color blended with the css background.

Yes, this is what I said in another email. Maybe I'm misunderstanding this, but 
if the main concern is to guarantee nice subpixel-antialiased text in canvas 
(but not anywhere else, such as the 99.99% of places where people draw text) 
then well, I'm still not convinced opaque is a great idea :) Especially not 
as an HTML attribute.

There are obviously ways to get around the problems you mentioned above (e.g. 
two buffers + two draws, or keeping a display list until someone wants to read 
out, etc) and, even more obviously, they have significant problems. It just 
seems to me that we're trying to address the issue of wanting nice looking text 
with a very specific solution on one element. Maybe we should consider what we 
could do across the platform?

Dean


 So, the canvas has to be blended if there's alpha. There's no magic getting 
 around that. The only way around it is to give the user a way to say no 
 alpha.



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

Re: [webkit-dev] New web-facing canvas feature: opaque attribute

[Dean Jackson]

On 15/03/2013, at 12:49 PM, Vladimir Vukicevic vladi...@mozilla.com wrote:

 On 3/14/2013 5:23 PM, Dean Jackson wrote:
 On 15/03/2013, at 8:06 AM, Gregg Tavares g...@google.com wrote:
 Because it's not the same as fillRect(0, 0, width, height) on an empty 
 canvas. The canvas itself has alpha (unless we add the option to not have 
 it as has been proposed). The contents of the canvas has to stay as the 
 user created it. If I draw with rgba(255,255,0, 0.5) I expect if I read 
 data out of the canvas or draw that canvas into another canvas I'll get 
 that color, not the color blended with the css background.
 Yes, this is what I said in another email. Maybe I'm misunderstanding this, 
 but if the main concern is to guarantee nice subpixel-antialiased text in 
 canvas (but not anywhere else, such as the 99.99% of places where people 
 draw text) then well, I'm still not convinced opaque is a great idea :) 
 Especially not as an HTML attribute.
 
 The main concern for us was performance -- if you have a large canvas, 
 whether on mobile or on desktop, it is beneficial to tell the browser that it 
 is guaranteed opaque, and it can allocate backing store and draw it as such.  
 There's no way to infer that... checking the CSS background doesn't work for 
 the reasons Gregg outlined.  Basing it on a fillRect() of the entire canvas 
 with a non-opaque color doesn't work, because there are blend modes that will 
 punch holes in alpha.  So you can have a really complicated heuristic to try 
 to get it right and miss in a bunch of cases, or you can just make it work 
 in the general case (have alpha), and let developers who are trying to 
 squeeze the last bit of performance out of the platform give you the hints 
 you need.  We opted for the latter approach.

Fair enough. I'm not arguing against the benefits - as I said, we get the 
request all the time. I'm just hoping there is a way we can do this for more 
elements than just canvas. 

If we do decide this is canvas only, I don't like an attribute on the element. 
That seems too presentational. It's the script that decides what is drawn into 
canvas, so the script should probably decide whether or not to tell the 
implementation it might be able to optimise by not allocating an alpha channel. 
So count me in the camp that agrees with context attributes.

Just calling it alpha is also a bit confusing, because alpha will still work 
within the canvas itself.

Dean

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

Re: [webkit-dev] sln files with wrong line endings

[Dean Jackson]

On 14/02/2013, at 6:23 pm, Vivek Galatage vivekgalat...@gmail.com wrote:

 I had the same problem and was able to trace the reason for this.
 
 http://stackoverflow.com/questions/1889559/git-diff-to-ignore-m
 
 Its the ^M characters at the EOL. git diff --ignore-space-at-eol ignores the 
 change from the diff.
 
 Something similar was happening with 
 http://trac.webkit.org/browser/trunk/Source/WTF/WTF.vcproj/WTF.sln and its 
 changelog says it.

FWIW, I’ve hit something similar to this when rsyncing repositories between 
machines. All of a sudden, that WTF.sln file is marked as modified, but git 
diff can’t see the change.

I “fix it by deleting the the .git/index and then doing a git checkout.

Dean

 
 
 
 On Thu, Feb 14, 2013 at 12:40 PM, Christophe Dumez - SISA 
 ch.du...@sisa.samsung.com wrote:
 Hi,
 
 The same thing has just happened to me. I managed to get rid of the changes 
 to this file by doing:
 git reset --hard
 
 Kr,
 Christope Dumez.
 
 From: webkit-dev-boun...@lists.webkit.org 
 [webkit-dev-boun...@lists.webkit.org] on behalf of Eric Seidel 
 [e...@webkit.org]
 Sent: Thursday, February 14, 2013 08:23
 To: WebKit Development
 Subject: [webkit-dev] sln files with wrong line endings
 
 We've had this come up before, but I figure I should ask on webkit-dev
 to see if we have a solution. :)
 
 Right now the Tools/DumpRenderTree/DumpRenderTree.vcxproj/DumpRenderTree.sln
 file is in some sort of bad state such that my Git checkout can't seem
 to not-modify the file.
 
 I'm not sure if it's a Git bug, or a repository config bug.
 
 But it means I can't seem to produce patches w/o modifying this file. :(
 
 https://bugs.webkit.org/attachment.cgi?id=188263action=review
 
 Thoughts?
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Using ninja (was Re:Common build system (was Re: WebKit Wishes))

[Dean Jackson]

OK, this sounds fantastic. And I've noticed how much faster Chromium
incrementally builds using ninja when I've done that.

So, ignoring the discussion of a single build system for a moment, how
can I, as a developer using the OS X + WK2 port, living mostly
in Xcode for editing and debugging, use ninja? I need the idiot's
guide :)

(Note: I am an idiot, but not so much an idiot to realise that the
answer involves lots of work and probably updating some old GYP
files that you and Adam were testing with, etc etc. I'm just selfishly
thinking that cutting even 30s off each incremental rebuild would make
me so much happier that I'd be willing to put up with other
inconveniences.)

Dean

On 03/02/2013, at 4:54 PM, Eric Seidel e...@webkit.org wrote:

 +1
 
 Ninja is beyond-words amazing.  http://martine.github.com/ninja/  For
 better or worse, it is not designed to use human-editable build files,
 but rather to be used by a meta build system, like GYP or CMake.  So
 using ninja is really an orthogonal discussion to the single build
 system discussion for WebKit. :)
 
 Were the WebKit project to convert to using a single meta-build
 system, ninja would become an option many users might choose.  I'm
 told most Chromium hackers have GYP set to output ninja files these
 days, with the exception of some folks who still want the MSVC build
 environment. For WebKit ports already using CMake, they should
 definitely try ninja today!
 
 
 Anyway, my wish was not about arguing for a specific build solution.
 I'm instead noting that for the project to continue to move quickly,
 we need to stop needing to edit 8 build systems for every file
 move/addition.  Whether that's GYP or CMake or something else, I don't
 really care.  Adam and I tried GYP-for-WebKIt a while back.  But any
 of these solutions will require buy-in from Apple, as they will have
 to do the largest amount of work converting to use something other
 than XCode.
 
 
 On Sat, Feb 2, 2013 at 8:20 PM, Nico Weber tha...@chromium.org wrote:
 On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth aba...@webkit.org wrote:
 Ninja has extremely fast incremental builds and can be generated by
 GYP.  Here are some stats from a year ago:
 
 https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
 
 Ninja has gotten even faster since then.  If you're interested in
 trying it out, you can play around with incremental builds of the
 Chromium port on Mac or Linux.
 
 You can also look at the build output from the chromium bots.
 
 Empty build in 1s:
 http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio
 Build with a few files changed in 15s:
 http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio
 
 …and this is on fairly slow bots. On my SSD-equipped laptop, I can do
 incremental rebuilds of all of chrome after touching one (cpp or mm)
 file in 2-6s.
 

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

Re: [webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d

[Dean Jackson]

On 30/01/2013, at 12:46 PM, Dirk Schulze dschu...@adobe.com wrote:

 Would it be possible to clean up the code a bit more and remove the prefixed 
 attributes?

I don't think they should be removed yet. As you mentioned, it's been 16 months 
which is at least one Safari release cycle. I'd prefer that we give a console 
warning for now.

Dean


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

Re: [webkit-dev] Enabling unprefixed CSS Transitions by default.

[Dean Jackson]

Related: when the unprefixed transitions are enabled by default, we plan
to make a long-overdue blog post on Recent Updates to Transitions and 
Animations
where recent means about 2 or 3 years :)

http://www.webkit.org/blog/?p=2233preview=true

The idea is that it would cover all the interesting things we've added, even if
we think most people know about them. Feel free to edit the draft (if that's 
possible
- otherwise email me), especially if there are features we've forgotten.

Dean


On 30/01/2013, at 8:03 AM, Alexis Menard ale...@webkit.org wrote:

 Hi,
 
 Last month I started working on supporting unprefixed CSS Transitions
 in WebKit. Today this work is guarded behind
 CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in
 trunk (but disabled in Chrome and probably release branches of other
 ports). After various patches we (Dean Jackson and myself) feel
 confident that the work on the transitions is ready for prime time. We
 still have bugs open in our bug tracker but that doesn't block the
 unprefixed version to go live.
 
 So the proposal is the following one :
 - Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to
 CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for
 unprefixing the animations and the transforms (that I plan to focus
 after this).
 - Ship CSS Transitions unprefixed enabled by default with no feature
 flag to disable it.
 
 My proposal is tracked here : https://bugs.webkit.org/show_bug.cgi?id=108216
 
 We can also be proud to say our implementation is maybe the most
 complete one (thanks to the various people involved).
 
 On a side note the usage of prefixed/unprefixed version is monitored
 through the FeatureObserver so we can later in the future have an idea
 of the usage and maybe remove the prefixed support.
 
 Thoughts?
 
 Patched landed :
 http://trac.webkit.org/changeset/141119
 http://trac.webkit.org/changeset/140560
 http://trac.webkit.org/changeset/140448
 http://trac.webkit.org/changeset/140010
 http://trac.webkit.org/changeset/139922
 http://trac.webkit.org/changeset/139762
 http://trac.webkit.org/changeset/139200
 http://trac.webkit.org/changeset/139106
 http://trac.webkit.org/changeset/139070
 http://trac.webkit.org/changeset/138728
 http://trac.webkit.org/changeset/138721
 http://trac.webkit.org/changeset/138184
 
 Thanks.
 
 -- 
 Software Engineer @
 Intel Open Source Technology Center
 ___
 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] Keeping up with new additions to canvas

[Dean Jackson]

As well as the other suggestions, you can look at bugs in the Canvas component. 
e.g.

https://bugs.webkit.org/show_bug.cgi?id=82790

We should probably have a owner bug to collect all the HTML5-ish Canvas changes.

Dean

On 07/01/2013, at 11:18 PM, RGraph.net support richard.he...@gmail.com wrote:

 Hi,
 
 Is watching this mailing list the best way to keep up-to-date with new
 additions to the WebKit canvas implementation (such as the canvas Path
 object or hit regions)? Or perhaps there's an  announcements list too?
 
 Thanks!
 
 -- 
 Richard
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Keeping up with new additions to canvas

[Dean Jackson]

On 09/01/2013, at 9:26 AM, Dirk Schulze dschu...@adobe.com wrote:

 
 On Jan 8, 2013, at 11:37 AM, Dean Jackson d...@apple.com wrote:
 
 As well as the other suggestions, you can look at bugs in the Canvas 
 component. e.g.
 
 https://bugs.webkit.org/show_bug.cgi?id=82790
 
 Marked as duplicate ;)

I noticed you forward-duplicated. At Apple we try not to do this, but is
there a convention for WebKit?

Dean

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

Re: [webkit-dev] Unprefixing CSS Animation, Transitions and Transform.

[Dean Jackson]

On 13/12/2012, at 12:49 AM, Alexis Menard ale...@webkit.org wrote:

 I would like to announce that I will start the work to unprefix CSS
 Animations, Transitions and Transform. It may sounds quick to do but
 it's not, there are few things to do before we can unprefix and
 unleash them to the world (e.g. -webkit-perspective accept valueless
 number but perspective doesn't) and we need to make few fixes to do to
 make sure we are compliant with the spec while keeping the behaviour
 as-is for the current unprefixed version. Also there is few
 unimplemented things.
 
 The bug is tracked here : https://bugs.webkit.org/show_bug.cgi?id=93136
 
 In the following days I will add new bugs as blocker to this one to
 track the work left to do. If you think of something missing feel free
 to open a new bug and mark is as blocker for 93136. Please put a
 detailed description on the bug.
 
 I will land the work behind a feature flag
 CSS_TRANSFORM_ANIMATION_TRANSITION_UNPREFIXED (I accept alternatives
 on the name :), I believe three feature flags for that is overkill)
 enabled by default on trunk as it is important for me to get the bots
 running the code. You can turn off the feature in your release
 branches up until the work is done (maybe afterwards we should even
 remove the feature flag).

Please start with Transitions. They are closer to ready than Animations
and especially Transforms (as you've noted - it needs a lot of work).

Good luck!

Dean

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

Re: [webkit-dev] WebKit + OpenCL

[Dean Jackson]

On 24/11/2012, at 10:56 AM, Dirk Schulze dschu...@adobe.com wrote:

 
 On Nov 23, 2012, at 2:43 PM, Andreas Kling akl...@apple.com wrote:
 
 Hi folks,
 
 Do we really think it's a good idea to add yet another implementation of 
 filters?
 
 We already have generic, NEON-optimized and WTF::ParallelJobs (which 
 includes generic, OpenMP and libdispatch backends) implementations of this 
 code, and now we're adding OpenCL too.
 
 On the WebKit Project Goals page 
 http://www.webkit.org/projects/goals.html, it states that:
 
 WebKit is an engineering project not a science project. For new features to 
 be adopted into WebKit, we strongly prefer for the technology or at least 
 the use case for it to be proven.
 
 Correct me if I'm wrong, but we don't see much use of these features on the 
 web. I understand that there's a bit of a chicken/egg problem where a 
 feature won't be interesting to content creators until it performs well 
 enough, but it seems like we could at least decide on a single path forward 
 instead of repeatedly forking the code.
 
 I designed the current SVG Filters implementation in a way that hopefully 
 make it possible to implement HW accelerated filters on top of it. Skia and 
 NEON already go this path. I am not defending the OpenCL implementation for 
 SVG Filters per se, but different platform dependent solutions were expected 
 and wanted. Software filters were designed to be a fallback if an 
 implementation does not provide HW acceleration (yet). I hope that we see a 
 Core Image version of filters in the near future as well. The code for that 
 is in the history of the repository already.

FWIW, we currently have an active Core Image filter path on OS X (only for the 
filter shorthands).

Dean

 
 Greetings,
 Dirk
 
 
 -Kling
 
 On Nov 21, 2012, at 7:30 PM, Zoltan Herczeg zherc...@webkit.org wrote:
 
 Hi,
 
 we start upstreaming some OpenCL optimizations into WebKit.
 
 This is the master bug:
 https://bugs.webkit.org/show_bug.cgi?id=70099
 
 Regards,
 Zoltan
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Adding Web Animations to WebCore

[Dean Jackson]

Hi Brian,

On 23/11/2012, at 12:01 AM, Brian Birtles bbirt...@mozilla.com wrote:

 * At least in its current form, it is overengineered and unusable. An 
 animation API should focus on ease of use, not combining every conceivable 
 animation concept ever invented.
 
 I'd genuinely appreciate your help with regards to identifying specific 
 concerns and unnecessary features. As for usability, I think the video we 
 released shows it's not entirely unusable.[1]
 
 If the spec seems long it's simply because it's explicitly specifying much of 
 what is left unspecified in SVG and CSS. It's predominantly composed of 
 features already implemented in CSS and SVG. The number of new features is 
 fairly small.
 
 That said, I think there are some parts of the API we can tighten up and 
 possibly drop. If you have specific suggestions I would really value your 
 comments at public...@w3.org (subject '[web-anim] ... ').

We're planning to send in some comments this week.

 Dean Jackson wrote:
 
 As well as Maciej's concerns, I'd like to add that we already have three 
 non-interoperable animation technologies in WebKit (SMIL, CSS and rAF). I 
 think we need to clean this up before adding any more complexity.
 
 As I'm sure Dean is well aware, the primary purpose of this specification is 
 to unify the SMIL and CSS models. In Gecko I anticipate replacing much of our 
 SMIL implementation with this API as well as parts of CSS. I see implementing 
 Web Animations as an opportunity to unify this code but you know your 
 codebase best and how best to stage the development.

Yes. My point was that we shouldn't simply Add Web Animations to WebCore 
before putting in the required effort on our existing code. We definitely need 
some cleanup, and I'm worried about unifying around an API that isn't stable.

 I agree that there is certainly some tidying up in order. In fact, in my 
 opinion, quite a lot. Development stalled briefly whilst some of us had other 
 duties to attend to but now we're back on deck and looking to get this into 
 FPWD-ready shape by the end of the year so your feedback is very precious. 
 For example, if you have a preference for abbreviated names or not, then by 
 all means please send feedback to public-fx.
 
 This doesn't feel baked enough.
 
 I tend to agree (just look at how many TODOs there still are).
 
 It's obviously up to you to decide when is the right time to start 
 implementing. In Doug's defence I'd say he is well aware of how much this is 
 still in flux.
 
 
 In summary I just want to acknowledge that there is still much work to be 
 done on Web Animations but that it should start moving more quickly in the 
 coming weeks. As a result, your feedback is particularly valuable at this 
 time.
 
 I also want to apologise if this caught anyone by surprise. We've been 
 posting to public-fx but I realise that not many people monitor that list. 
 I'll try to send a note to www-style in the coming days to alert anyone else 
 who might be interested.

We'll comment on the W3C list rather than here, but in brief (for those who 
don't want to subscribe to another list):

- we'd prefer a much more incremental approach
- we feel this bites off way too much for a V1.0 API (trying to address 
everything at once)
- we'd like to see more declarative support

Dean


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

Re: [webkit-dev] Adding Web Animations to WebCore

[Dean Jackson]

On Nov 8, 2012, at 4:11 PM, Douglas Stockwell dstockw...@chromium.org wrote:

 I wanted to let you know that work has begun on implementing Web Animations 
 in WebKit. New code for this effort will be landed behind the ENABLE_WEB_ANIM 
 feature define and a runtime setting. We expect to be turning this define on 
 for Chromium buildbots so there will be build and test coverage as the new 
 functionality is added.
 
 The current Editor’s Draft for Web Animations is available at: 
 https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html
 
 The implementation will be tracked by a meta bug: 
 https://bugs.webkit.org/show_bug.cgi?id=101660

As well as Maciej's concerns, I'd like to add that we already have three 
non-interoperable animation technologies in WebKit (SMIL, CSS and rAF). I think 
we need to clean this up before adding any more complexity.

I do very much support the idea of an animation API though.

Dean


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

Re: [webkit-dev] Unprefixing requestAnimationFrame

[Dean Jackson]

Me too. Please don't just remove the prefix - we need a period of time where we 
support both prefixed and unprefixed.

Dean

On 12/10/2012, at 6:58 PM, Maciej Stachowiak m...@apple.com wrote:

 
 I agree with this position as well. It seems good to have a transition period 
 and to gather some data.
 
  - Maciej
 
 On Oct 11, 2012, at 9:59 PM, Darin Fisher da...@chromium.org wrote:
 
 I agree with what Adam wrote in 
 https://bugs.webkit.org/show_bug.cgi?id=99116#c5.  Even if a lot of sites 
 will magically failover to the unprefixed API, we can't know for sure that 
 this change won't break sites.  We need to give them a chance to update.  (I 
 don't know if one Chrome release cycle will be enough.)
 
 Why not be conservative here?
 
 -Darin
 
 
 On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen simon...@chromium.org 
 wrote:
 I've posted a patch to remove the webkit prefix from 
 requestAnimationFrame. [1] The question is whether or not to continue to 
 support the prefixed version. I propose dropping it for the following 
 reasons:
 
 1. We're changing the callback semantics to match the spec. [2]
 
 2. IE10 is shipping with this unprefixed. [3]
 
 3. Toolkits already use the unprefixed version. [4]
 
 4. The advice on the internet recommends everyone use the polyfill 
 technique. [5]
 
 I'm curious what everyone else thinks.
 
 James
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=99116
 [2] https://bugs.webkit.org/show_bug.cgi?id=66683
 [3] http://caniuse.com/#feat=requestanimationframe
 [4] https://gist.github.com/1579671
 [5] https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Experimental features in Safari Web Inspector

[Dean Jackson]

On 26/09/2012, at 6:15 PM, Mihai Balan miba...@adobe.com wrote:

 We have recently been working on some WebInspector features related to CSS 
 Regions. Most of the work was done using Chromium's Developer Tools, as this 
 allowed us to have this work under a DevTools experiment flag.
 Now that this work has reached a more stable state, it would be useful to 
 test it under Webkit/Safari, too.
  
 So, my question for you is this (ok, that's actually two questions):
  
 1. Is there a way to enable / disable features in Safari DevTools the way 
 it is in Chromium's? It doesn't have to be a GUI, though

No.

 2. What is the general policy for WebInspector features? How and when do 
 they get enabled by default, at least in the nightlies? (Since regions are 
 already enabled by default in the nightlies, IMO it would make sense to have 
 the web inspector regions features, too)

Safari's Web Inspector lives in the Safari.app, so nightlies do not 
automatically get new features. The best thing to do is implement it in the 
Open Source inspector (as you've done) and Apple will (hopefully) merge it in. 
You can also file a bug at bugreporter.apple.com explicitly requesting it.

Dean

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

Re: [webkit-dev] ANGLE on QNX / non-x11 unixoids

[Dean Jackson]

On Sep 4, 2012, at 10:19 AM, noam.rosent...@nokia.com wrote:

 A
 On Sep 4, 2012, at 8:34 AM, ext Konstantin Tokarev annu...@yandex.ru wrote:
 
 
 To get it compiling, I had to patch ANGLE source code and Simon Hausmann 
 told
 me he is not comfortable in reviewing these patches. So here I am asking for
 how to proceed. Should I first try to upstream these patches to ANGLE 
 somehow?
 
 Why do you compe ANGLE? Does QNX support DirectX?
 
 ANGLE is used to validate and compile WebGL shaders to OpenGL/OpenGL ES2, so 
 it's a dependency regardless of DirectX.

And, as of a recent patch from the Adobe team, it's also used to rewrite the 
content of CSS shaders and add the code which blends the result into the page.

Dean


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

Re: [webkit-dev] Adding CSS blending to WebKit

[Dean Jackson]

On 21/07/2012, at 8:50 AM, Rik Cabanier caban...@gmail.com wrote:

 I'm planning on adding CSS blending to WebKit: 
 https://bugs.webkit.org/show_bug.cgi?id=91908
 We already have a working prototype and I will bring it over as a couple of 
 patches.
 
 We did a couple of write-ups on this feature:
 https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
 http://blogs.adobe.com/webplatform/2012/04/04/bringing-blending-to-the-web/
 http://blogs.adobe.com/webplatform/2012/07/17/new-blending-features-in-css/
 http://html.adobe.com/webstandards/csscompositing/
 
 
 This is my first time contributing so let me know if there is another process 
 I should follow.

Rik didn't mention this will be protected by a feature flag: 
ENABLE_CSS_COMPOSITING seems to be the suggestion.

Dean

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

Re: [webkit-dev] Adding CSS blending to WebKit

[Dean Jackson]

On 28/07/2012, at 11:25 AM, Rik Cabanier caban...@gmail.com wrote:

 I changed all the project files that were modified for the CSS_SHADERS define 
 but my patch was denied because it didn't modify the makefiles for every 
 single platform.
 Do I really have to modify all of them?

Let's discuss it in the bug so that future webkittens will be able to find it.

https://bugs.webkit.org/show_bug.cgi?id=92553

Dean


 
 Rik
 
 On Fri, Jul 27, 2012 at 6:06 PM, Dean Jackson d...@apple.com wrote:
 
 On 21/07/2012, at 8:50 AM, Rik Cabanier caban...@gmail.com wrote:
 
 I'm planning on adding CSS blending to WebKit: 
 https://bugs.webkit.org/show_bug.cgi?id=91908
 We already have a working prototype and I will bring it over as a couple of 
 patches.
 
 We did a couple of write-ups on this feature:
 https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
 http://blogs.adobe.com/webplatform/2012/04/04/bringing-blending-to-the-web/
 http://blogs.adobe.com/webplatform/2012/07/17/new-blending-features-in-css/
 http://html.adobe.com/webstandards/csscompositing/
 
 
 This is my first time contributing so let me know if there is another 
 process I should follow.
 
 Rik didn't mention this will be protected by a feature flag: 
 ENABLE_CSS_COMPOSITING seems to be the suggestion.
 
 Dean
 
 

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

Re: [webkit-dev] Delaying Applying CSS Effects

[Dean Jackson]

On 25/07/2012, at 6:09 AM, Keyar Hood ke...@chromium.org wrote:

 I am working on https://bugs.webkit.org/show_bug.cgi?id=90405
 
 The problem is that when doing SVG filters in CSS using URL references, if 
 the target SVG filter is after the element that the filter is to be applied 
 to (the filtered element), then the filter will not be applied.
 
 Looking at the code, a getElementByID() call is made when looking for the 
 target SVG filter. However, this does not work when the target SVG filter is 
 after the filtered element. I believe this is because the DOM element for the 
 target SVG filter does not exist yet.
 
 I am wondering if there is some way to delay resolving these CSS effects 
 until after the DOM has finished loading.

Your analysis sounds right. I think we'll have to do exactly that: delay 
calling buildFilterEffectRenderer until the document has loaded.

Dean


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

Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore

[Dean Jackson]

On 07/06/2012, at 10:07 AM, Annie Sullivan sulli...@chromium.org wrote:

 Oops, forgot to reply-all.
 
 On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan sulli...@chromium.org wrote:
 On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote:
 
 Our past experience with this sort of thing at Apple is that it led to bugs 
 we didn’t find until after we shipped “final” software because they did not 
 show up during earlier testing. Since then, we’ve gone out of our way to 
 avoid differences, since one of the main things we want to do with 
 non-final builds is to approximate the final releases as closely as 
 possible to get useful testing.
 
 To oversimplify, website developers notoriously make mistakes with these 
 types of attributes doing things like version and OS checks, leading to 
 website incompatibilities.
 
 Yes, this is definitely a concern we have as well.
 
 Maybe you could make your case for the usefulness of the attribute?
 
 The problem we're experiencing in Chrome is for sites that collect
 usage data--it turns out there's a selection bias caused by users who
 opt in to our canary, dev, and beta channels.
 
 The specific case I'm looking at right now is sites collecting
 performance data from their user base. We'd love for these sites to be
 able to report regressions they see in Chrome's performance as early
 as possible. But it turns out users on different channels actually
 show different performance characteristics. Beta users seem to have
 faster machines, for example. So in order to compare two versions of
 Chrome, we need to compare data from users on the same release
 channel. So we'd like sites who collect performance information to be
 able to collect the build type in order to do that comparison.
 
 We considered a few alternatives:
 1) Adding a marker in the user agent string that indicates the
 channel. The problem with this is that there is a lot of very fragile
 code in the wild which parses user agent strings and breaks at the
 slightest change. For example, code that parses Opera 10 as Opera 1.
 2) Updating the version number as Chrome advances from canary to dev
 to beta to stable, or encoding the build type in one of the octets of
 the version number. The problem with this is that there's a big
 possibility of sites that do version checking accidentally turning off
 features on some channels. There are also a lot of things that we *do*
 want to track across release channels for a specific version, like
 bugs. So changing the version number could cause confusion there.
 3) Sending an x-buildtype header. If we do this on every request,
 it's a lot of bloat. We can't restrict it to requests that send a
 corresponding x-tell-me-the-buildtype request header because most
 metrics collection libraries send their metrics in an image request,
 so they can't send custom headers.

navigator.buildType might address your particular problem, but introduces a 
significant risk of future issues. I can imagine keen web authors adding 
features based on detecting nightly or beta that then break in final.

This is similar to prefixing CSS properties which, as you probably know, is an 
extremely hot discussion topic right now in the community. I don't think people 
will be especially excited for another potential point of failure.

Dean


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

Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore

[Dean Jackson]

On 07/06/2012, at 12:53 PM, Annie Sullivan sulli...@chromium.org wrote:

 On Thu, Jun 7, 2012 at 3:43 PM, Dean Jackson d...@apple.com wrote:
 
 On 07/06/2012, at 12:05 PM, Annie Sullivan sulli...@chromium.org wrote:
 
 In many browsers in the past, it's been
 pretty easy to determine from a and b characters in the user agent
 of many browsers which builds are alpha and beta, and I haven't
 heard of bugs caused specifically by checking for build type there.
 
 So why not just do that then?
 
 While it's nice that web developers don't seem to be using the build
 type info in the user agent string in their code, user agent parsing
 code is still very brittle. Some browsers, like Firefox, have had
 buildtype characters in the user agent string for many years, so
 parsing code can handle things like Firefox/14.0a2. But Chrome
 hasn't ever changed its version format, so we're worried about
 breaking user agent parsers.

Right, I understand that issue. But I don't think replacing something
flakey and problematic with something that could be equally flakey and
problematic is a big win.

Your original problem was:

 We'd love for these sites to be able to report regressions they see in 
 Chrome's performance as early as possible. But it turns out users on 
 different channels actually show different performance characteristics. Beta 
 users seem to have faster machines, for example. So in order to compare two 
 versions of Chrome, we need to compare data from users on the same release 
 channel. So we'd like sites who collect performance information to be able to 
 collect the build type in order to do that comparison.

That sounds exactly like User Agent detection to me. You want
to detect build version and type.

I still think there are similarities to prefixing. The Web community
(not just WebKit) is making a lot of noise about how being able to
detect browsers might seem like a good idea at first but ends up
causing longer-term headaches.

By the way, I don't feel strongly about this. I'm just pointing
out that I don't see any benefit and that what looks like a
small change in metadata has just as important consequences
as a significant technical change.

Dean

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

Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore

[Dean Jackson]

On 07/06/2012, at 1:10 PM, Adam Barth aba...@webkit.org wrote:

 On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.org
 wrote:
 
 I wanted to let you know that I plan to add support for
 navigator.buildType (e.g., nightly, beta, final) to WebKit. This
 feature isn't on the standards track (but neither are a bunch of other
 similar properties on Navigator). This feature will be behind the
 ENABLE(NAVIGATOR_BUILDTYPE) feature define. See:
 https://bugs.webkit.org/show_bug.cgi?id=88358
 http://html.spec.whatwg.org/#navigator
 
 What is the rationale for adding this property on the navigator object
 instead of the chrome object we also expose if your'e not expecting this
 property to be ever standarized?
 
 Generally, we avoid implementing web visible features via the chrome
 object because that makes them Chrome-proprietary.  In this case, it
 seems entirely reasonable for other browsers (e.g., Firefox) to want
 to implement this feature.  By putting it on navigator, we invite them
 to implement it as well.

But the original message said:

 I wanted to let you know that I plan to add support for navigator.buildType 
 (e.g., nightly, beta, final) to WebKit. This feature isn't on the 
 standards track (but neither are a bunch of other similar properties on 
 Navigator)

If you don't want it to be Chrome or WebKit-proprietary, and you're inviting 
other browsers to implement it, then you should probably speak to them and the 
rest of the community up front.

It definitely would be much nicer if User Agent was exposed as a bunch of 
neatly organised JavaScript properties on the navigator object. Of course then 
we'd eventually have issues similar to what are now parsing errors. Who says a 
browser won't want to add alpha or release-candidate to the list above. 
This is going to be flakey no matter what.

I should stop replying now because I really don't care anywhere near as much 
about this as I'm suggesting by all my email :)

Dean


 
 The feedback the WebKit community at large has given us so far appears to be
 strictly negative about adding this to the navigator object.
 
 The mechanism for implementing the feature doesn't really affect the
 arguments that folks are making on this thread.  If we decide that the
 feature is worth implementing, we should implement it on navigator.
 If the feature is not worth implementing, we shouldn't implement it on
 the chrome object either.
 
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Anyone using NEON code on ARM builds?

[Dean Jackson]

Hi Jonathan,

On 21/03/2012, at 12:56 AM, Jonathan Kliegman wrote:

 On Wed, Mar 14, 2012 at 2:14 PM, Dean Jackson d...@apple.com wrote:
 Hi,
 
 There are three files with embedded NEON code to speed up filters:
 
 ./Source/WebCore/platform/graphics/filters/arm/FECompositeArithmeticNEON.{h,cpp}
 ./Source/WebCore/platform/graphics/filters/arm/FEGaussianBlurNEON.{h,cpp}
 ./Source/WebCore/platform/graphics/filters/arm/FELightingNEON.{h,cpp}
 
 Are any ARM ports using this? (would require SVG and FILTERS both enabled) If 
 so, could you contact me? Off list is fine.
 
 I see the code came from Felician Marton via Zoltan reviewed by Dirk (eg. 
 https://bugs.webkit.org/show_bug.cgi?id=65522) and it's been very slightly 
 touched for some chromium build issues.
 
 Chrome OS has ports that use NEON and has SVG and FILTERS both enabled so 
 this would still be used.

Excellent!

Zoltan and I have been chatting offline a bit. I was testing compilation on 
Darwin/iOS ARM and running into a few issues. The first was about alignment 
errors from the compiler. The second was some linking issues, for example:

 https://bugs.webkit.org/show_bug.cgi?id=81568

Is there someone (you?) on the Chrome team I should CC on any bugs raises?

Dean


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

[webkit-dev] Anyone using NEON code on ARM builds?

[Dean Jackson]

Hi,

There are three files with embedded NEON code to speed up filters:

./Source/WebCore/platform/graphics/filters/arm/FECompositeArithmeticNEON.{h,cpp}
./Source/WebCore/platform/graphics/filters/arm/FEGaussianBlurNEON.{h,cpp}
./Source/WebCore/platform/graphics/filters/arm/FELightingNEON.{h,cpp}

Are any ARM ports using this? (would require SVG and FILTERS both enabled) If 
so, could you contact me? Off list is fine.

I see the code came from Felician Marton via Zoltan reviewed by Dirk (eg. 
https://bugs.webkit.org/show_bug.cgi?id=65522) and it's been very slightly 
touched for some chromium build issues.

Thanks,

Dean


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

Re: [webkit-dev] ProgressEvents for Images

[Dean Jackson]

On 17/01/2012, at 10:41 AM, Bear Travis wrote:

 A group of us at Adobe has been looking into adding support for 
 ProgressEvents 
 to images.  The overall goal is to simplify image download progress reporting 
 by supporting roughly the same progress events as XHR and the File API for 
 image elements.   For example one could connect an image to a progress 
 element 
 like this:
 
 img id=image src=sample.jpg
 onloadstart=showProgressBar()
 onprogress=updateProgressBar(event)
 onloadend=hideProgressBar()/
 
 Developers have taken various tacks to enable progress reporting, for example 
 in some cases XHR can be used to download image files.  Max Vujovic just 
 published a blog about the practicalities of doing so: 
 http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/.  We 
 think it would be preferable to provide support for image progress events 
 directly.

I think this would be extremely useful. It would require a proposal to
W3C or WHATWG though.

Dean

 
 We're working on a prototype implementation for WebKit and have filed a bug 
 that explains what we're up to in a little more detail: 
 https://bugs.webkit.org/show_bug.cgi?id=76102
 
 It's probably worth pointing out that the beforeload event, which is 
 currently 
 under discussion, addresses a different use case.  Our proposal is intended 
 to 
 enable applications to give the user feedback about image download progress, 
 it's not intended to enable security or efficiency by preemptively blocking 
 or 
 transforming image downloads.
 
 We'd appreciate feedback on this proposal.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)

[Dean Jackson]

On 04/12/2011, at 6:06 PM, Adam Barth wrote:

 On Mon, Oct 24, 2011 at 9:51 PM, Adam Barth aba...@webkit.org wrote:
 Personally, I don't believe it's possible to implement this feature
 securely, at least not using the approach prototyped by Adobe.
 However, I would love to be proven wrong because this is certainly a
 powerful primitive with many use cases.
 
 I spent some more time looking into timing attacks on CSS Shaders.  I
 haven't created a proof-of-concept exploit, but I believe the current
 design is vulnerable to timing attacks.  I've written up blog post
 explaining the issue:
 
 http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html

Thanks for writing this up.

I'm still interested to know what the potential rate of data leakage is.
Like I mentioned before, there are plenty of existing techniques that could
expose information to a timing attack. For example, SVG Filters can
manipulate the color channels of cross-domain images, and using CSS overflow
on an iframe could potentially detect rendering slowdowns as particular
colors/elements/images come into view. CSS shaders increase the rate of leakage
because they execute fast and can be tweaked to exaggerate the timing, but
one could imagine that the GPU renderers now being used in many of WebKit's 
ports
could be exploited in the same manner (e.g. discover a CSS trick that drops
the renderer into software mode).

Obviously at a minimum we'll need to be careful about cross-domain content,
and give input to filters (not just CSS shaders, and moz-element or 
ctx2d.drawElement)
that doesn't expose user info like history. 

But I wonder if there is also some more general approach to take here.
You mention Mozilla's paint events and requestAnimationFrame. Without those
it would be much more difficult to get timing information. The original
exploit on WebGL was especially easy because you could explicitly time a
drawing operation. This is more difficult with CSS (and in Safari, we
don't necessarily draw on the same thread, so even rAF data might not
be accurate enough).

Is there something we can do to make rendering-based timing attacks
less feasible?

Here's a idea I heard floated internally: since the rAF-based attack would be
trying to trigger cases where the framerate drops from 60fps to 30fps, is
there some way we can detect this and do something about it? For example,
once you drop, don't return to 60fps for some random amount of time even if
it is possible. This might sound annoying to developers, but I expect anyone
legitimately concerned with framerate is going to want to do what they can
to keep at the higher value (i.e. they'll want to rewrite their code to
avoid the stutter). This doesn't stop the leak, but it slows it down. And as
far as I can tell everything is leaky - we're just concerned about the
rate. I know there won't be a single solution to everything.

Or maybe rAF is inherently insecure?

Dean



 
 Jonas Sicking seems to have a similar concern:
 
 https://twitter.com/#!/SickingJ/status/143161375823380480
 
 It's probably worth addressing this concern sooner rather than later.
 Ignoring it certainly won't cause the vulnerability to go away.
 
 Adam

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

Re: [webkit-dev] Starting implementation on W3C Filter Effects

[Dean Jackson]

On 24/10/2011, at 9:02 PM, Dean Jackson wrote:

 
 On 22/09/2011, at 11:30 AM, Dean Jackson wrote:
 
 Dirk (known in these parts as krit) reminded me that I had not emailed 
 webkit-dev about the plans to start an implementation of W3C's new Filter 
 Effects specification. 
 
 https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
 
 The quick summary is that this exposes the 'filter' property from SVG to 
 everything in CSS, and adds some shorthands for common effects so people 
 don't have to write XML in order to do something like a blur or sepia 
 effect. The spec has received a fair amount of input from the CSS and SVG 
 working groups, and particularly from Apple, Google, Mozilla, Opera and 
 Adobe.
 
 A followup: we're going to start work on the CSS Shaders proposal [1] soon. 
 Adobe have published their implementation which was specific to Chromium, and 
 we'll be working with them to split it into small patches that can land in 
 the coming weeks. A good introduction to the technology is [2].
 
 This will be done behind the ENABLE_CSS_FILTERS macro, but also with the 
 guards for ENABLE_WEBGL since the implementation (and security) requirements 
 are so similar.

As requested by Adam, this is now ENABLE_CSS_SHADERS and landed yesterday:

http://trac.webkit.org/changeset/99118

Dean

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

Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)

[Dean Jackson]

On 25/10/2011, at 3:13 AM, Dirk Schulze wrote:

 I'd like to know what the actual threat of such timing attacks are. I've 
 seen claims of a maximum theoretical leak rate (in bits/s) but then counter 
 claims that since, in this case, it would be hard to distinguish the 
 difference in slowdown between CSS shaders and general page rendering, that 
 the real rate is much lower. And, at least in the case of Safari, you can't 
 always be sure that getting a rAF callback means you're about to draw.
 
 Does anyone have hard data on this?
 
 At a minimum, please do not land an implementation for this feature
 without a way for ports that are concerned about this security feature
 to disable it independently of both CSS_FILTERS and WEBGL.  Contrary
 to your previous assertion, the security implications are quite
 different than those with WebGL.

Sorry, I was assuming a WebGL that allowed input from 
canvasContext.drawElement. At that point I think they are close enough to call 
the same (no doubt I'm wrong! :) Even without drawElement, WebGL offers a lot 
of attack vectors.

 We already discussed the HW acceleration of SVG Filters on 
 https://bugs.webkit.org/show_bug.cgi?id=70099 and the implementation of CSS 
 Filters earlier on this mailing list. We agreed that we will continue to use 
 the implemented software rendering as fallback for Filters. CSS Shaders won't 
 be included. Shaders should just be supported if HW acceleration is enabled. 
 And I think as a minimum consensus on bug 70099 most people on the thread 
 agreed to go on with GraphicsContext3D for now. In my opinion it means we 
 would have the same security concerns like on WebGL. That's also one reason 
 why I think that the WEBGL flag would match these needs quite well, even if 
 CSS Shaders rely just indirectly to WebGL. If the flag is not enabled, CSS 
 Shaders are deactivated (and ignored if web developers use them in their 
 filter chain) and Filters take the software rendering fallback.

Adam's point in the bug is that any operation that can access colour channels 
might be able to perform a timing attack. This would include SVG filters 
operating on HTML content without any hardware acceleration.

For this reason I'm still tempted to suggest the combination of CSS_FILTERS + 
WEBGL is enough of a switch for ports to disable this, but I'm happy to add 
another one.

I'm not sure at what point we should take the discussion from this list and 
onto bugzilla.

Dean

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

Re: [webkit-dev] Starting implementation on W3C Filter Effects

[Dean Jackson]

On 22/09/2011, at 11:30 AM, Dean Jackson wrote:

 Dirk (known in these parts as krit) reminded me that I had not emailed 
 webkit-dev about the plans to start an implementation of W3C's new Filter 
 Effects specification. 
 
 https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
 
 The quick summary is that this exposes the 'filter' property from SVG to 
 everything in CSS, and adds some shorthands for common effects so people 
 don't have to write XML in order to do something like a blur or sepia effect. 
 The spec has received a fair amount of input from the CSS and SVG working 
 groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.

A followup: we're going to start work on the CSS Shaders proposal [1] soon. 
Adobe have published their implementation which was specific to Chromium, and 
we'll be working with them to split it into small patches that can land in the 
coming weeks. A good introduction to the technology is [2].

This will be done behind the ENABLE_CSS_FILTERS macro, but also with the guards 
for ENABLE_WEBGL since the implementation (and security) requirements are so 
similar.

Dean

[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html
[2] www.adobe.com/devnet/html5/articles/css-shaders.html


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

Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)

[Dean Jackson]

On 24/10/2011, at 9:08 PM, Adam Barth wrote:

 How have you solved the security problems with CSS Shaders?
 Specifically, timing attacks can be used to extract image information
 passed to shaders and many things WebKit renders are sensitive and
 should not be exposed to the web site (e.g., the color of visited
 links).

This is a good question and I know that I don't have the answers (and can't 
even claim to understand all the implications).

I think the most important restriction is that shaders should not apply 
cross-origin. e.g. iframes and probably anything with img children from 
another domain (unless it is marked as ok via CORS).

The possibility of leaking information such as visited links, or maybe 
reconstructing text which could be fed to OCR, is more difficult. Is this 
really specific to CSS Shaders? SVG filters would theoretically be able to do 
the same thing. In fact, given enough knowledge of WebKit rendering one could 
imagine tweaking the style of an element in a way that causes a measurable 
rendering slowdown.

I'd like to know what the actual threat of such timing attacks are. I've seen 
claims of a maximum theoretical leak rate (in bits/s) but then counter claims 
that since, in this case, it would be hard to distinguish the difference in 
slowdown between CSS shaders and general page rendering, that the real rate is 
much lower. And, at least in the case of Safari, you can't always be sure that 
getting a rAF callback means you're about to draw.

Does anyone have hard data on this?

Dean



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