Open Bug 1576646 Opened 5 years ago Updated 2 years ago

The text cursor jumps back after hitting the space key a few times in Office 365

Categories

(Core :: DOM: Editor, defect, P3)

Desktop
All
defect

Tracking

()

Tracking Status
firefox68 --- affected
firefox69 --- affected
firefox70 --- affected
firefox76 --- affected
firefox77 --- affected
firefox78 --- affected

People

(Reporter: rdoghi, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: webcompat:needs-diagnosis, Whiteboard: [platform-rel-microsoft])

Attachments

(2 files)

Attached video 2019-08-26_16h54_18.mp4

[Affected versions]:
Nightly 70.0a1

[Affected platforms]:
Platforms: All

Steps :

  1. Launch the Firefox browser and reach Office 365.
  2. Open a new Word document.
  3. 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.

This only occurs on Office Online only. (I cannot reproduce this using simple contenteditable). This might be site's issue.

Priority: -- → P3
Whiteboard: [platform-rel-microsoft]
Flags: needinfo?(miket)

Ksenia, could you take a look please?

Flags: needinfo?(miket) → needinfo?(kberezina)
Attached file 1576646.html
Flags: needinfo?(kberezina)

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

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.

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.

Hmm, I don't see any redundant (outdated) Selection::Collapse() calls...

Severity: normal → S2

Now I cannot reproduce this now. Rares, could you still reproduce this? comment #6's code is still existed.

Severity: S2 → S3
Flags: needinfo?(rares.doghi)

Yes, this issue still occurs on my end in Release, Beta 77.0b7 and our latest Nightly build 78.0a1 (2020-05-18).

Flags: needinfo?(rares.doghi)

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.

Depends on: 1637855
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: