[Webkit-unassigned] [Bug 208129] [GTK] Stop using gtk foreign drawing API to style form controls

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=208129

--- Comment #21 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Adrian Perez from comment #17)
> (In reply to Michael Catanzaro from comment #16)
> > (In reply to Carlos Garcia Campos from comment #14)
> > > For GTK3 the only solution I see is to bring back the old code and add a new
> > > setting (useSystemAppearance), disabled by default, that apps can use to
> > > keep the consistency.
> > 
> > Compromise proposal: do this, but enabled by default, and only for
> > scrollbars. All the web form controls can use Adwaita theme. Scrollbar is
> > going to be more important than form controls since having a non-native
> > scrollbar will look really out of place. The rest is just web content, and
> > it's not expected that web content look native. Then when GTK 4 comes
> > around... well, I don't know what to do for GTK 4, but I think retaining
> > native scrollbar would be enough to avoid most complaints. Maybe we could
> > try moving the scrollbar to the UI process, except when it's actually themed
> > by websites (in which case it has to be in the web process no matter what).
> > 
> > Maybe we could add a config file or some other way of configuring a color
> > scheme on top of Adwaita that Yaru and Granite (and other themes) could use,
> > without creating a completely separate RenderTheme class that would be tough
> > to maintain.
> 
> Wild idea: can we expose somehow in the WebKitWebView API the information
> that an embedder might need to render a scrollbar? I think the following
> additions each scrollbar should suffice:
> 
>  - Current position, range [0.0, 1.0].
>  - Size of the viewport vs. page height (to know how long the thumb
>    needs to be).
>  - Whether the web view needs to show a scrollbar (e.g. FALSE if content
>    does not need it, or if CSS has been used to override the default
>    scrollbar look).
>  - A new method to scroll to a given position.
> 
> Am I being too naïve with this idea?

In WebKit1, we coordinated the view scrolling with the GtkScrollWindow and it was nightmare, and a source of weird bugs. It was very difficult to keep it in sync in the same process, I can't imagine between two processes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200320/dd7f6ecf/attachment.htm>