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.
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?
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.
(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....
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?
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.
(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.
(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. :)
(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.
(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
WebKit doesn't use foreign drawing for this anymore, closing.