Intent to Deprecate and Remove: webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage()

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Remove webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage().

These are global functions, exposed on Window.

Motivation

They were added in https://bugs.webkit.org/show_bug.cgi?id=23943 to "map points through possibly-transformed elements." At least the uses of them in LayoutTests can be replaced with getBoundingClientRect(), which also take transforms into consideration. The same is likely true of usage in the wild, too.

These two functions are also the only APIs that depend on WebKitPoint, paving the way for its eventual removal.

Compatibility Risk

The worst-case scenario is catastrophic failure of a WebKit-only site. Given the usage, actual risk seems very low indeed.

Alternative implementation suggestion for web developers

Use element.getBoundingClientRect().left/top to get the offsets that these functions would add/remove.

For example, webkitConvertPointFromNodeToPage(element, new WebKitPoint(0,0)).x can be replaced by element.getBoundingClientRect().left.

Usage information from UseCounter

webkitConvertPointFromPageToNode() ~0.0001%:

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

webkitConvertPointFromNodeToPage() ~0.0002%:

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

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

None.

Requesting approval to remove too?

Yes. Usage is negligible.

[Eric Seidel]

lgtm

[Dimitri Glazkov]

Lgtm2

[Tab Atkins Jr.]

LGTM. This is addressed through a vastly better API in the
GeometryUtils interface: http://dev.w3.org/csswg/cssom-view/#geometry

On Mon, Jul 28, 2014 at 1:58 PM, Philip Jägenstedt <phi...@opera.com> wrote:

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

[Jochen Eisinger]

lgtm3

[ma...@krpano.com]

Big problem here!!!

This change will break several hundred thousand pages!

I'm the developer of the krpano - a viewer for panoramic images on the web. This viewer will be used on a lot of pages and also in many third party products (often in a not visible way).

And inside it's viewer source code there I'm unfortunately still using the webkitConvertPointFromPageToNode function when the WebKitPoint object is defined - the code looks like this:

if (typeof(WebKitPoint) != "undefined")
{
  // webkit code
  var pnt = new WebKitPoint();
  ...    
  pnt = window.webkitConvertPointFromPageToNode(layer, pnt);
}
else
{
  // non webkit code
  // ...
}

I know that check itself wasn't optimal, but unfortunately that code is already out and updating it now will be not possible for a lot of users. Many of them don't have much web knowledge and even updating/replacing a file is often a problem...

But the whole code would still work when additionally also the WebKitPoint would be removed, because then the non-Webkit path would be chosen and that would work in all browsers.

The only reason for the still existing webkitConvertPointFromPageToNode code path was the support for CSS rotated elements, but it would be no big problem when that would be missing.


That means - please:

• either remove the WebKitPoint object too
• or don't remove the webkitConvertPointFromPageToNode/webkitConvertPointFromNodeToPage functions yet
  

For future krpano versions, I have already removed the all webkit related code, but it will take some time (at least one year) until all old pages out there would be updated...

Best regards,
Klaus

[Philip Jägenstedt]

Hi Klaus,

That feature detection was unfortunate, but not too surprising since the two removed functions are the only APIs that used WebKitPoint. One can also create them with new WebKitPoint(1, 2), but that's not very useful in isolation.

Note that the highest usage to date for the removed functions is 0.0003%, which is much lower than some successful removals:
http://www.chromestatus.com/metrics/feature/timeline/popularity/359
http://www.chromestatus.com/metrics/feature/timeline/popularity/360

The use counter for WebKitPoint is in M38, so unfortunately it hasn't produced any useful data yet:
http://www.chromestatus.com/metrics/feature/timeline/popularity/488

Anyway, I agree that removing all of this together makes sense, and Klaus has already mentioned the options:

1. Remove WebKitPoint too, on the reasonable assumption that its usage won't be much higher than the only APIs which you can use it together with.
2. Revert the removal and wait for the WebKitPoint use counter to reach stable.

Do our API owners have a preference on this? I'll be happy to do either.

Philip

[PhistucK]

I am in favor of 2, obviously.

Also, the krpano author noted - "webkitConvertPointFromPageToNode code path was the support for CSS rotated elements".

Does the offered alternative (getBoundingClientRect) support CSS rotated elements?

☆PhistucK

[Philip Jägenstedt]

On Wed, Aug 27, 2014 at 11:18 AM, PhistucK <phis...@gmail.com> wrote:
> I am in favor of 2, obviously.
>
> Also, the krpano author noted - "webkitConvertPointFromPageToNode code path
> was the support for CSS rotated elements".
> Does the offered alternative (getBoundingClientRect) support CSS rotated
> elements?

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3136

