[WebIDL] Element's scrollLeft and scrollTop should be unrestricted double

[Frédéric Wang (:fredw)]

Follow-up of bug 161610:

(In reply to Simon Fraser (smfr) from comment #3)
> > > Source/WebCore/dom/Element.idl:75
> > > -    attribute long scrollLeft;
> > > -    attribute long scrollTop;
> > > +    attribute long scrollLeft; // FIXME: should be unrestricted double
> > > +    attribute long scrollTop; // FIXME: should be unrestricted double
> > 
> > Seems relatively straightforward to fix this.
> 
> I didn't want to make a web-facing change here in the same patch.

[Frédéric Wang (:fredw)]

Created attachment 345845 [details]
Patch

Just some quick patch for testing purpose...

[Frédéric Wang (:fredw)]

> (In reply to Simon Fraser (smfr) from comment #3)
> > > > Source/WebCore/dom/Element.idl:75
> > > > -    attribute long scrollLeft;
> > > > -    attribute long scrollTop;
> > > > +    attribute long scrollLeft; // FIXME: should be unrestricted double
> > > > +    attribute long scrollTop; // FIXME: should be unrestricted double
> > > 
> > > Seems relatively straightforward to fix this.
> > 
> > I didn't want to make a web-facing change here in the same patch.

@Simon: Any idea how this change could be visible to the user? And hence whether we can can/should test it?

I tried using values larger than the max long or non-integer values, but scrollable overflow elements/frames seem to have a limited size and to round up scroll position, so that does not seem easy.

[Emilio Cobos Álvarez (:emilio)]

This should be user-visible, see https://bugzilla.mozilla.org/show_bug.cgi?id=1674687 for a test-case.

Modulo compat I'm probably going to try changing Gecko to follow the spec.

[Rado]

Please fix this, because it makes a Scroll Snap Points carousel extremely hard to achieve. Thanks.

[Simon Fraser (smfr)]

How so?

[Rado]

The container must be scrolled programmatically or with snapping to increments of its width. If the width is sub pixel, this is impossible as the browsers can only scroll to integer.

[Ahmad Saleem]

I am able to reproduce this bug using test case from Mozilla bug:

Test case - https://bug1674687.bmoattachments.org/attachment.cgi?id=9185098

Here are outputs across browsers:

*** Safari 15.6 on macOS 12.5 ***

max scrollTop is: 50 
rect offset (real scroll top)is: 50 
dpi is: 2

*** Firefox Nightly 105 ***

max scrollTop is: 50
rect offset (real scroll top)is: 49.5
dpi is: 2

*** Chrome Canary 106 ***

max scrollTop is: 49.5
rect offset (real scroll top)is: 49.5
dpi is: 2

______

As per Mozilla bug, it should be 49.5 for both like Chrome. Just wanted to share updated testing results. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/98460291>