Fix links in inline continuations in printed PDF

third_party/WebKit/Source/core/paint/BlockPainter.cpp

Index: third_party/WebKit/Source/core/paint/BlockPainter.cpp
diff --git a/third_party/WebKit/Source/core/paint/BlockPainter.cpp b/third_party/WebKit/Source/core/paint/BlockPainter.cpp
index d1371af3162d690059078612b5b307404f7c0f2e..0abb334b79287969e1b4521cee1e00556631b63c 100644
--- a/third_party/WebKit/Source/core/paint/BlockPainter.cpp
+++ b/third_party/WebKit/Source/core/paint/BlockPainter.cpp
@@ -151,8 +151,6 @@ void BlockPainter::paintObject(const PaintInfo& paintInfo, const LayoutPoint& pa
         return;
     }
 
-    // FIXME: When Skia supports annotation rect covering (https://code.google.com/p/skia/issues/detail?id=3872),
-    // this rect may be covered by foreground and descendant drawings. Then we may need a dedicated paint phase.
     if (paintPhase == PaintPhaseForeground && paintInfo.isPrinting())
         ObjectPainter(m_layoutBlock).addPDFURLRectIfNeeded(paintInfo, paintOffset);
 
@@ -213,6 +211,16 @@ void BlockPainter::paintCarets(const PaintInfo& paintInfo, const LayoutPoint& pa
 bool BlockPainter::intersectsPaintRect(const PaintInfo& paintInfo, const LayoutPoint& paintOffset) const
 {
     LayoutRect overflowRect = m_layoutBlock.visualOverflowRect();
+
+    if (paintInfo.isPrinting() && m_layoutBlock.isAnonymousBlock() && !m_layoutBlock.previousSibling() && m_layoutBlock.childrenInline()) {

[chrishtr, 2016/01/14 23:29:32]

Why can't we always use this path? Is it really too inefficient?

[Xianzhu, 2016/01/14 23:41:41]

Do you mean use the path also for non-printing painting? It's just unnecessary,
and the normal path works fine.

[chrishtr, 2016/01/14 23:56:00]

I mean: why can't we have the same cull rect behavior for PDF and non-PDF? If
the other one
misses things because PDF links are different size, then how about we delete
that logic in favor of the logic you added here?

[Xianzhu, 2016/01/15 01:51:00]

The added logic will cause unnecessary paints which is not a big issue for
printing. It's also only applicable to the anonymous block container of inline
with continuations, so we can't delete the original logic.

[chrishtr, 2016/01/15 02:20:02]

Ok. Now my question is: why are the rects broken in PDF output exactly? Does PDF
have different dimensions
that don't exhibit in regular web pages?

[Xianzhu, 2016/01/15 05:06:44]

The PDF clickable rects are to let the PDF viewers know which parts of the
document are clickable and the URLs to open when clicked. The counterpart in
regular web pages is implemented with hit testing. It's special for PDF printing
during painting.

The PDF rect of a link is the bounding box of the outline of the link. If the
link has continuations, the bounding box also covers the continuations. If the
link did have an actual outline, we would have added the outline area to the
visual overflow of the link and it's container blocks, and the normal
intersection checking path would work. But when printing, the link doesn't have
actual outline, so the continuation part of the link are not in the visual
overflow, causing the intersection check returns early even we have "outline" to
output.

For example,
  <a href="x"><div>Target</div></a>
The layout tree is:
  LayoutBlock anonymous
    LayoutInline A with empty content
  LayoutBlock anonymous
    LayoutBlock DIV
      LayoutText Target
  LayoutBlock anonymous
    LayoutInline A with empty content
      
The first anonymous container block of <a> has empty visual overflow. With the
old code, the anonymous block's paint() method returns immediately because
intersectsPaintRect returns false. We miss painting of the <a> element and thus
miss output of the PDF rect of the link.

+        // For case <a href="..."><div>...</div></a>, when m_layoutBlock is the anonymous container
+        // of <a>, the anonymous container's visual overflow is empty, but we need to continue
+        // painting to output <a>'s PDF URL rect which covers the continuations, as if we included
+        // <a>'s PDF URL rect into m_layoutBlock's visual overflow. For simplicity, we just check
+        // if the parent block intersects paint rect.
+        return BlockPainter(toLayoutBlock(*m_layoutBlock.parent())).intersectsPaintRect(paintInfo, paintOffset);
+    }
+
     if (m_layoutBlock.hasOverflowModel() && m_layoutBlock.usesCompositedScrolling()) {
         overflowRect.unite(m_layoutBlock.layoutOverflowRect());
         overflowRect.move(-m_layoutBlock.scrolledContentOffset());