Incorrect scroll behaviour on a page about scroll-into-view-if-needed

[stipsan]

🎉 This issue has been resolved in version 2.2.15 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[stipsan]

The new release is tested against your code but let me know if there's still a problem 🙂

[catamphetamine]

@stipsan You're the man )

[catamphetamine]

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.

[stipsan]

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:

1. Find closest scrollable element.
2. Calculate where it should scroll.
3. Perform scrolling.
4. Check if more scrolling is needed to make the element visible, if yes repeat step 1.

In v2:

1. compute-scroll-into-view finds all scrollable parent elements first.
2. Loop through the element and create an array over elements and their coordinates.
3. 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 😄 👍

[catamphetamine]

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.

[catamphetamine]

@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 });
  }
}

[stipsan]

You can send it to [email protected] 👍

[catamphetamine]

Sent

[stipsan]

Sweet! I'll post back here when it's resolved 😄

[catamphetamine]

Ok )
We're fine with 1.5.0 for the time being.

[stipsan]

Well the code you shared with me made it really easy for me to fix this 😄