Fixes to the Unix version of TestNetscapePlugin have uncovered a bug in PluginViewQt. This is related to a special-case for DumpRenderTree.
Committed r72719: <http://trac.webkit.org/changeset/72719>
http://trac.webkit.org/changeset/72719 might have broken GTK Linux 64-bit Debug
The following tests are not passing:
Created attachment 79103 [details]
Comment on attachment 79103 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=79103&action=review
> + const char* chr = qKeyEvent->text().left(1).toUtf8().constData();
> + xEvent->xkey.keycode = XKeysymToKeycode(QX11Info::display(), XStringToKeysym(chr));
'chr' points to deleted data on the second line since the QByteArray returned by toUtf8() is temporary.
Created attachment 79106 [details]
Comment on attachment 79106 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=79106&action=review
LGTM, thanks for attending to this!
> + QString chr = qKeyEvent->text().left(1);
Nit: We don't abbreviate variable names in WebKit.
Created attachment 79108 [details]
Comment on attachment 79108 [details]
Clearing flags on attachment: 79108
Committed r75894: <http://trac.webkit.org/changeset/75894>
All reviewed patches have been landed. Closing bug.
Committed r75895: <http://trac.webkit.org/changeset/75895>
http://trac.webkit.org/changeset/75897 might have broken Leopard Intel Release (Build)
I had to re-skip plugins/keyboard-events.html because it failed on the buildbot.
The change that broke this originally for Qt is http://trac.webkit.org/changeset/72717
I think the reason my patch failed is as follows, and am hoping Martin might be amenable to going back to using the keysym for this event.
In order to get the keycode of the keyboard event, we have to do:
xEvent->xkey.keycode = XKeysymToKeycode(QX11Info::display(), XStringToKeysym(keyText.toUtf8().constData()));
At first I thought it failed on the buildbot because it was headless, but the tests are run under xvfb so that was only half-right. The real reason, it seems to me, is because xvfb doesn't have a keyboard, so XKeysymToKeycode will always fail. (See http://lists.apple.com/archives/x11-users/2009/Apr/msg00016.html for an example of this elsewhere).
Since there's no keyboard mapping available to xvfb it can't determine the keycode. I recreated the problem in Ossy's 'QtWebKit Builder and Tester VM (Q-BAT VM)'.
I'm going to drop to a terminal session on this machine with no x server running so see if I can recreate it here too. I'll come back with my results but it looks as if using the keycodes won't work for us running our buildbot under xvfb.
Looking at the output from the other buildbots I think qt may be alone running the layout tests under xvfb. Who would be able to confirm that do you know?
So much for that theory - I can pass the test using xvfb-run in a session with no X server running on my own machine. The test always fails for me in the VM.
My version of Xvfb is from xorg-server 1.7.6, the version of Xvfb on the VM/buildbot is 1.4.2. Mmmm...
So that's my new copper-bottomed theory. I guess we wait for the buildbot to upgrade to debian squeeze and try again!
Bbandix, could you check Robert's idea on your hyper-up-to-date Arch Linux? :)
For ease of reference, this should pass:
xvfb-run --server-args="-screen 0 1024x768x24" Tools/Scripts/run-webkit-tests --
no-launch-safari --qt plugins/keyboard-events.html $@
Committed r86938: <http://trac.webkit.org/changeset/86938>