Bug 188045

Summary: [WebIDL] Element's scrollLeft and scrollTop should be unrestricted double
Product: WebKit Reporter: Frédéric Wang (:fredw) <fred.wang>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: ahmad.saleem792, ap, bfulgham, cdumez, cmarcelo, dbates, emilio, esprehn+autocc, ews-watchlist, gyuyoung.kim, kangil.han, kondapallykalyan, rado, rniwa, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 5991    
Attachments:
Description Flags
Patch none

Frédéric Wang (:fredw)
Reported 2018-07-26 06:53:29 PDT
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.
Attachments
Patch (4.46 KB, patch)
2018-07-26 08:17 PDT, Frédéric Wang (:fredw) 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Frédéric Wang (:fredw)
Comment 1 2018-07-26 08:17:38 PDT
Created attachment 345845 [details] Patch Just some quick patch for testing purpose...
Frédéric Wang (:fredw)
Comment 2 2018-08-31 01:36:33 PDT
> (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)
Comment 3 2020-11-02 01:44:56 PST
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
Comment 4 2021-01-15 08:58:35 PST
Please fix this, because it makes a Scroll Snap Points carousel extremely hard to achieve. Thanks.
Simon Fraser (smfr)
Comment 5 2021-01-15 09:38:25 PST
How so?
Rado
Comment 6 2021-01-15 10:30:49 PST
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
Comment 7 2022-08-09 13:40:13 PDT
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
Comment 8 2022-08-10 10:59:36 PDT
<rdar://problem/98460291>
Note You need to log in before you can comment on or make changes to this bug.