UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.113 Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce the problem:
1. Load a page that includes a hyperlinked region that is partially occluded by
   other content (e.g. partially_occluded_hyperlink.html attached).
2. Print the page to PDF through Chromium, selecting "Background graphics" under
   "More settings".
3. Observe that the entire yellow square is hyperlinked in the output PDF,
   including the area occluded by the red rectangle.

What is the expected behavior?
Only the yellow area should be hyperlinked---none of the red area should be
hyperlinked.

What went wrong?
Hyperlinks are clickable on regions of the printed page that should not be
clickable based on occlusion.

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 60.0.3112.113  Channel: stable
OS Version: 16.04
Flash Version: Shockwave Flash 26.0 r0

== Attached Artifacts ==

Compare the clickable region when loading the attached .html versus the
clickable region when loading the .pdf.  I also attach a .png screenshot,
illustrating the hyperlink tooltip when the cursor is positioned over the red
box in the .pdf.

== Preliminary Diagnosis ==

I believe this issue spans both Blink and Skia.

Skia:

On the one hand, SkPDFDevice appears to draw all "annotations" (e.g. hyperlinks)
last.  See SkPDFDevice::drawAnnotation, which enqueues annotations for later
drawing rather than drawing them "inline".  Annotations get drawn during
SkPDFDocument::onEndPage(), causing annotations to appear on top rather than
honoring occluding elements.  So, I believe the first step is correcting
SkPDFDevice to draw the annotations "inline" rather than queuing and drawing at
the end.

Blink:

On the other hand, I noticed that on more complex pages, the draw call order
sometimes, but not always, calls drawAnnotation() prior to the content being
annotated.  This might result in the opposite problem, where a hyperlink which
should be clickable is occluded by its content.  For example, a piece of text
that is meant to be hyperlinked might have this call order:

SkDevice::drawAnnotation()
SkDevice::drawtext()

instead of:

SkDevice::drawText()
SkDevice::drawAnnotation()

So, there might be a second step to shuffle some calls in blink to ensure the
device draw order ultimately ends up being correct.
 

Deleted: partially_occluded_hyperlink.html 249 bytes

partially_occluded_hyperlink.html 249 bytes View Download

Deleted: partially_occluded_hyperlink.pdf 24.8 KB

partially_occluded_hyperlink.pdf 24.8 KB Download

Deleted: partially_occluded_hyperlink.png 32.0 KB

	partially_occluded_hyperlink.png 32.0 KB View Download