[Qt] Invalidate relative and absolute co-ords in PluginView
http://trac.webkit.org/changeset/79397
http://trac.webkit.org/changeset/79397 uses frameView->invalidateRect(m_windowRect); to dirty the appropriate region on the screen, so that QWebFrame::renderRelativeCoords() will repaint the correct location of the plugin. This works well except when the plugin is contained in an iframe, such as at www.blognone.com. In that situation, invalidating the location of the plugin has no effect - putting some debug statements in renderRelativeCoords() shows that the plugin's rect does not even show up in the list of dirty rects in 'clip'. The result is that the plugin does not move when you scroll the page, except when the area it is contained in is about to get clipped by the viewport. The simple solution is to just reinstate invalidate() so that we call that in addition to frameView->invalidateRect(m_windowRect);.
Created attachment 87178 [details] Patch
The iframe plugin in blognone.com is: <iframe id='a400cc05' name='a400cc05' src='http://solid.lightdynamic.com/www/delivery/afr.php?zoneid=16&cb=INSERT_RANDOM_NUMBER_HERE' frameborder='0' scrolling='no' width='300' height='250'><a href='http://solid.lightdynamic.com/www/delivery/ck.phpn=af511631&cb=INSERT_RANDOM_NUMBER_HERE' target='_blank'><img src='http://solid.lightdynamic.com/www/delivery/avw.php?zoneid=16&cb=INSERT_RANDOM_NUMBER_HERE&n=af511631' border='0' alt='' /></a></iframe>
Created attachment 87181 [details] Patch
Created attachment 87397 [details] Patch
OK, all my analysis up to now was wrong: the issue r79397 was trying to solve is properly solved by the new patch. PluginViewQt was getting the plugin widget repainted before it had updated the widget's knowledge of its position on the page. As a result, QWebView got a paint event from the widget with the wrong rects for painting.
Comment on attachment 87397 [details] Patch This might be the most sane-looking Qt plugin patch I've seen. r=me :)
Blocking 2.2 (bug 56130, which fixes the problem on symbian has been added to 2.1.x, so it makes sense to fix the problem on all platforms on 2.2).
Comment on attachment 87397 [details] Patch Rejecting attachment 87397 [details] from commit-queue. Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=cr-jail-8', 'land-a..." exit_code: 1 Last 500 characters of output: autoinstalled/mechanize/_urllib2_fork.py", line 332, in _call_chain result = func(*args) File "/mnt/git/webkit-commit-queue/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1170, in https_open return self.do_open(conn_factory, req) File "/mnt/git/webkit-commit-queue/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1118, in do_open raise URLError(err) urllib2.URLError: <urlopen error [Errno 60] Operation timed out> Full output: http://queues.webkit.org/results/8469040
Comment on attachment 87397 [details] Patch Clearing flags on attachment: 87397 Committed r84187: <http://trac.webkit.org/changeset/84187>
All reviewed patches have been landed. Closing bug.