Incorrect scroll behaviour on a page
catamphetamine opened this issue Β· comments
Version: 2.2.14
.
See the gif:
I don't observe the bug on the react-responsive-ui
demo page but in a real-world app I can see the bug.
Don't know what could cause such behaviour.
I guess there could be many variables affecting that.
I downgraded to various versions and found out that 2.1.0
doesn't have the bug and >= 2.1.1
has the bug, so I guess it was some change from 2.1.0
to 2.1.1
.
I'm staying on version 2.1.0
because of that.
Oh, actually, 2.1.0
doesn't work in some cases too.
So I reverted to 1.5.0
.
1.5.1
doesn't work while 1.5.0
does.
Thanks for the report! Is it possible to share a link to the real world use case where it happens?
In v1 offsetLeft
and offsetTop
is used to calculate scrolling coordinates. In v2 this had to refactor to use getBoundingClientRect
instead to support SVG-in-HTML use cases, as SVG elements do not have these properties.
Another cause for the major difference in scrolling behavior is that v1 performs everything in a single loop:
- Find closest scrollable element.
- Calculate where it should scroll.
- Perform scrolling.
- Check if more scrolling is needed to make the element visible, if yes repeat step 1.
In v2:
compute-scroll-into-view
finds all scrollable parent elements first.- Loop through the element and create an array over elements and their coordinates.
- Return the list to
scroll-into-view-if-needed
which loops it and scrolls the elements.
V1 is very stable and mature but unfortunately without a solid testing suite. I am focusing now on expanding the testing suite in v2 to help mature it and get it to the same stability as v1. Reports like yours is really helpful for gathering test cases and scenarios so thanks again π π
Is it possible to share a link to the real world use case where it happens?
We didn't roll it into production because the bug was discovered, so I guess it isn't.
to support SVG-in-HTML use cases
Yeah, SVG is becoming more popular these days.
We ourselves use SVG quite often (because of React).
Without React SVG would be much less used.
compute-scroll-into-view finds all scrollable parent elements first.
Yeah, I noticed: it found <body/>
and <html/>
(two of them).
I am focusing now on expanding the testing suite in v2 to help mature it and get it to the same stability as v1.
π
Reports like yours is really helpful for gathering test cases and scenarios so thanks again
You're welcome.
@stipsan I made a demo for you.
Give me your email address and I'll email you a link to the archive.
Screenshot:
Extract to a folder, run npm run dev
, go to localhost:3002
, click on the "RESIDENCY" select and see how it scrolls into view.
Then open console and enter scrollIntoView2 = true
.
Hit "Enter".
Scroll to the bottom of the page and click "RESIDENCY" select again β it will scroll top instead of scrolling bottom (or instead of not scrolling at all).
The flag is in node_modules/react-responsive-ui/modules/Expandable.js
:
var _scrollIntoViewIfNeeded = require('scroll-into-view-if-needed');
var _scrollIntoViewIfNeeded2 = _interopRequireDefault(_scrollIntoViewIfNeeded);
var _scrollIntoViewIfNeeded_2 = require('scroll-into-view-if-needed-2');
var _scrollIntoViewIfNeeded_22 = _interopRequireDefault(_scrollIntoViewIfNeeded_2);
...
if (expanded) {
// https://github.com/stipsan/scroll-into-view-if-needed/issues/359
if (window.scrollIntoView2) {
(0, _scrollIntoViewIfNeeded_22.default)(_this3.container,
{
scrollMode : 'if-needed',
behavior : 'smooth',
block : 'nearest',
inline : 'nearest'
})
} else {
(0, _scrollIntoViewIfNeeded2.default)(_this3.container, false, { duration: 300 });
}
}
You can send it to stipsan@gmail.com π
Sent
Sweet! I'll post back here when it's resolved π
Ok )
We're fine with 1.5.0 for the time being.
π This issue has been resolved in version 2.2.15 π
The release is available on:
Your semantic-release bot π¦π
The new release is tested against your code but let me know if there's still a problem π
Well the code you shared with me made it really easy for me to fix this π