Expose scroll event data

[Zagitta]

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.

[mcmah309]

@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?

[ealmloff]

@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