972238 - Contenteditable elements are completely repainted whenever the text changes

Status: NEW

(Core :: Layout: Form Controls, defect, P3)

Description

[Mason Chang [Inactive] [:mchang]]

Attachment: Video Showing Painting

Potential optimization. At the moment, when the new keys are typed, we are painting the whole input field + the send button as shown in the video. On a tarako device, while typing, we use up to ~45% cpu usage. Here's a profile:

https://people.mozilla.org/~bgirard/cleopatra/#report=b51d33763d1396b42f7a2830e0fe2bc302dae36a

Comment 1

[Jan Jongboom [:janjongboom] (inactive)]

This is one for the SMS team

Comment 2

[Julien Wajsberg [:julienw]]

We're using a contenteditable div, so that could be the reason?

Also, we know we have some bad patterns (I mean: reflows) due to history and the UX complexity, and we hope that bug 949457 can help with this.

Comment 3

[Julien Wajsberg [:julienw]]

To be clearer, I think any work on the composer should start by fixing bug 949457.

Comment 4

[Joe Cheng [:jcheng] (please needinfo)]

Hi mason, do we know if this is going to improve the keyboard performance much more than what we have done last week in Taipei?

Comment 5

[Mason Chang [Inactive] [:mchang]]

It might only help in the SMS app. And as Julien stated in comment 3, it will probably involve a lot of work to fix this bug as the composer needs a lot of work. I think it's too risky to block on as the keyboard is acceptable on Tarako as of last week.

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

triage: lets work on this on trunk. thanks

Comment 7

[Mason Chang [Inactive] [:mchang]]

Just retested with 949457 landed, and we still repaint the whole input field while typing just letters. This is still an issue.

Comment 8

[Julien Wajsberg [:julienw]]

Is it happening with other apps? Is it because we use contenteditable? What happens on Desktop?

Comment 9

[Mason Chang [Inactive] [:mchang]]

Tested on desktop and browser app. Paint flashing occurs on the input field for both doh. Good question though.

Comment 10

[Dave Huseby [:huseby]]

picking this up to go with my other keyboard work.

Comment 11

[Julien Wajsberg [:julienw]]

Attachment: simple contenteditable

STR:
0. Turn on "nglayout.debug.paint_flashing" in about:config
1. Open the file in Firefox.
2. Put the cursor at the end of the contenteditable zone.
3. Type things without typing "enter" (you can enter "spaces" though)

=> notice how the whole contenteditable is always rerendered even that the previous words didn't change at all and so there should be no reason to rerender it. Actually we should not need to rerender anything that is more than 1 line above what is currently edited.

Comment 12

[Julien Wajsberg [:julienw]]

I understand _why_ it's doing this but this could be optimized for contenteditable elements. This was an issue in the SMS app in Firefox OS because users rarely used new lines, and the available cpu power was low.

Moving to Core::Editor (maybe it should be in Layout or Paint though, to better manage invalidation ?)

Comment 13

[William Chen [:wchen]]

<textarea> also experiences the same issue.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information