Simplified repro:
1. open the attached test.html
2. click anywhere inside the embedded PDF
3. observe "Click status" at the top

Expected: "PDF document" text is shown
Observed: nothing

Bisected to r526154 = 8e8ae37d2e02943cadb4d658777866e8e4a12f60 = https://crrev.com/c/838626 by sadrul@chromium.org
"event router: Use mojom.InputTargetClient for targeting."
Landed in 65.0.3304.0

Deleted: test.html 10.9 KB

test.html 10.9 KB View Download

Able to reproduce this issue on Windows 10, Mac OS 10.13.5 and Ubuntu 14.04 on the latest Stable 67.0.3396.87 and latest Canary 69.0.3463.0 as per comment #1.

Bisect Information:
===================
Good Build: 65.0.3303.0
Bad Build : 65.0.3304.0

By running the per-revision bisect script, below is the Changelog URL.

https://chromium.googlesource.com/chromium/src/+log/d37a9f10c7e32ff40e864a2ff30478fc8a0a1169..8e8ae37d2e02943cadb4d658777866e8e4a12f60

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/838626

sadrul@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Thanks

Thank you all.
I hope this issue will be fixed soon.

Is it possible to fix this bug until the release of stable version 68?
Thank you in advance.

 Issue 863729  has been merged into this issue.

To sadrul@chromium.org:

Could you please fix this bug as soon as possible?
Thank you in advance.

--> kenrb@, /cc+ riajiang@

The current behavior matches that of Firefox, does it not?

There was some discussion about this some time ago, and the behavior of clicks on PDFs generating DOM events. There was some thinking that it shouldn't be that way, and the embedding page only sees interactions with PDFs because of how WebKit implemented plugins.

That behavior is lost because PDFs are now in different processes and events are directly routed to them.

We might consider this working as intended.

I have confirmed that the current behavior matches that of Firefox, even though it changed from previous Chrome behavior. I'd like to call this working as intended and close this bug.

Reporter, this is right now an intended behavior. So this is unlikely to get fixed.
However, can you elaborate more on the usecase that you have? What are you trying to achieve in your webpage?

Specifically speaking, I have wanted to disable contextmenu or want to detect oncontextmenu event.

And even though it is true that the current behavior is the same as Firefox's internal PDF Viewer, however, please compare it with Internet Explorer in relation to Adobe Reader.

Internet Explorer's JavaScript can communicate with Adobe Reader's Acrobat JavaScript (hostContainer), thus can control Adobe Reader through DOM. For example, you can change the current page or change the zoom percentage, with your own HTML interface, without relying on Adobe Reader's native interface.

From another perspective, you can know which page your readers are reading now and how much minutes they are reading the page. You can know when they left your site, and which page is attractive or boring.


I hope that in the future with Google Chrome as well it can communicate with embedded PDF and enable us to control it through DOM.

Re: comment 14, I can't authoritatively speak to the feasibility of that (although I believe it would be contrary to the goals of same origin policy, since a PDF loaded from another origin could be sensitive), but I'm closing this bug since we consider the current input event behavior is correct.