Bug 79680 – Webkit GTK 1.6.3 (535.4) misrenders some UI widgets

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Layout and Rendering

[eris0xff]

Created attachment 129059 [details]
Screen shot of renderig errors in Midori

Webkit 535.4, GTK Version mis-renders UI widgets.  Especially apparent on drop-down selector boxes and text input fields.

Web pages exhibiting this behavior include one or more of the UI widgets in question.  Behavior is especially apparent during rapid up-down scrolling.  The UI widgets seem to render in the wrong area, usually collecting on the left side of the display.  Sometimes the upper left side.

Sometimes by slowly scrolling down and then back up again, the mis-rendering goes away.  It's very unpredictable.

Platform Information
--------------------

Debian Linux SID
(aptosid distribution -- very recent rolling release)

Midori "about:" reports:

about:version

Version numbers in brackets show the version used at runtime.

Command line	midori
Midori	0.4.3
WebKitGTK+	1.6.1 (1.6.3)
GTK+	2.24.8 (2.24.10)
Glib	2.30.2 (2.30.2)
libsoup	2.36.1
cairo	1.10.2 (1.10.2)
libnotify	0.7.4
libunique	1.1.6
libhildon	No
Platform	X11; Linux x86_64
Identification	Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/535+ (KHTML, like Gecko) Version/5.0 Safari/535.4+ Midori/0.4
Video Formats	 H264: true Ogg Theora: true WebM: true
Netscape Plugins:

gxineplugin.so	gxine starter plugin

Other Information
-----------------
- Both Midori and Gtklauncher (simple web browser) exhibit this behavior.  They are both using the same version 1.6.3 of libwebkitgtk-1.0
- Gnome/Epiphany browser on the same platform does *not* exhibit this behavior.  It uses uses libwebkitgtk-3.0.
- Don't know if this is relevant, but the X session was being viewed using a remote X session (over NX / x2go / ssh)

[eris0xff]

Created attachment 129060 [details]
Webkitgtk rendering errors in GtkLauncher

Another example.  This one in the simplest possible browser (Gtklauncher).  This shows the very common rendering error in the upper left.

(For another interesting UI rendering error, go to slashdot.org and scroll up and down rapidly.  It renders UI circles and sometimes dashes).

[eris0xff]

Created attachment 129078 [details]
about:widgets rendering in midori

Here is the definitive "about:widgets" webkitgtk rendering.  It clearly shows numerous rendering errors.

I can confirm the exact same behavior with cross-compiled webkitgtk 1.6.x for Windows.

Native widgets are stacked up in the top left corner of the page, like in attachment: 
https://bugs.webkit.org/attachment.cgi?id=129060 

When page is scrolled widget disappears entirely. 
When mis-rendered widget is visible sometimes you can
interact with it (for example check the checkbox). 

This issue seems to be worked around somewhat when applying  
-webkit-appearance: none; 
style to the widgets, as it can be seen in third column of attachment: 
https://bugs.webkit.org/attachment.cgi?id=129078


For the record:
Webkitgtk 1.4.2 cross compiled and run with the same version of libraries
behaves as intended. Widgets are in proper place, stay on scroll.

When using webkitgtk 1.7.x widgets are no longer stuck in the corner
and they stay in the proper place when scrolling as well. 
Instead one can see black borders
around widgets like ones here:

http://kalev.fedorapeople.org/midori_about_widgets.png

Again applying --webkit-appearance: none; seems to help somewhat.

[eris0xff]

This issue is resolved if I switch from using my Windows X Window Server (x2go Windows client) to my VMWare vSphere console.  The only failure mode common to myself and the other poster (tuxator) is that we are both using webkitgtk (1.6.x+) on a 'mingw' stack.  

(I'm not sure I understand the implications of that.  Perhaps it's a timing or other issue in the mingw support libraries, or perhaps it just exposes an already existing issue in webkitgtk.  Certainly it's not anything in the X Window layer itself.)

Again, my vSphere console (running on Windows) does not exhibit the issue.  Don't know why. The only difference is that mingw is not in the stack.  

I don't have any way currently to test this problem on a physical console.  Maybe tonight.

[Aaron Robertson]

Confirming this behavior under a somewhat different set of circumstances than those previously listed.

I'm running two heads on a nvidia card with the proprietary driver using Xinerama, and all of my WebKitGTK browsers are exhibiting this. The interesting thing is that, when I run only one head, or on both heads using TwinView (neither being a particularly-appealing workaround), the behavior is no longer exhibited at all. This tells me that I'm getting this behavior as a result of a lack of xrandr extensions on my display, a state common to all setups I've seen this bug with. Given the odd assortment of environments associated with most of the comments in this report, like X over ssh and a Windows cross-compile, my (admittedly disclaimer-warranting) thinking is that a lack of information on the display is causing something in WebKit's GTK widgeting faculty to wig out (only GTK widgets on the page seem to be affected).

I'll be testing this on an assortment of other setups, but, so far, I've only been able to replicate in environments lacking xrandr extensions. Dual-head on an Intel IGP using xrandr seems to work fine.

For posterity's sake:

Midori	0.4.4
WebKitGTK+	1.6.3 (1.6.3)
GTK+	2.24.10 (2.24.10)
Glib	2.30.2 (2.30.2)
libsoup	2.36.1
cairo	1.10.2 (1.10.2)
libnotify	0.7.4
single instance	libunique 1.1.6
Platform	X11; Linux i686
Identification	Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/535+ (KHTML, like Gecko) Version/5.0 Safari/535.4+ Midori/0.4
Video Formats	 H264 [x]   Ogg Theora [x]   WebM [x]

[Sameer Naik]

Hi,
I am seeing the same black borders issue with WebKiTGtk+-1.6.3. The WebKiTGtk+-1.2.x is fine in this respect.

I am compiling Webkit for an embedded system with Gtk-Directfb.

Did you have any success in figuring out the issue?

Regards
~Sameer

[Grant Gayed]

*** Bug 75872 has been marked as a duplicate of this bug. ***

[Michael Roberts]

Created attachment 232259 [details]
Black Boxes Around Inputs

[Michael Roberts]

Comment on attachment 232259 [details]
Black Boxes Around Inputs

I am having this black box issue surrounding inputs as well.  Running Debian Jessie with libwebkitgtk-1.0-1 version 2.4.2-1 and midori version 0.5.8-1~trusty~ppa1.

[Adrian Perez]

We have not supported legacy WebKit1 for a long time, I think we
can close this.