scroll-into-view / compute-scroll-into-view Goto Github PK

I saw this mentioned in an earlier issue (#292):

I plan on implementing scroll-margin and scroll-padding support next, as these properties are no longer exclusive to scroll-snap logic but also affect scrollIntoView and page fragment scrolling in firefox and chrome betas.

And I gather that explicit support has not been implemented yet, based on searching the source code.

I noticed that, without the polyfill, I can use .scrollIntoView in Chrome (just without the if-needed option), and it's working as I expect, taking scroll-padding-top into account. So my solution for now is: in Chrome, just call that native method, but if we are in Safari/Edge (or if that method had an error), it uses this polyfill (even though some content will be covered by the fixed header, since scroll-padding/scroll-margin is not accounted-for yet).

Is that basically the right idea in the meantime?

This might be a trivial and uncommon compatibility issue:

I have packages in my mono repo with source export so that build tools can directly bundle the source files if applicable.

Source maps are not of much use in a package without source either.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

The push permission to the Git repository is required.

semantic-release cannot push the version tag to the branch master on remote Git repository with URL http://[secure]@github.com/stipsan/compute-scroll-into-view.git.

Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment and make sure the repositoryUrl is configured with a valid Git URL.

Good luck with your project ✨

Your semantic-release bot 📦🚀

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

@stipsan

https://codesandbox.io/s/an-niu-lei-xing-antd-4-17-0-alpha-0-forked-nk52i?file=/index.js

1、scroll to the position like this image

2、click the button

3、Nothing happened

If I use scrollMode=“always” and custom behavior to set value=el.top + 70 can resolve it.But I do not need “always”,I need “if needed”. Can you provide an offsetTop parameter to configure with scrollMode=“if-needed”?

In new version of Typescript they added visualViewport type and is not compatible with visualViewport type in scroll-into-view package.

node_modules/typescript/lib/lib.dom.d.ts:18515:14 - error TS2687: All declarations of 'visualViewport' must have identical modifiers.

18515 readonly visualViewport: VisualViewport;

The global declaration of Element {
host: any
}

is conflicting with the new typescript version(3.0.1) where host is of string type.

Getting the following errors while using this package

/node_modules/typescript/lib/lib.dom.d.ts:5547:11 - error TS2320: Interface 'HTMLAnchorElement' cannot simultaneously extend types 'HTMLElement' and 'HTMLHyperlinkElementUtils'.
Named property 'host' of types 'HTMLElement' and 'HTMLHyperlinkElementUtils' are not identical.

/node_modules/typescript/lib/lib.dom.d.ts:5658:11 - error TS2320: Interface 'HTMLAreaElement' cannot simultaneously extend types 'HTMLElement' and 'HTMLHyperlinkElementUtils'.
Named property 'host' of types 'HTMLElement' and 'HTMLHyperlinkElementUtils' are not identical.

Because of this line:

Here it accesses document as a global, but when you execute this function from the iframe's parent's context, the document outside of the iframe is selected which results in the wrong behavior.

I think instead of getting document as a global here, we can also get it from the element directly.
So that would become something like:

const targetDocument = target.ownerDocument!
const scrollingElement = targetDocument.scrollingElement || targetDocument.documentElement

If an element inside an iFrame has an overflow: visible parent closer than its scroll parent. Then compute will return scroll on this parent, even though scroll is not possible.

Here is a code sandbox to demonstrate the issue: link

Not sure which repo you prefer issues on, but I have an issue where I have a horizontal container that's not detected as "scrollable". If I log out all the actions computed by compute-scroll-into-view, the container isn't listed. This happens even though the scrollWidth is definitely wider than clientWidth. (I logged to verify.) Is there a way to force computation that a container definitely is scrollable and to set the scroll position?

PR #882

I'm trying to use this package over at https://github.com/janosh/svelte-multiselect with vite v3 and getting the following error:

SyntaxError: Unexpected token 'export'
❯ Object.compileFunction node:vm:360:18

Module node_modules/compute-scroll-into-view/dist/index.module.js:1 seems to be an ES Module but shipped in a CommonJS package. You might want to create an issue to the package "compute-scroll-into-view" asking them to ship the file in .mjs extension or add "type": "module" in their package.json.

As a temporary workaround you can try to inline the package by updating your config:

// vitest.config.js
export default {
  test: {
    deps: {
      inline: [
        "compute-scroll-into-view"
      ]
    }
  }
}

Any reservations about adding "type": "module" to package.json?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Using a curated preset maintained by

Sanity: The Composable Content Cloud

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• chore(deps): update non-major (@sanity/pkg-utils, @sanity/semantic-release-preset, @types/expect-puppeteer, @types/jest, @types/jest-environment-puppeteer, EndBug/add-and-commit, jest, jest-puppeteer, prettier, prettier-plugin-packagejson, puppeteer, rimraf, serve, typescript)
• chore(deps): update dependency @sanity/pkg-utils to v5
• chore(deps): update dependency @sanity/pkg-utils to v6
• chore(deps): update dependency puppeteer to v22
• chore(deps): lock file maintenance
• 🔐 Create all pending approval PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update actions/cache action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update dependency @sanity/pkg-utils to v3
• chore(deps): update dependency @sanity/pkg-utils to v4
• chore(deps): update dependency jest-junit to v16
• chore(deps): update dependency jest-puppeteer to v10
• chore(deps): update dependency jest-puppeteer to v9
• chore(deps): update dependency prettier to v3
• chore(deps): update dependency puppeteer to v20
• chore(deps): update dependency puppeteer to v21
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

When the dir attribute of an ancestor node is set to "rtl" compute-scroll-into-view calculates the wrong scrollLeft positions.

To illustrate this I've created a jsfiddle - https://jsfiddle.net/6ckneau1/1/. When you click the "Scroll 7 into view" button in the LTR example it works just fine. When you click the "Scroll 7 into view" in the RTL example it doesn't scroll it into view.

The bug is caused by the way browsers report/use scrollLeft when in RTL. You may want to use a library like this https://github.com/alitaheri/normalize-scroll-left to address this issue.

If compute-scroll-into-view tries to evaluate a scrollable container with zero height, it generates values of NaN.

See https://codesandbox.io/s/nifty-kate-gxf4k8?file=/src/index.js for an example.

A zero-height element can happen, for example, when using a grow transition. The growing element is initially rendered at 0 height, but I'd like to go ahead and scroll to it so that it will be visible as it grows.

Hi @stipsan. Generally i'd like to try to connect it to 'webdriver io' package. But issue is when i'd like to execute the script in context of browser from nodejs where webdriver io works, refers to methods outside of 'compute' lost. Could we move all the functions declaration like canOverflow, getFrameElement, isHiddenByFrame, isScrollable, alignNearest, getParentElement, getScrollMargins to inside of 'compute'? As the methods not exported I believe it doesn't affect something,

The unpkg.com link produces a 500 Server Error and compiling hangs at puppeteer:

$ yarn install
yarn install v1.17.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...
[-/5] ⠈ waiting...
[-/5] ⠈ waiting...
[-/5] ⠈ waiting...
[-/5] ⠈ waiting...
[5/5] ⠈ puppeteer

Any plans on adding support for Shadow DOM ? It was temporarily dropped in #76

It seems to work in both firefox and chrome for us if we want to scroll to the start of the body for example. But both in edge and safari the frames array is always empty if we use document.body as a target

It's IE11 specific issue.

Steps to reproduce:

1. You need App1 with iFrame
2. set document.domain of app1 to domain.com
3. You need App2 that load into App1 iframe
4. set document.domain of app2 to sub.domain.com
5. Usage of function getFrameElement with crash with error: Access is denied

Because IE allow access top window ONLY in case when domain fully matched!

Impact:
Very popular UI library antd - just stops work with error that very hard to find and reproduce.

Thanks for the great library!

I'd like to integrate this library in Quill but the usage is to scroll a range into view. I think it makes sense to support a virtual element as well in addition to Element. A virtual element is basically an object providing the following methods:

interface VirtualElement {
  getBoundingClientRect(): DOMRect;
  getParentElement(): HTMLElement;
}

I can create a PR if that something you want to support.

Hi, thanks for this great library!

I noticed that 2.2.20 was supposed to fix scrolling in iframes but it still doesn't work for me.

I did some debugging, in case it's helpful. In the computeScroll...() function, it's detecting that isScrollable() is false on the target's ownerDocument, so ultimately frames is empty. The iframe is clearly scrollable but the clientHeight and scrollHeight are the same (taller than the iframe).

Not sure what the best fix is - thanks for taking a look!

• chrome 83.0.4103.106 on Mac
• [email protected]

• button[click to scroll]: scroll by this scroll-into-view-if-needed
• button[click to scroll by brower API]: scroll by native Element.ScrollIntoViewIfNeeded

reproduction: https://codesandbox.io/s/elegant-cdn-75n62

Hello!

If you have the following scenario then the check starting on line 346 to see if the element is in the viewport will fail:

1. You supplied no boundary and are not within a scrollable element
2. You gave the HTML element a height of 100%
3. You have scrolled more than the current height of the page

Seems that bottom property from getClientBoundingRect for the HTML element will be negative if conditions two and three hold. I think bottom = top + height in this condition, where top < -height since you scrolled more than the current height of the page. The check targetBottom <= bottom will then fail in this case because targetBottom will be positive.

I have no clue why this is the case, and I might be slightly off in my deduction but I guess to fix this you would need to have an if statement to check for if bottom is negative and if it is recalculate bottom using something like document.documentElement.clientHeight.

Happy to commit a PR if you agree with the cause + fix @stipsan :)

it is bug