Additional data point - the mouse offset seems to be both horizontal and vertical, but linear and relative to the top-left corner of the window. That is, if I'm pointing at the top-left corner, there's no offset, but as I move the mouse down or right the offset gets worse and worse.

Also, it's not required for me to actually drag the window to another monitor. There seems to be a "home" monitor (normally the internal monitor, but I can't say always) where the mouse tracking is correct, and even if the window opens on another monitor it will still be  wrong. 

This issue seems to correct itself if you resize the window.

Bisected to 58.0.3014.0, producing the following change list:

https://chromium.googlesource.com/chromium/src/+log/32e074e42207bf161510aba4c4b5539d0818d2f1..ecfcc163f15b17c9a04b1f62db1ff8cf11d9eccc

None of the changes seem like they could be the cause. Looking between 58.0.3013.0 and 58.0.3014.0, the following change stands out because it discusses directly forwarding mouse events for OOPIF, and this bug is a combo of extensions and incorrect mouse location calculations on a screen with a different resolution than the originating screen:

commit	9b5618b8aa52feeccbb3203046b56b8e75d9423a	
author	lfg <lfg@chromium.org>	Wed Feb 15 20:43:37 2017
committer	Commit bot <commit-bot@chromium.org>	Wed Feb 15 20:43:37 2017
Unify the code paths for handling mouse events when pointer is locked on
WebViewImpl and WebFrameWidgetImpl.

BUG= 618460 

Review-Url: https://codereview.chromium.org/2696523003

This is unrelated to my change, it happened when nasko@ enabled SiteIsolationExtensions in r450821.

I think this is because we don't propagate DPI changes to OOPIFs when the window moves from a hidpi screen to a lodpi screen, but I'm wondering if this is still the case on the canary channel. Can we get that tested?

I originally suspected r450821 but realized it could not be responsible. When I git reverted that change and compiled chrome to verify, ninja did no work - if you look at the changed files, they are all tests, and the json file just turns on waterfall testing. It might be site isolation-related, but it's not caused by r450821. That is why I started examining a larger commit range and am wondering about commit 9b5618b8aa52feeccbb3203046b56b8e75d9423a .

If you go to go/bisect-build you can do single-CL bisects.

That said, around that time we were using a Finch configuration for the site isolation experiment, so you would also have to disable experiments to get a correct bisect.

Not following either of your comments in c#7. Did you run a bisect-build and wound up on r450821? That change only modifies tests.

This seems likely to be related to 659642 (even though that bug is listed as Win-specific), so I'm going to dupe this into that one, at least for now.

Re#8: Sorry, the correct link is go/bisect-builds. What I meant is that there is this internal tool that can bisect to a single CL, instead of a range like you got.