WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
140610
[GTK] Add API to change the WebKitWebView background color
https://bugs.webkit.org/show_bug.cgi?id=140610
Summary
[GTK] Add API to change the WebKitWebView background color
Carlos Garcia Campos
Reported
2015-01-19 01:52:22 PST
Add webkit_web_view_get_background_color and webkit_web_view_set_background_color
Attachments
Patch
(14.54 KB, patch)
2015-01-19 02:10 PST
,
Carlos Garcia Campos
gustavo
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Carlos Garcia Campos
Comment 1
2015-01-19 02:10:20 PST
Created
attachment 244887
[details]
Patch I've tried to check the actual rendering in the unit tests using different approaches but none of the actually worked. We can't use snapshots, because the background is rendered in the UI process by the backing store, and snapshots are rendered in an image surface without using the backing store. I also tried to use a GtkOffscreenWindow, but it uses xlib surfaces than when rendered into an image surface can't be compared at pixel level with an image surface manually filled. So, in the end I added a --bg-color command line option to MiniBrowser that can be used to manually tested. You can pass any value that can be parsed by gdk_rgba_parse().
Gustavo Noronha (kov)
Comment 2
2015-01-19 14:58:15 PST
Comment on
attachment 244887
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=244887&action=review
> Source/WebKit2/UIProcess/WebPageProxy.cpp:339 > +#if PLATFORM(GTK) > + , m_backgroundColor(Color::white) > +#endif
I read your description of its behaviour on the list: - WebPageProxy::setDrawsBackground(): This ends up calling FrameView::setTransparent() for every frame. It seems that when this is set to true the document or base background color is ignored. There is a base background color already, then, can we use that instead of adding something else? Otherwise looks good!
Carlos Garcia Campos
Comment 3
2015-01-20 00:24:48 PST
(In reply to
comment #2
)
> Comment on
attachment 244887
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=244887&action=review
> > > Source/WebKit2/UIProcess/WebPageProxy.cpp:339 > > +#if PLATFORM(GTK) > > + , m_backgroundColor(Color::white) > > +#endif > > I read your description of its behaviour on the list: > > - WebPageProxy::setDrawsBackground(): This ends up calling > FrameView::setTransparent() for every frame. It seems that when this is set > to true the document or base background color is ignored. > > There is a base background color already, then, can we use that instead of > adding something else? Otherwise looks good!
Not sure I understand what you mean. When we set drawsBrackground to False, WebCore doesn't render any background (unless the document itself specifies a background in the HTML or CSS). The default base color in FrameView is white, so when the white color is set by the user, we simply set the drawsBackground to True, and we don't need to fill our backing store. We need to initialize the WebPageProxy bg color member to white because we are comparing that value when a new color is set. If white color is set the first time, we simply do nothing, because that's already the default.
Carlos Garcia Campos
Comment 4
2015-01-20 00:25:59 PST
Committed
r178699
: <
http://trac.webkit.org/changeset/178699
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug