Bug 79680 - Webkit GTK 1.6.3 (535.4) misrenders some UI widgets
: Webkit GTK 1.6.3 (535.4) misrenders some UI widgets
Status: UNCONFIRMED
: WebKit
Layout and Rendering
: 528+ (Nightly build)
: Other Linux
: P2 Major
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-02-27 10:01 PST by
Modified: 2012-05-11 11:31 PST (History)


Attachments
Screen shot of renderig errors in Midori (134.30 KB, image/png)
2012-02-27 10:01 PST, eris0xff
no flags Details
Webkitgtk rendering errors in GtkLauncher (86.88 KB, image/png)
2012-02-27 10:04 PST, eris0xff
no flags Details
about:widgets rendering in midori (63.28 KB, image/png)
2012-02-27 11:39 PST, eris0xff
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-02-27 10:01:32 PST
Created an attachment (id=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)
------- Comment #1 From 2012-02-27 10:04:06 PST -------
Created an attachment (id=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).
------- Comment #2 From 2012-02-27 11:39:31 PST -------
Created an attachment (id=129078) [details]
about:widgets rendering in midori

Here is the definitive "about:widgets" webkitgtk rendering.  It clearly shows numerous rendering errors.
------- Comment #3 From 2012-02-27 12:05:44 PST -------
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.
------- Comment #4 From 2012-02-27 17:59:13 PST -------
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.
------- Comment #5 From 2012-03-13 08:39:05 PST -------
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]
------- Comment #6 From 2012-05-04 08:37:50 PST -------
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
------- Comment #7 From 2012-05-11 11:31:00 PST -------
*** Bug 75872 has been marked as a duplicate of this bug. ***