WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 152273
[GTK] Gradient on large text fields
https://bugs.webkit.org/show_bug.cgi?id=152273
Summary
[GTK] Gradient on large text fields
Cosimo Cecchi
Reported
2015-12-14 14:26:19 PST
Created
attachment 267322
[details]
screenshot Originally reported at
https://bugzilla.gnome.org/show_bug.cgi?id=759378
There is a gradient in the background of large text fields, as can be seen in the "Description" field in the attached screenshot. Michael Catanzaro suggested in the above bug report that it's rendered from WebKit in WebCore::RenderThemeGtk::paintTextField, using gtk_render_background, mimicking the background for a GtkEntry, but such fields would be a GtkTextView in GTK parlance, not a GtkEntry, so it should be rendered as such and have e.g. a plain background instead of the background image gradient.
Attachments
screenshot
(144.98 KB, image/png)
2015-12-14 14:26 PST
,
Cosimo Cecchi
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Michael Catanzaro
Comment 1
2015-12-15 04:49:24 PST
Hm, good point about GtkTextView. Perhaps WebCore::RenderThemeGtk::paintTextArea should not call paintTextField. I think paintTextField should probably continue to use GtkEntry style, but paintTextArea should switch to using GtkTreeView style. Does this seem sane?
Carlos Garcia Campos
Comment 2
2016-01-11 06:10:22 PST
I'm not sure, using GtkTextView means we need to manually render the border and we lose the focus too. A simpler solution could be to simply not call gtk_render_background for TextArea. Note that paintTextArea is also used for list boxes.
Michael Catanzaro
Comment 3
2016-01-11 07:29:16 PST
(In reply to
comment #2
)
> I'm not sure, using GtkTextView means we need to manually render the border > and we lose the focus too.
Ugh, no. I ran into this problem too when I tried, thinking this would be an easy change. If it can't be done properly with the foreign drawing API, we should not use it.
> A simpler solution could be to simply not call > gtk_render_background for TextArea. Note that paintTextArea is also used for > list boxes.
It's not really "right" as some themes do not use white for text views (e.g. dark Adwaita), but in those cases it's tough to read black text, so this seems fine to me....
Adrien Plazas
Comment 4
2016-03-09 07:26:12 PST
I don't know if this info is useful but: I can see exactly the same thing on this actual page in Firefox on Fedora 23. Is this behavior normal or does both have this bug?
Michael Catanzaro
Comment 5
2016-03-09 10:51:11 PST
Firefox is not expected to render text fields similar to GTK+. In Adwaita, large text fields should not have any gradient, the bug is that ours should respect that. But since GTK+ does not provide any easy way to accomplish this, I am tempted to close this WONTFIX. (In reply to
comment #2
)
> A simpler solution could be to simply not call > gtk_render_background for TextArea.
That would break themes that use a gradient in text areas. OTOH it would avoid issues with black text on dark text fields.
Cosimo Cecchi
Comment 6
2016-03-09 11:25:11 PST
(In reply to
comment #5
)
> But since GTK+ does not provide any easy way to accomplish this, I am > tempted to close this WONTFIX.
I don't think this is correct. My understanding of the issue is that WebKit is intentionally using the style of an entry for that field. It could just avoid doing so, and use the style of a textview.
Michael Catanzaro
Comment 7
2016-03-09 14:03:52 PST
(In reply to
comment #6
)
> I don't think this is correct. My understanding of the issue is that WebKit > is intentionally using the style of an entry for that field. It could just > avoid doing so, and use the style of a textview.
But see
comment #2
and
comment #3
for why we don't want to do this. :)
Cosimo Cecchi
Comment 8
2016-03-14 11:34:47 PDT
(In reply to
comment #7
)
> But see
comment #2
and
comment #3
for why we don't want to do this. :)
Unfortunately I don't have enough insight into this issue to know how to overcome the problems mentioned in those comments. But that does not mean there's no bug here IMO.
Michael Catanzaro
Comment 9
2016-04-04 13:40:12 PDT
(In reply to
comment #2
)
> I'm not sure, using GtkTextView means we need to manually render the border > and we lose the focus too.
Worth checking if this is easier now after
https://git.gnome.org/browse/gtk+/commit/?id=d23c6c624628d31fa7c9dd543c96af18954018c2
Alice Mikhaylenko
Comment 10
2022-03-23 09:26:13 PDT
WebKit doesn't use foreign drawing for this anymore, closing.
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