Open Bug 972238 Opened 9 years ago Updated 6 months ago

Contenteditable elements are completely repainted whenever the text changes


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

Gonk (Firefox OS)




(Reporter: mchang, Unassigned)



(Keywords: perf, Whiteboard: [c=effect p=4 s= u=])


(2 files)

Attached video 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:
blocking-b2g: --- → 1.3T?
This is one for the SMS team
Component: Gaia::Keyboard → Gaia::SMS
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.
Depends on: 949457
Priority: -- → P1
Whiteboard: [c=handeye p= s= u=] → [c=effect p= s= u=]
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?
Flags: needinfo?(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.
Flags: needinfo?(mchang)
triage: lets work on this on trunk. thanks
blocking-b2g: 1.3T? → ---
Priority: P1 → P2
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.
Assignee: nobody → dhuseby
Whiteboard: [c=effect p= s= u=] → [c=effect p=4 s= u=]
Assignee: huseby → nobody
Flags: needinfo?(felash)
Attached file simple contenteditable
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.
Flags: needinfo?(felash)
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 ?)
Component: Gaia::SMS → Editor
Product: Firefox OS → Core
Summary: The Gaia Keyboard paints the whole input field when typing → Contenteditable elements are completely repainted whenever the text changes
<textarea> also experiences the same issue.
Component: Editor → Layout: Form Controls
Moving to p3 because no activity for at least 1 year(s).
See for more information
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.