If we set CONFIG += use_qt_mobile_theme in Source/WebKit.pri, which adds ENABLE_NO_LISTBOX_RENDERING=1 to DEFINES in WebCore.pro, the menuList will be used and WTR aborts when running the above layout test. The abort message comes from Qt5 qxcbwindow.cpp, qFatal("no window!").
Do you have a backtrace? If it comes from qxcbwindow, then it sounds like it would come from the ui process, given that you probably start the web process with either minimal or your own platform plugin, right? So what in the ui process tries to do the evil stuff? :)
Yes, please see the backtrace below: #1 0xb464f651 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb4652a82 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb4a2f965 in qt_message_output (msgType=QtFatalMsg, buf= 0x8324e18 "no window!") at global/qglobal.cpp:2101 #4 0xb4a2fb5e in qt_message (msgType=QtFatalMsg, msg=0xb08d7761 "no window!", ap=0xbfda8fc4 "") at global/qglobal.cpp:2147 #5 0xb4a2fec7 in qFatal (msg=0xb08d7761 "no window!") at global/qglobal.cpp:2325 #6 0xb08b6ec9 in QXcbWindow::create (this=0x8328518) at qxcbwindow.cpp:244 #7 0xb08b689a in QXcbWindow (this=0x8328518, window=0x8328438) at qxcbwindow.cpp:154 #8 0xb08a9307 in QXcbIntegration::createPlatformWindow (this=0x82c79a0, window=0x8328438) at qxcbintegration.cpp:120 #9 0xb4e8bc80 in QWindow::create (this=0x8328438) at kernel/qwindow.cpp:155 #10 0xb55c2cee in QWidgetPrivate::create_sys (this=0x8314740, window=0, initializeWindow=true, destroyOldWindow=true) at kernel/qwidget_qpa.cpp:130 #11 0xb55898ec in QWidget::create (this=0x831e190, window=0, initializeWindow=true, destroyOldWindow=true) at kernel/qwidget.cpp:1346 #12 0xb558daa6 in QWidgetPrivate::createWinId (this=0x8314740, winid=0) at kernel/qwidget.cpp:2320 #13 0xb558d835 in QWidget::winId (this=0x831e190) at kernel/qwidget.cpp:2279 #14 0xb686271d in WebKit::WebPopupMenuProxyQtDesktop::WebPopupMenuProxyQtDesktop (WebKit::WebPopupMenuProxy::Client*, QQuickItem*) () from /home/cshu/webkit.wk2/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4 #15 0xb6856369 in QtDesktopWebPageProxy::createPopupMenuProxy(WebKit::WebPageProxy*) () from /home/cshu/webkit.wk2/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4 #16 0xb6835731 in WebKit::WebPageProxy::showPopupMenu(WebCore::IntRect const&, unsigned long long, WTF::Vector<WebKit::WebPopupItem, 0u> const&, int, WebKit::PlatformPopupMenuData const&) () from /home/cshu/webkit.wk2/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4 #17 0xb68a40b1 in void CoreIPC::handleMessage<Messages::WebPageProxy::ShowPopupMenu, WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(WebCore::IntRect const&, unsigned long long, WTF::Vector<WebKit::WebPopupItem, 0u> const&, int, WebKit::PlatformPopupMenuData const&)>(CoreIPC::ArgumentDecoder*, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WebCore::IntRect const&, unsigned long long, WTF::Vector<WebKit::WebPopupItem, 0u> const&, int, WebKit::PlatformPopupMenuData const&)) () from /home/cshu/webkit.wk2/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4
Like mentioned on IRC yesterday, I think that this is probably best qualified as Qt bug. The issue is that Qt thinks that the computer in question supports OpenGL, while in fact it doesn't do that properly, because the glx call fails that is supposed to determine the visual for window that needs to be created. It seems that a bit of robustness may be needed there. However the easiest way to work around this is by fixing the computer setup :). I'm closing this as WONTFIX for WebKit, because I don't see what's broken in WebKit (although there are reasons to rewrite WebPopupMenuProxyQtDesktop to use different code in Qt, but that should be a different bug report :)
(In reply to comment #3) > Like mentioned on IRC yesterday, I think that this is probably best qualified as Qt bug. > > The issue is that Qt thinks that the computer in question supports OpenGL, while in fact it doesn't do that properly, because the glx call fails that is supposed to determine the visual for window that needs to be created. It seems that a bit of robustness may be needed there. > > However the easiest way to work around this is by fixing the computer setup :). > > > I'm closing this as WONTFIX for WebKit, because I don't see what's broken in WebKit (although there are reasons to rewrite WebPopupMenuProxyQtDesktop to use different code in Qt, but that should be a different bug report :) Can you help me figure out which setup I might have been missing? Thanks
Somehow the graphic driver on my machine was messed up. Thanks for the help.