This is closely related to Ied0b974 which fixed a similar, if not
the same rounding issue.
Note the following might be different depending on e.g. the
operating system. My Ubuntu+Chromium shows the following behavior:
* The RTL scroll type is correctly detected as "negative" with all
zoom factors below and up to 100%.
* When the zoom factor is 110%, 125%, or 150% the scrollLeft value
is not 0 but something like 0.909090876 or 0.200000002.
* It's 0 again at 175% and 200%.
* Bad at 250%. Good at 300%. Bad at 400%. And so on. No rhyme or
reason.
The current Firefox version also ends in the "negative" branch, but
doesn't have the same rounding errors. It's always a perfect 0 in
Firefox.
This makes it look like a bug in Chrome's engine. We don't know how
old it is, but based on the information in T352169 it might be a
relatively new bug that didn't exist when this code was originally
written in 2016 (see I7c903c2).
For reference, this is what's supposed to happen here: Browsers with
the scroll type "negative" (which are apparently all current Chrome
and Firefox versions) won't allow scrollLeft to be a positive number
on an RTL page. When you scroll to the left in such browsers the
numbers get negative. The detection code tries to set the number to
+1 anyway. We expect the browser to ignore this invalid call and
still report the previous 0.
This mostly works in Chrome as well. For example, setting scrollLeft
to +100 wont set it to +100 but to … some random number between >=0
and <1, depending on the current zoom factor? o_O?
I suspect we can remove this detection code entirely, or at least
change the default to "negative". But this needs more testing with
more browsers. Let's start with this tiny fix.
Bug: T352169
Change-Id: I22cbb8881578e96165097d4fcc812baadc22d7fa
This updates the code a little bit to be closer to the current
version of https://github.com/othree/jquery.rtl-scroll-type
without actually changing anything (for now).
I tried copy-pasting the current version to see if that helps with
T352169, but it doesn't make a difference.
The only actual change is that the dummy element is removed when
it's not needed any more.
Change-Id: Ibdd064e228fa9464a8652ce9a8a9ac388662f29d
The version numbers mentioned in the comment are from the V8 engine.
The last Google Chrome version to use a 5.x version of the V8 engine
was Google Chrome version 59. That was 8 years ago. See T168299.
Our official support matrix asks for 3 years.
https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix
Notice how there is no version number in the code despite the comment
explaining that it shouldn't be used in later versions.
According to my local tests this is not a full fix for T352169, but
notably improves the situation. I can still see the bad behavior
described in T352169, but only in a narrow region on the right side
of the slider. Removing the obsolete browser detection is necessary
to unblock further investigation.
Making the dummy text a bit longer also makes an actual difference.
To keep this patch as minimal as possible all I do is to add a single
character.
Bug: T352169
Change-Id: I56f3c1969ce4f164f4319e5038d0f97527e6b1c0
Reintroduces IIFE closures in test files because variables were
declared in the global namespace, and "const" now causes hard errors.
Bug: T339323
Change-Id: I69e9d7a29591137f185f3e5ab02dea590ec4dff6
This will make the pointers work on touch devices. The events responsible
for the touch drag and move are converted to mouse actions that will
trigger the draggable.
When using Chrome on touch devices and zooming the offset of elements
calculated by jQuery is wrong. There is a workaround that seems to work
and also seems to not break behavior with normal browsers and on other
devices. Since this only seems to be a problem in Chrome the fix will
only applied to Chrome browsers to avoid performance los on others.
Also introduced a script file for static utility methods.
Bug: T164249
Change-Id: I245f77eb836afded249f3b5ebb7129dab08d0017
