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:

https://www.haiku-os.org/docs/userguide/en/images/apps-images/webpositive.png

Change History (8)

comment:1 by pulkomandy, 4 years ago

Component: Applications/WebPositiveKits/Web Kit

comment:2 by nephele, 3 years ago

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.

comment:3 by pulkomandy, 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 nephele, 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?

comment:5 by pulkomandy, 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 nephele, 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.

Last edited 23 months ago by nephele (previous) (diff)

in reply to:  5 comment:7 by madmax, 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 nephele, 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.

Note: See TracTickets for help on using tickets.