This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26775 - CSSOM-View extensions to Element and Window break backwards-compatibility
Summary: CSSOM-View extensions to Element and Window break backwards-compatibility
Status: RESOLVED FIXED
Alias: None
Product: CSS
Classification: Unclassified
Component: CSSOM View (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-10 18:21 UTC by Kearwood "Kip" Gilbert
Modified: 2014-09-12 12:09 UTC (History)
1 user (show)

See Also:


Attachments

Description Kearwood "Kip" Gilbert 2014-09-10 18:21:08 UTC
Existing web content may fail as it expects the coordinates
passed to CSSOM-View functions to treat non-finite numbers
(NaN, Infininity, and -Infinity) as 0.

WebIDL for these functions defines the x and y coordinates using the "double" data type:

http://www.w3.org/TR/cssom-view/#extensions-to-the-window-interface
http://www.w3.org/TR/cssom-view/#extensions-to-the-element-interface

This affects all functions that accept a double value for
coordinates, including:

window.scroll
window.scrollTo
window.scrollBy
element.scrollTop;
element.scrollLeft

I propose that this could be solved by defining the
coordinates as "unrestricted double" so that these functions
can accept the non-finite values.  The function
implementations should then coerce any non-finite values to 0.

For example, window.scrollTo would be defined as:

void scrollTo(unrestricted double x, unrestricted double y, optional ScrollOptions options);
Comment 1 Boris Zbarsky 2014-09-10 18:27:12 UTC
Note that this not a theoretical concern.  See https://bugzilla.mozilla.org/show_bug.cgi?id=1062406 and https://bugzilla.mozilla.org/show_bug.cgi?id=1064385 for two sites we've already found that are broken by this API change.
Comment 2 Simon Pieters 2014-09-11 17:33:15 UTC
Should I do this across the board?

window.moveTo
window.moveBy
window.resizeTo
window.resizeBy
window.moveTo
document.elementFromPoint
document.elementsFromPoint
document.caretPositionFromPoint
ScrollOptionsHorizontal#x
ScrollOptionsVertical#y

What about initMouseEvent()? MouseEventInit? (similar for touch events?)
Comment 3 Boris Zbarsky 2014-09-11 18:03:08 UTC
> Should I do this across the board?

Only for the things that used to take integers, I'd say.  Things that have been taking doubles/floats all along are likely web-compatible, since browsers are already shipping those.

> What about initMouseEvent()? MouseEventInit?

Those take integers in https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#interface-MouseEvent and https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#idl-def-MouseEventInit as far as I can tell.

No idea on touch events.
Comment 4 Simon Pieters 2014-09-12 07:45:18 UTC
OK, that makes sense.

https://dvcs.w3.org/hg/csswg/rev/0bd322b87db6

CSSOM View defines MouseEvent as double. But I've left that alone for now.
Comment 5 Boris Zbarsky 2014-09-12 12:09:27 UTC
> CSSOM View defines MouseEvent as double.

Then it likely needs the same change.  Also, why are we defining the same thing in multiple specs?  :(