Search code examples
javascriptinputscrollfocusenter

scrollIntoView() method stops scrolling mid-way to the element when triggered by ENTER key on input


Context

I'm developing a list of items.

I have a form on the top of the list in order to add new items (just 1 input and 1 submit button).

Once the form is submitted, I have the next code in order to automatically scroll into the new element (wherever it fits into the list):

document.getElementById(newItemId).scrollIntoView({ behavior: "smooth" });

For testing purposes and a better understanding of the problem, I created a huge list (50 items) and I made all new items to be placed at the bottom of the list, so I can get clearer evidences.

web page with a form at the top and a list of items below

Problem

When creating the item #51:

  • If I click the submit button (just a mouse click), it works in all browsers (tested in Chrome, Firefox and Edge): The item is created at the bottom and the browser scrolls down into the end of the page.

    Web page scrolled at the bottom of the list

  • If I press the Enter key while the input is focused:

    • It doesn't work on Chrome: just stops scrolling like mid-window, no matter the whole page height.

      web page scrolled just like mid-window

    • It doesn't work on Edge: it stops a little before the new item.

      web page scrolled almost at the bottom of the list

    • It works on Firefox properly.

      web page scrolled at the bottom of the list

  • If I tab into the submit button and then press the Enter key, it works in all browsers.

Note: Without behavior: "smooth" there isn't any problem, as it is an instant scroll and there is no time in-between to get interrupted.

Note 2: I managed to develop a workaround by using the window.scrollTo() method, but I would like to make it work with scrollIntoView() to avoid pixel-perfect calculations and to report this problem to affected browsers in case this is a bug.

Code Example

As suggested by comments, I made this jsbin for testing purposes: https://jsbin.com/kiwiviboro/edit?html,output

Considerations:

  • I made a simplified version, as my app is programmed in TS / React / Next. But the behavior is exactly the same.
  • For the simplification, the form doesn't actually create a new element, just scrolls into the last one (the 50th one).
  • In this simplified version, you can check that the scroll even doesn't move a single pixel on Chrome nor Edge, as there is no interactions / request in-between.
  • I made this after finding the solution, that's why it includes more logic. Please check my solution for details on the logic affected.
  • Why did I made it if I already found the solution? Because I would like to discuss about if this is actually the correct behavior or if some browsers have a bug that should be reported and fixed. Please check my solution to find the jsbin with the fixed code to draw your own conclusions

Solution

  • Source of the problem

    I just woke up with fresh ideas! And found out that the problem was in other part of the logic.

    I have a logic to hide the form when it is correctly submitted (affected CSS property: visibility: hidden), so the problem here is that the input loses the focus "unexpectedly" and some browsers (Chrome) when losing the focus stops any scrolling actions (and maybe other kind of animations?), some others (Edge) notice it a while later and others (Firefox) doesn't even care.

    I omitted it as I though it had nothing to do with this problem due to the differences between browsers behaviors.

    Solution

    In case you face this problem, just .blur() your input before sending/hiding the form or, most accurately / in any other case, before starting the scroll action, in order to lose the focus manually / intentionally before the scroll starts happening.

    Code Example

    I made the same code example of the question but with the fix already applied:

    https://jsbin.com/deciyenivo/edit?html,output

    You can check that it now works properly in all browsers.

    Discussion

    Anyway, do you think it is still a bug from Chrome and Edge? (and maybe other browsers) Should I report it?

    Or is this considered a correct behavior?

    Just for the record, I will leave here my current browsers versions:

    • Chrome: 118.0.5993.89 (official build) (64 bits)
    • Firefox: 113.0.2 (64-bit)
    • Edge: 118.0.2088.61 (official compilation) (64 bits)