Intent to Deprecate and Remove: WebKitPoint

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Remove the WebKitPoint interface on master and the M38 branch.

Motivation

The removal of webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage() broke a script which uses WebKitPoint for feature detection:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/KS5GAM7JXtg/3jx_wEo5_LoJ 

The author contacted blink-dev and recommended either removing WebKitPoint as well, or reverting the removal for now. Despite the low impact, it's a reasonable request given the connection between the APIs.

Since the removal, WebKitPoint isn't passed to or returned from any other function. The only thing one can do is create objects with new WebKitPoint(x,y) and read back the values.

Compatibility Risk

Likely low. Since the object can only be used meaningfully together with webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage() it's likely that usage is similar to those, which is extremely low:

http://www.chromestatus.com/metrics/feature/timeline/popularity/359

http://www.chromestatus.com/metrics/feature/timeline/popularity/360

Alternative implementation suggestion for web developers

If used together with webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage(), see the previous thread.

If used in isolation (unlikely) just use an object literal { x: x, y: y} or similar.

Usage information from UseCounter

http://www.chromestatus.com/metrics/feature/timeline/popularity/488

This use counter has not reached stable, which makes the removal speculative.

Entry on chromestatus.com, crbug.com, or MDN

None.

Requesting approval to remove too?

Yes. If we learn about some problematic sites and they need time to stop using WebKitPoint, we can revert both removals together and wait.

I preemptive acknowledge that PhistucK favors waiting for use counter data, but have nothing useful to say on that disagreement.

[PhistucK]

Unfortunately, I found a few cases where WebKitPoint is used for rendering engine detection (might not be relevant here).

https://github.com/search?l=javascript&p=6&q=WebKitPoint+NOT+webkitConvertPointFromPageToNode&ref=searchresults&type=Code&utf8=%E2%9C%93

For example, to check whether it is a pre-WebKit Blackberry browser -

https://github.com/zachleat/ToolOrDie/blob/b610f4176196f2146ef4bf3b049f0d685e2a97a6/js/global.js

https://github.com/filamentgroup/tablesaw/blob/f67f102d648b31fed6c843356a0004d329c61ddc/src/tables-init.js

Or whether it is WebKit -

https://github.com/benjrallen/cleanslate/blob/11463a1e3556c8216d886b53f9092cbb46e54705/wp-content/themes/guru_boilerplate/js/common.js

https://github.com/benjrallen/max-parallax/blob/efa4efc55ef74deea369f6304037e3d402d77fad/wp/wp-content/themes/max/js/common.js

https://github.com/benjrallen/resume/blob/dc568e9fff7ae0849086afa817a9a5353b36e445/js/script.js

https://github.com/majinhui04/reference/blob/889b59239f42189933a52bb9fd36d8059f186648/base.js

https://github.com/benjrallen/wp_resume/blob/38432b2b70859f53eb4e640906c1037e87d1188a/wp-content/themes/resume/js/common.js

https://github.com/ian000/singleton/blob/cc873841e0f5d63b54102b7d5ad5173d9cc95fc7/js/jquery.css3.js

Damn. I hate those 'feature' browser detections.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

Thanks, that's interesting and a bit sad. Fortunately, tablesaw appears to be the only repo with many forks, and since it says "window
.blackberry && !window.WebKitPoint" it won't make any difference.

Note that when an interface object on window is accessed, that doesn't register with use counter, only invoking the constructor is counted.

We'd have to tweak the IDL generator to get meaningful use counter data. This is something I should point out when it comes to future interface removals, since it's not at all obvious.

Philip

[PhistucK]

There are many cases unrelated to Blackberry.

☆PhistucK

[Philip Jägenstedt]

Yes, but of the ones you found none have any forks on GitHub, which is encouraging.

[PhistucK]

True, but the same code is used over and over again in various repositories, forks or not. The GitHub search has over 10,000 results.

☆PhistucK

[Mike Sherov]

A slightly more filtered github search reveals far less matches:

https://github.com/search?l=javascript&q=WebKitPoint+NOT+webkitConvertPointFromPageToNode+NOT+webkitConvertPointFromNodeToPage+NOT+blackberry+NOT+shouldBeTrue&ref=searchresults&type=Code&utf8=✓

This search NOTS both companion functions, and also "blackberry" to filter out the "window.blackberry" case, and filters out clones of the WebKit test suite with "shouldBeTrue". 

Instead of >10,000 I get ~350, mostly used for crude WebKit browser sniffs which are possibly doing the wrong thing now since the blink/WebKit split. 

—
Sent from Mailbox

[Eric Seidel]

LGTM to remove. If we don't remove things like this, then other
browsers will just have to implement them eventually:
http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx

[Dimitri Glazkov]

LGTM2.

[Jochen Eisinger]

lgtm3

[dark...@gmail.com]

We have a problem with Sencha Touch 1.1.1 since yesterday because of the Google Update 39. How can we replace the framework's WebKitPoint code? Here is more info about the issue: http://stackoverflow.com/questions/27040297/uncaught-referenceerror-webkitpoint-is-not-defined

[PhistucK]

See https://crbug.com/434976 for alternatives (you will have to modify the Sencha JavaScript file).

☆PhistucK

On Thu, Nov 20, 2014 at 3:13 PM, <dark...@gmail.com> wrote:

We have a problem with Sencha Touch 1.1.1 since yesterday because of the Google Update 39. How can we replace the framework's WebKitPoint code? Here is more info about the issue: http://stackoverflow.com/questions/27040297/uncaught-referenceerror-webkitpoint-is-not-defined

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.