+dmazzoni do you think we should use clipboard copy/paste in PDF too? Or should selection be fixed to work on PDFs?

Fixed in https://chromium-review.googlesource.com/936454

Reverting to Assigned to katie@ 

Google Chrome 67.0.3369.0 (Official Build) canary (64-bit)
Firmware Version Google_Samus.6300.276.0
Flag enabled: #enable-experimental-accessibility-features


# Enable STS in Accessibility Settings
# Launch text PDF such as this one: http://unec.edu.az/application/uploads/2014/12/pdf-sample.pdf
# Highlight text using mouse then press Search + s
Expected: STS reads text
Actual: earcon is played for nothing selected 

# Clear highlight on the PDF by clicking anywhere with the mouse
# Invoke STS by pressing search button and dragging highlight around text in the PDF
Expected: highlight appears around text and word highlighting lines up with word being read
Actual: Highlight ring is offset from actual selection, word highlighting is moving in this offset area and doesn't line up visually with any words.

This was working, Laura can you please bisect to help determine where it went wrong?

It was working as of Dominic submitting that change:
https://chromium-review.googlesource.com/c/chromium/src/+/936454 / commit 4d87bccef0d6c07cdecf43449af4157736ac3f35

Actually it seems to work on my emulated Chrome OS on Linux, but it fails on my Eve device.

But, it appears that the focus rect is also wrong in Chromevox.

It looks like a problem on higher resolution machines -- low resolution chromebooks don't have the problem, and high resolution emulated chromeos does.

 Issue 811504  has been merged into this issue.

Looks like the embeddedObject of the PDF has the right location bounds, but the "group" inside of that has the wrong location bounds.

I wonder if "use zoom for device scale factor" has anything to do with it:

 content/public/common/use_zoom_for_dsf_policy.cc

In particular, this is supposed to be handled by PdfAccessibilityTree::GetDeviceScaleFactor and I think it used to be working.

There's a new flag --enable-use-zoom-for-dsf and I wonder if the bug only happens when the flag is on or off.

The correct fix should be to figure out the right scale factor and have PdfAccessibilityTree::GetDeviceScaleFactor return the right number, rather than calling any other function to convert coordinates.

OK, I figured out that zoom_ and GetDeviceScaleFactor() are now returning the same number, so in PdfAccessibilityTree::MakeTransformFromViewInfo() they were just canceling each other out.

Just removing the division by GetDeviceScaleFactor() fixes things in PdfAccessibilityTree::MakeTransformFromViewInfo() on Chrome OS.

My concern is that this might break things on other platforms. I still suspect that --enable-use-zoom-for-dsf is related.

See these related bugs: 821089, 741171,  737777 , 716231

My suggestion would be to figure out from those bugs who seems to be knowledgeable about this and get their help figuring out the correct fix.

Just confirming here at bisect is no longer needed since it appears that the root cause has been found. If you need anything else, please let me know!

I'd be curious if Chromevox gets bounds correct in high-resolution PDFs in Chrome 63 or 64. If so, a bisect may be worth while. Otherwise, this bug has probably always been around.