getBoundingClientRect() takes CSS transforms into account, but since
you get a bounding box instead of a single point it's not
interchangeable. If one needs the absolute coordinates of a point in a
rotated element, one could add a temporary point-sized element and use
getBoundingClientRect() on that element.

Philip

[ma...@krpano.com]

Hi, are there any news or decisions here?

The webkitConvertPoint* functions are basically very handy functions, but I can understand when there are intentions to remove them.
But when removing, then at least they should be removed completely including the WebKitPoint object. This would be a 'complete and final solution' and for my case/problem this solution be also very acceptable.

But it would be very bad when a stable end-user Chrome version would be released without any changes here....

Best regards,
Klaus

[Eric Seidel]

I'm fine with either 1 or 2. My personal favor is for #1 since every
webKit* we have is harmful to the web:
http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx

I agree with Klaus that getting to a stable #1 or #2 state is better
than sitting in the middle for a release.

[benjami...@gmail.com]

Hi,

The removal of the WebKitPoint object will be good to avoid problem with this kind of object when a correct coding (fallback case) has been done.
If we have to make code with fallback for each method, rather than object it will be a major problem.

Benjamin

[Philip Jägenstedt]

This is what ended up happening:

WebKitPoint was removed on trunk, so if no issues are discovered M39
will ship with the entire set of APIs gone.

When requesting to merge that to M38, the release manager preferred to
revert the "Remove webkitConvertPointFromPageToNode() and
webkitConvertPointFromNodeToPage()" instead, so I've done that. In
other words, M38 will ship with the entire set of APIs present.

Philip

[nith...@gmail.com]

Removal of webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage(). in the latest chrome 29 version is leading to a blocker issue in sencha web application. The page doesn't navigate in my sencha web app and gives exception "
Exception occured while dispatching: ReferenceError: WebKitPoint is not defined"

Please fix this issue

[PhistucK]

Trying the Sencha Touch example, it works fine, so you are probably using an old version of Sencha Touch.

If you are not using Sencha Touch, but something else from them, first try the examples in the Sencha websites and if they also fail, you might have a case...

Good luck!

☆PhistucK

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

[Philip Jägenstedt]

Right, the removal of webkitConvertPointFromPageToNode(), webkitConvertPointFromNodeToPage() and WebKitPoint went into M39.

Can you paste the code where the exception is thrown?

Philip

[nith...@gmail.com]

The exception is thrown due to the following code in sencha-touch.js 

       var point = window.webkitConvertPointFromNodeToPage(this.dom, new WebKitPoint(0, 0));

        return [point.x, point.y]

On Tuesday, 29 July 2014 02:28:28 UTC+5:30, Philip Jägenstedt wrote:

[PhistucK]

I just downloaded the latest Sencha Touch and sencha-touch-all-compat.js does not mention WebKitPoint at all. I guess this is just an old version.

Can you update it?

☆PhistucK

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

[Philip Jägenstedt]

Let's continue this discussion in the bug you filed and that I didn't see before: https://crbug.com/434976

Philip

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

[nith...@gmail.com]

Yes. this is an older version of sencha touch which is 1.1.1 . I cannot update it to a newer version because it is built on the older one and hence it uses the old API's.

Updating to a new version will be a re-write of the whole application.

Is there anything which can be done at the chrome level as it was working fine in the chrome 38 version and also my application is already in production.

So the users will face this issue whenever their chrome gets updated.

On Tuesday, 29 July 2014 02:28:28 UTC+5:30, Philip Jägenstedt wrote:

[pro...@gmail.com]

I have the same issue as well. Doing an upgrade means a large re-write of our app as users upgrade their browsers.

[Philip Jägenstedt]

proto7, please have a look at
https://code.google.com/p/chromium/issues/detail?id=434976#c10 and
comment on that bug if that does not suffice.

Philip

[John R.]

sorry about responding to this old bug, but is there a modern polyfill for this? an old website i'm using requires this (and other deprecated WK functions) and i have found nothing to mitigate this issue.

[Russell Bicknell]

I've been wondering about this for a while too. AFAIK, there's no built-in way to ask the browser to transform points like this, so you have to write a heavy function to walk the tree and inspect the styles manually. The function ends up being huge and brittle - there's no forward compatible way to do it given that new CSS properties might show up in the future. However, this part of the CSSOM spec adds an interface (`GeometryUtils`) that sounds like it's intended to do this, but every time I've returned to that page over the last handful of years, they still have basically zero description.

The lack of this function means that there's no way to handle coordinates from pointer events in relation to arbitrarily transformed elements in a robust way. :(