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

This is one for the SMS team

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.

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

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?

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.

triage: lets work on this on trunk. thanks

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

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

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

picking this up to go with my other keyboard work.

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.

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 ?)

<textarea> also experiences the same issue.

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