Opened 11 years ago
Last modified 23 months ago
#10780 new bug
[WebPositive] scrollbars are not properly aligned
Reported by: | diver | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/Web Kit | Version: | R1/Development |
Keywords: | Cc: | stippi | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev47167.
Probably this commit caused it: https://github.com/haiku/webkit/commit/035a53a95715a00aed4cfd739f5aa09c94e4233a
Some notes from PulkoMandy:
PulkoMandy: the problem is, if I fix it for the main scrollbars, there's another bug when drawing scrollbars for iframes PulkoMandy: and it doesn't even look the same in HaikuLauncher PulkoMandy: what was done in Web+ is the scrollbars were 1 pixel too high and too low PulkoMandy: so the grey border at top and bottom isn't drawn PulkoMandy: but, there are grey border for other things around (the navigation bar, and the resize knob) so in the end it looks good
Previously Web+ had correct scrollbar alignment, see this user guide image:
Change History (8)
comment:1 by , 4 years ago
Component: | Applications/WebPositive → Kits/Web Kit |
---|
comment:2 by , 3 years ago
comment:3 by , 3 years ago
This is not about the scrollbar size. They are intentionally offset by 1 pixel at the top and bottom, regardless of their width.
comment:4 by , 23 months ago
Currently webpositive will draw scrollbars itself calling the button drawing and the scrollbarends etc. I wish to change this to use the more high level decorator api for this, so that different scrollbar styles from decorators that do not use the button decorator respect this.
That said, i still don't understand what the bug in this case is?
follow-up: 7 comment:5 by , 23 months ago
All vertical scrollbars are shifted by 1px up (or down? I don't remember), not aligning as they should with the resize knob and the resize handle at the bottom.
I'm not sure if it's possible to use higher level decorator APIs in this case, because of the way this is handled in the web engine and that supposedly CSS could be used to change the scrollbar appearance and colors (but this currently does not work, I think). Which means WebKit really expects a low-level API here (I could be wrong on this).
comment:6 by , 23 months ago
I'm mostly talking about stuff like Source/WebCore/platform/haiku/ScrollbarThemeHaiku.cpp
For example void ScrollbarThemeHaiku::paintThumb implements the thumb drawing as HaikuControlLook does it roughly, by using the button drawing and calling be_control_look->DrawButtonBackground later on after it set up everything.
I think it should instead call be_control_look->DrawScrollBarThumb. It would do basically the same If i'm not mistaken, just allow me to implement this differently in my controllook. Perhaps it's not that much "higher level" but it is more specific i think.
For colors, there is no way in the codepath for our custom controls to respect the colors in the drawing, perhaps they are passed and we ignore them? It may be worth investigating.
comment:7 by , 23 months ago
Replying to pulkomandy:
CSS could be used to change the scrollbar appearance and colors (but this currently does not work, I think).
It does. Haiku api book generated with a current doxygen shows them, for example.
comment:8 by , 23 months ago
Webkit does pass the base color for the control we use it indeed, and i think webkit draws the text itself. but we don't respect any css stuff like button roundness etc. as far as I can tell for native buttons.
which scrollbars is this referring to? If it is the ones on the right side could sou retest with haikuwebkit 1.8.1? The size changed recently to respect the decorators choice.