Created attachment 55890 [details] Screenshot showing the issue The combobox in graphics mode is using a proxy widget and thus doesn't seem to be notified when the proxy widget looses focus, resulting in wrong rendering.
Sounds like a Qt (QGraphicsView) bug... Can you try to make a Qt-only testcase for it and report it upstream?
Alexis, have you seen something like this before? Could it be a QGraphicsProxyWidget problem?
I think we have similar bug, but not exactly the same: https://bugs.webkit.org/show_bug.cgi?id=40082
Created attachment 59999 [details] Patch
Attachment 59999 [details] did not pass style-queue: Failed to run "['WebKitTools/Scripts/check-webkit-style', '--no-squash']" exit_code: 1 WebKit/qt/WebCoreSupport/QtFallbackWebPopup.cpp:110: Declaration has space between type name and * in QGraphicsView *firstView [whitespace/declaration] [3] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 60003 [details] Patch v2 Fixed style issues.
Comment on attachment 60003 [details] Patch v2 Fine with me. Girish made the original patch because it was needed for SecondLife, maybe you should notify him.
(In reply to comment #6) > Created an attachment (id=60003) [details] > Patch v2 > > Fixed style issues. does you patch fix bug 39066?
(In reply to comment #8) > (In reply to comment #6) > > Created an attachment (id=60003) [details] [details] > > Patch v2 > > > > Fixed style issues. > > does you patch fix bug 39066? /s/you/your
(In reply to comment #8) > (In reply to comment #6) > > Created an attachment (id=60003) [details] [details] > > Patch v2 > > > > Fixed style issues. > > does you patch fix bug 39066? No but I had a similar problem which this patch corrects. The context menu bug feels like there is a graphicsView->mapFromScene(graphicsWebView->mapToScene(pos)) missing somewhere.
Comment on attachment 60003 [details] Patch v2 I think that this patch should not go in. After having a look I saw that QtAbstractWebPopup is not exposed in the API, and this patch would change the containment of a QGraphicsWebView inside a scene like SecondLife probably needed. To use a QWidget combo box popup we would need to know if the developer wants to use QGraphicsWebView for its advantages (like accelerated compositing, tiling) or because he wants it inside a QGraphicsScene. Until we have a flag or a class that separate these two cases I think we should keep this behavior for popups. I have another fix (mostly in Qt) for this bug and I'll push it when possible.
Created attachment 60130 [details] Patch (complementary to the one in Qt) The patch in Qt will close the popop on wheel event like for QWidgets outside a graphic scene. This patch make sure that we catch the popup hide event since the popup is directly closed by the QGraphicsScene.
Comment on attachment 60130 [details] Patch (complementary to the one in Qt) Clearing flags on attachment: 60130 Committed r62193: <http://trac.webkit.org/changeset/62193>
All reviewed patches have been landed. Closing bug.
Revision r62193 cherry-picked into qtwebkit-2.0 with commit 4bb61fb7b128d99bb98c410716a19e83cdeffe85
I realize this bug is closed but the reason to use a proxy widget is so that the scene can render the popup when using QGraphicsScene::render(). With a QWidget combo box, the popup simply won't render since it's not part of the scene.