The text cursor jumps back after hitting the space key a few times in Office 365
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
People
(Reporter: rdoghi, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: webcompat:needs-diagnosis, Whiteboard: [platform-rel-microsoft])
Attachments
(2 files)
[Affected versions]:
Nightly 70.0a1
[Affected platforms]:
Platforms: All
Steps :
- Launch the Firefox browser and reach Office 365.
- Open a new Word document.
- Type some text and Hit SPACE multiple times
Expected Results :
The text cursor should move accordingly without glitching.
Actual Results :
The mouse cursor glitches, sometimes jumps forward 2 spaces and then jumps back after hitting space.
This glitch is more visible if the user HOLDS the SPACE bar down.
Note: please note that in the attached video is not that visible since it has a poor framerate.
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
This only occurs on Office Online only. (I cannot reproduce this using simple contenteditable). This might be site's issue.
Updated•5 years ago
|
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Ksenia, could you take a look please?
Comment 3•4 years ago
|
||
Comment 4•4 years ago
|
||
This is not reproducible 100% of the time for me, most of the times it works ok.
On every input event there is a constant DOM modification via removeChild/appendChild, so this could be a performance issue.
I've attached a reduced test case. Similarly, most of the time it works ok, but sometimes the browser freezes up (not happening in Chrome).
Also a link to perf profile from the original website https://perfht.ml/34dt1y6
Comment 5•4 years ago
•
|
||
Thank you, :ksenia! According to the profile, most time spends on reflow caused by Element.getBoundingClientRect()
which is called by a input
event handler. https://perfht.ml/2Wp9b1V
Before dispatching input
event, of course there is a change of a text node at least. However, the reflow computes new layout really deeply. If it's caused by this performance, I don't understand what's going on. But I guess that the jumping is caused by setting Selection
by editor which is outdated. Unfortunately, I cannot reproduce this bug with ksenia's testcase even on slower debug build.
Comment 6•4 years ago
|
||
Oh, before dispatching input
event, editor calls ScrollIntoView()
and it flushes pending reflow which includes the change caused by typing text.
https://searchfox.org/mozilla-central/rev/61f224ec08ddc6f9a93ac45c8c3c5f7159be7c2a/editor/libeditor/EditorBase.cpp#983,1005,1032
So, it seems that the getBoundingClientRect()
is called after Office changed something.
Comment 7•4 years ago
|
||
Hmm, I don't see any redundant (outdated) Selection::Collapse()
calls...
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Now I cannot reproduce this now. Rares, could you still reproduce this? comment #6's code is still existed.
Reporter | ||
Comment 9•4 years ago
|
||
Yes, this issue still occurs on my end in Release, Beta 77.0b7 and our latest Nightly build 78.0a1 (2020-05-18).
Comment 10•4 years ago
|
||
Currently, I'm working on rewriting the code normalizing whitespaces. Once it'll be landed, our editor won't modify text nodes multiple times at inserting a whitespace. I hope, it fixes this or at least makes the symptom better.
Updated•4 years ago
|
Description
•