LibWeb+WebContent: Move scrollbar painting into WebContent #24554
Conversation
|
Without making changes in SerenityOS Browser you will get duplicated scrollbar (one painted in WebContent and another in Browser) and probably some other issues. |
github-actions
bot
added
the
👀 pr-needs-review
|
Hmm, silly me. I'll work on this later / tomorrow :) |
github-actions
bot
removed
the
👀 pr-needs-review
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! |
This is a hack needed to preserve current behaviour after making set
viewport_rect() being not async in upcoming changes.
For example both handle_mousedown and handle_mouseup should use the same
viewport scroll offset even though handle_mousedown runs focusing steps
that might cause scrolling to focused element:
- handle_mousedown({ 0, 0 })
- run_focusing_steps()
- set_focused_element()
- scroll_into_viewport() changes viewport scroll offset
- handle_mouseup({ 0, 0 })
(cherry picked from commit 50920b05953a6bc2aacb07d291d503052caadf15)
(cherry picked from commit eb909118bfe9d939a1109823b6e0b8736abab138)
|
This gets things at least to compile: hack.patch It removes client-side scrollbars from Browser. But the renderer-side scrollbars look supremely janky in serenity, even more so in non-browser apps that use a webview: 
So we probably want to move scrollbar painting to a new LibTheming or something, and make both LibGUI and LibWeb use that to draw scrollbars. Also, it comments out a few calls (to Also also, Also also also, dragging the horizontal scrollbar if text is below it selects the text instead of dragging the scrollbar :yakkiss: |
|
Looks like we've both been working on this at the same time, although you've gone further than me. https://gist.github.com/jamierocks/3607e73f472ec6efba0fce1030b8b5c8
|
|
I gave it a short look last Thursday (that's when the diff is from). I'm not actively looking at this :) |
The main intention of this change is to have a consistent look and behavior across all scrollbars, including elements with `overflow: scroll` and `overflow: auto`, iframes, and a page. Before: - Page's scrollbar is painted by Browser (Qt/AppKit) using the corresponding UI framework style, - Both WebContent and Browser know the scroll position offset. - WebContent uses did_request_scroll_to() IPC call to send updates. - Browser uses set_viewport_rect() to send updates. After: - Page's scrollbar is painted on WebContent side using the same style as currently used for elements with `overflow: scroll` and `overflow: auto`. A nice side effects: scrollbars are now painted for iframes, and page's scrollbar respects scrollbar-width CSS property. - Only WebContent knows scroll position offset. - did_request_scroll_to() is no longer used. - set_viewport_rect() is changed to set_viewport_size(). (cherry picked from commit 5285e22f2aa09152365179865f135e7bc5d254a5) Co-authored-by: Jamie Mansfield <jmansfield@cadixdev.org> Co-authored-by: Nico Weber <thakis@chromium.org>
No longer used after moving scrollbar painting into WebContent. (cherry picked from commit cc3d95a356ea3769d325c2f7bb73947cb4ba7baa)
No longer used after moving scrollbar painting into WebContent. (cherry picked from commit 94eacf6da736f957a5fc22faa552341165aaf1ca)
(cherry picked from commit 881e97084625184543b93cee235cb0b96ee055ae)
github-actions
bot
added
the
👀 pr-needs-review
I've added a FIXME for this, for now.
This shouldn't be required anymore, it should reset when the new document loads.
I've added some FIXMEs for this, for now. |
github-actions
bot
removed
the
👀 pr-needs-review
See LadybirdBrowser/ladybird#21 for details :^)