The current implementation of tap-to-zoom uses a normal hit-testing and simply walks the DOM-tree to find a suitable zoomable area. This fails to catch almost all cases of CSS layout that doesn't follow flow. A better solution is to use the areas returned by a rect-based hit-testing and returning the best zoomable area from the result.
Created attachment 134570 [details] Patch
Comment on attachment 134570 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=134570&action=review lets look this over together tomorrow > Source/WebCore/page/TouchAdjustment.cpp:101 > + ASSERT(node->renderer()); > + return node->renderer()->isBox(); > +} What happens if it has a rotation transform? bounding box ? > Source/WebCore/page/TouchAdjustment.cpp:120 > + RenderBox* renderer = static_cast<RenderBox*>(node->renderer()); I believe there is a toRenderBox method
(In reply to comment #2) > (From update of attachment 134570 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=134570&action=review > > lets look this over together tomorrow > > > Source/WebCore/page/TouchAdjustment.cpp:101 > > + ASSERT(node->renderer()); > > + return node->renderer()->isBox(); > > +} > > What happens if it has a rotation transform? bounding box ? > Yes. This is similar to the current code. Also in this case bounding box is not an approximation. The bounding box is truly what we want to zoom to. I don't think UI's are ready for zoom and rotate :D > > Source/WebCore/page/TouchAdjustment.cpp:120 > > + RenderBox* renderer = static_cast<RenderBox*>(node->renderer()); > > I believe there is a toRenderBox method Right!
Created attachment 134789 [details] Patch
Comment on attachment 134789 [details] Patch Nice improvement with layout tests!
Comment on attachment 134789 [details] Patch Clearing flags on attachment: 134789 Committed r112669: <http://trac.webkit.org/changeset/112669>
All reviewed patches have been landed. Closing bug.