Skip to content

Expose scroll event data #2472

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Zagitta opened this issue Jun 3, 2024 · 2 comments · May be fixed by #4022
Open

Expose scroll event data #2472

Zagitta opened this issue Jun 3, 2024 · 2 comments · May be fixed by #4022
Labels
enhancement New feature or request html Related to the html crate

Comments

@Zagitta
Copy link

Zagitta commented Jun 3, 2024

Feature Request

Currently the onscroll event's ScrollData exposes nothing besides downcasting which leaves downstream users/libraries to deal with platform specifics to obtain scroll position etc.

One example of this is dioxus-lazy where the scroll position is required to calculate which elements to show. What that library does is to keep track of MountedData and on every scroll event downcast that to &web_sys::Element on which scroll_top() is called.
This means that his otherwise great library is limited to only supporting web which is unfortunate.
I attempted to add desktop support but it turns to not even be possible because the equivalent DesktopElement isn't even exposed from the desktop crate.

So instead of requesting that be made public the root issue should be addressed to expose scroll_top() etc in a platform-agnostic way.

@ealmloff ealmloff added enhancement New feature or request html Related to the html crate labels Jun 3, 2024
@jkelleyrtp jkelleyrtp added this to the High-Priority Backlog milestone Jul 25, 2024
@mcmah309
Copy link
Contributor

@ealmloff @jkelleyrtp I just looked into this and willing to implement something. Web was easy to implement, but wry seems to not send any scroll data. Here the data in the request is always empty for scroll

move |_id: wry::WebViewId, request, responder: RequestAsyncResponder| {
. I'm not familiar with wry, so does wry just not handle the data for these events? I noticed on desktop each element has an id like dioxus-data-id (not sure where this comes from though) and this id is in the header of the requests, so this could be theoretically be used to request the new information for the scroll container when a scroll event is received on desktop. Any direction?

@ealmloff
Copy link
Member

@ealmloff @jkelleyrtp I just looked into this and willing to implement something. Web was easy to implement, but wry seems to not send any scroll data. Here the data in the request is always empty for scroll

dioxus/packages/desktop/src/webview.rs

Line 238 in 66e284c

move |_id: wry::WebViewId, request, responder: RequestAsyncResponder| {
. I'm not familiar with wry, so does wry just not handle the data for these events? I noticed on desktop each element has an id like dioxus-data-id (not sure where this comes from though) and this id is in the header of the requests, so this could be theoretically be used to request the new information for the scroll container when a scroll event is received on desktop. Any direction?

In the desktop renderer we get most events from the webview, not wry itself. We serialize the browser events to JSON and send them over a synchronous request to the native rust code. For example, the wheel event is serialized in javascript here and deserialized here. We need to add similar serialization/deserialization code for the scroll event

@mcmah309 mcmah309 linked a pull request Apr 21, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request html Related to the html crate
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants