Comment 1 by mdcurran on 2014-02-21 04:48
Annoyingly this is actually in master, and now also in the rc. It's a regression caused by #3758.
Technical:
Now that NVDA reports itself as DPI aware, When NVDA fetches the caret rectangle with GetGUIThreadInfo from an app that is not DPI aware, Windows tries to convert rcCaret from logical to physical coordinates. But when we then convert it back to logical coordinates for searching in displayModel, it's offset by an incorrect amount. E.g. when it should be 14 its 12. When it should be 23 it's 19 etc. Note that simply not calling physicalToLogicalPoint for the caretRect still yields incorrect coordinates.
The best way this can be fixed is to have GetGUIThreadInfo be called in-process via an RPC call, to ensure that it is fetched in exactly the same way the rest of the displayModel coordinates would be fetched.
Changes:
Milestone changed from None to 2014.1

Comment 2 by Michael Curran <mick@... on 2014-02-21 04:49
In [5c67adb07fe6480c24dddac2c3a56352a2cfbe6f]:

When fetching the caret rectangle for tracking in displayModel text, make an rpc call and use GetGUIThreadInfo in-process as Windows' logical to physical coordinate conversion is rather stuffed for cCaret. Re #3901

Comment 3 by jteh on 2014-02-21 05:50
Damn. The thing that confuses me about this is that if Windows maps from logical to physical, surely the reverse mapping should be symmetrical. I can understand it breaking when converting from physical (DPI aware) to logical (DPI unaware), as you're scaling down in that case so you lose resolution, but i can't see why resolution should be lost when scaling up.

As a matter of interest, if you take the coordinates from in-process rcCaret, convert to physical and then convert those physical coordinates back to logical, do you get the original coordinates? If you do, that suggests it's really just rcCaret conversion that's affected. If not, I'm very concerned about mouse routing with display model in general, though I don't think there's a workable solution for that.

Comment 4 by k_kolev1985 on 2014-02-22 11:39
Is this supposed to be fixed in the "next" snapshots from yesterday or today? Because if it is, I can still reproduce it in Balabolka (don't know about other apps/controls).

Comment 5 by jteh on 2014-02-22 11:41
No. It hasn't been merged to next yet. We'll merge it to rc (and release rc2) once Mick and I have a chance to talk about it.

Comment 6 by James Teh <jamie@... on 2014-02-24 22:24
In [b0b4622]:

Fix tracking of the caret for some editable text fields that rely on text written to the screen such as the main text area in Balabolka.

When fetching the caret rectangle for tracking in displayModel text, make an rpc call and use GetGUIThreadInfo in-process as Windows' logical to physical coordinate conversion is rather stuffed for cCaret.
Fixes #3901.

Changes:
State: closed

Comment 7 by k_kolev1985 on 2014-03-07 09:30
Yes, this was merged in the RC branch. I saw that there were a few merges of RC into master and then into next these days. But even with next-10416,8ef0ebb, the problem still exists in Balabolka. But in the RC branch it is fixed - it works as it should. Why? Wasn't this change merged in the next branch as well? Or some of my add-ons is causing problems in this case in my next snapshot?