|Summary:||[Qt] QWebPage::createPlugin() ignores visibility attribute in 4.5|
|Product:||WebKit||Reporter:||Andy Nichols <andy.nichols>|
|Component:||New Bugs||Assignee:||Benjamin Poulain <benjamin>|
|Severity:||Normal||CC:||benjamin, dglazkov, jturcotte, kenneth, laszlo.gombos, vestbo, zecke|
Description Andy Nichols 2009-11-06 05:09:17 PST
In Qt Extended 4.4.2, the visibility attribute in the <div> tag of an html file correctly hides a QLineEdit object on a QWebPage created by QWebPAge::createPlugin(). In Qt 4.5.3, the visibility attribute seems to be ignored altogether, resulting in the QLineEdit object always being visible. <div id="hiddenLineEdit" style="visibility: hidden"> Hidden Field: <object type="application/x-qt-plugin" classid="LineEdit" height="30" width="180" contents="hide me" name="lineedit1"></object> </div> Attached example reproduces issue.
Comment 2 Holger Freyther 2009-11-12 19:10:01 PST
Created attachment 43127 [details] Fix the cause of this bug WebCore::Widget was handling show/hide properly but the QtPluginWidget::frameRectChanged was calling setVisible undoing the effect of show/hide.
Comment 3 Kenneth Rohde Christiansen 2009-11-13 04:51:08 PST
Comment on attachment 43127 [details] Fix the cause of this bug We have some manual-tests. Have you run those? Especially for testing the clipping. Also, doesn't WebCore::Widget have code for knowing if it is visible or not, that can be used instead of m_visible?
Comment 4 Kenneth Rohde Christiansen 2009-11-16 11:30:59 PST
Comment on attachment 43127 [details] Fix the cause of this bug Patch has been cherry-picked into Qt 4.6, but zecke will redo it for inclusion in trunk. The test will be turned into a real layout test and the code will make use of setSelfVisible from WebCore::Widget.
Comment 5 Holger Freyther 2009-11-23 07:04:38 PST
Created attachment 43712 [details] Move PluginViewQt.cpp PluginView::show/::hide to Widget::show/::hide Fix the bug by making use of Widget::isVisible, isSelfVisible, isParentVisible... Update the manual test to include the problem seen here.
Comment 6 Holger Freyther 2009-11-23 07:05:45 PST
Created attachment 43713 [details] Be able to automate tests including a QWidget Print the QWidget properties as part of the RenderPart. This will require us to update some results but I have hundreds of test failures locally (by default...)
Comment 7 Kenneth Rohde Christiansen 2009-11-23 13:09:49 PST
Is this supposed to be up for review?
Comment 8 Holger Freyther 2009-11-24 01:24:21 PST
Comment on attachment 43712 [details] Move PluginViewQt.cpp PluginView::show/::hide to Widget::show/::hide Test cases are passing...
Comment 9 Holger Freyther 2009-11-24 01:25:29 PST
Created attachment 43756 [details] Be able to automate plugin tests using a QWidget Add new test, test result, update the other existing result
Comment 10 Kenneth Rohde Christiansen 2009-11-24 01:35:10 PST
Comment on attachment 43756 [details] Be able to automate plugin tests using a QWidget Great work. Please remove 'Need a short description and bug URL (OOPS!)' from the ChangeLog Should we be testing QGraphicsWidget based plugins as well? might widget in those cases be a QGrapicsWidget and not a QWidget?
Comment 11 Holger Freyther 2009-11-24 14:34:14 PST
Created attachment 43805 [details] Be able to automate plugin test using a QWidget -- Fix the ChangeLog entry Fix the ChangeLog entry, regarding the QGraphicsView and Qt plugins. I don't know yet.
Comment 12 Holger Freyther 2009-11-26 02:38:12 PST
Comment 13 Dimitri Glazkov (Google) 2009-11-26 10:36:00 PST
Shouldn't the test have gone to platform/gt/plugins instead of just plugins?
Comment 14 Holger Freyther 2009-11-26 18:39:19 PST
(In reply to comment #13) > Shouldn't the test have gone to platform/gt/plugins instead of just plugins? For me it looked to be in the same class as the ObjC plugins that are in the plugin directory as well. We can consider moving all those away though.
Comment 15 Jocelyn Turcotte 2009-12-07 07:13:27 PST
*** Bug 29451 has been marked as a duplicate of this bug. ***
Comment 16 Holger Freyther 2009-12-13 18:44:49 PST
I waited for Dimitri to respond to my response. If Dimitri thinks there should be more work done we can reopen the bug again, for now closing is the most easy way to make it drop out of the review queue.