1083132 - text inside translate3d cannot be read or hit-tested correctly

Status: NEW

(Core :: Layout, defect)

Description

[Alex Dima]

Attachment: translate3d.htm

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:

I work on the Monaco editor (used in various places such as http://www.typescriptlang.org/Playground). I recently (not live in the playground page yet) added support that the editor scrolls its virtual viewport using translate3d. AFAIK, this is the only JS code editor doing this cross-browser. Firefox is usually very good, but translate3d & text seem to be pretty broken in some regards and at this point (see test2 in the attached repro) my only recourse is to disable translate3d scrolling for Firefox, which is a shame given that only now I can validate that I'm doing the right thing using the new Highlight Painted Area tool you've rolled out in FF33. Thanks for that, by the way! :)

Long story short, TextRange.getClientRects and document.caretPositionFromPoint don't work as expected when the text is inside a dom node that uses transform:translate3d(x, y, 0);

Please try out attached repro htm which contains two divs, one blue (that uses scrollTop/scrollLeft) and one red (that uses translate3d to simulate scrolling). FF 31 or 32 were broken (in that they exhibited only the bug in TextRange.getClientRects, but only for the vertical space -- funny), but FF 33 is now even more broken: it exhibits the bug in the horizontal space as well and also introduces the bug in document.caretPositionFromPoint. I know this because I noticed the issue in an earlier version of FF, but had code in place to workaround  (in TextRange.getClientRects vertical values).

In my simplified repro htm, document.caretPositionFromPoint is not completely broken (in that it returns presumably the value at x - scrollLeft, y - scrollTop), but in my scenario document.caretPositionFromPoint always returns an offset equal to 0. I couldn't figure out what about my full scenario brings out the always returning 0, so if you're in your code, please look around for other issues :).

I would mention that IE11, latest Chrome and latest Opera do not have this issue. I can reproduce on Win 8.1 FF 33.0.


Actual results:

My output is something like (absolute values are not important, they should just be the same):

testing with scrollTop: 7, scrollLeft: 15
=============================================
test1: [I can workaround this bug in code]
test1: Expected: [@(21,140), 41x19]
test1: Actual  : [@(28,155), 41x19]
test1: You could be a nice browser, but you have bugs in textRange.getClientRects() when using translate3d
=============================================
test2: [I cannot workaround this bug in code]
test2: Expected: ' dolor' @ 4
test2: Actual  : ' dolor' @ 2
test2: You could be a nice browser, but you have bugs in hit-testing when using translate3d


Expected results:

Here is for example the output in Opera (note again that absolute values are not important):

testing with scrollTop: 7, scrollLeft: 15
=============================================
test1: [I can workaround this bug in code]
test1: Expected: [@(20,131), 38x19]
test1: Actual  : [@(20,131), 38x19]
test1: You're a nice browser and textRange.getClientRects() is OK when using translate3d
=============================================
test2: [I cannot workaround this bug in code]
test2: Expected: ' dolor' @ 5
test2: Actual  : ' dolor' @ 5
test2: You're a nice browser and hit-testing is OK when using translate3d

Comment 1

[Loic]

I tested your testcase with FF36 (Nightly) and I think test #1 is fixed but test #2 is still broken.

Output
testing with scrollTop: 7, scrollLeft: 15
=============================================
test1: [I can workaround this bug in code]
test1: Expected: [@(20,140), 41x18]
test1: Actual  : [@(20,140), 41x18]
test1: You're a nice browser and textRange.getClientRects() is OK when using translate3d
=============================================
test2: [I cannot workaround this bug in code]
test2: Expected: ' dolor' @ 4
test2: Actual  : ' dolor' @ 2
test2: You could be a nice browser, but you have bugs in hit-testing when using translate3d

Comment 2

[Alex Dima]

Hi Loic,

Thanks for trying, I've just tried it on Nightly and can confirm that my (more complicated) use-case no longer suffers from the textRange.getClientRects() issue (test1), while it still suffers from the document.caretPositionFromPoint issue (test2).

I've also tried more scroll positions in my (more complicated) use-case and I want to correct the initial report that I only get back CaretPosition.offset equal to 0. Most of the time, the returned offset is 0, but sometimes it is not. I'm sorry I couldn't figure out why.

Thanks,
Alex

Comment 3

[Pascal Chevrel:pascalc]

I can confirm that test 2 is still not working as intended in Nightly 55, marking as NEW. 
It seems to be causing this bug in Microsoft Monaco Editor:
https://github.com/Microsoft/monaco-editor/issues/390