Probably related to the landing of bug 1270916 or related, but a regression in any case. There is a subjective feeling of performance degradation of text updates on the braille display when typing in multi-line text fields. I've seen this in Gmail (contentEditable), IRCCloud (TextArea) and while composing on my blog in the plain text editor (also a TextArea). Especially when deleting or replacing text, text updates are slower than they used to be before I got sick on November 9th. Only E10S mode affected. You probably will see this most likely when using NVDA with a braille display connected, since that makes heavier use of the text interfaces than speech alone.

(In reply to Marco Zehe (:MarcoZ) from comment #0) > Probably related to the landing of bug 1270916 or related, but a regression > in any case. Trevor would this be expected?

(In reply to Marco Zehe (:MarcoZ) from comment #0) > Probably related to the landing of bug 1270916 or related, but a regression > in any case. > > There is a subjective feeling of performance degradation of text updates on > the braille display when typing in multi-line text fields. I've seen this in > Gmail (contentEditable), IRCCloud (TextArea) and while composing on my blog > in the plain text editor (also a TextArea). Especially when deleting or > replacing text, text updates are slower than they used to be before I got > sick on November 9th. Only E10S mode affected. That would seem to contradict the theory it is bug 1270916, that should effect both roughly equally. > You probably will see this most likely when using NVDA with a braille > display connected, since that makes heavier use of the text interfaces than > speech alone. If this is related to use of text interface stuff that would also suggest it isn't related to events. (In reply to David Bolter [:davidb] from comment #1) > (In reply to Marco Zehe (:MarcoZ) from comment #0) > > Probably related to the landing of bug 1270916 or related, but a regression > > in any case. > > Trevor would this be expected? given above no, and it doesn't really make much sense, there shouldn't be that many events for this. However its hard to say what the problem is without reproducing and profiling.

Marco is there more you could do to help pinpoint the cause of this regression?

Jamie and I discussed this during the all-hands, and he's convinced that this has been present before bug 1270916 landed, which may very well be true. Jamie mentioned a particular case where Undo in Gmail's message composer takes forever, like two to three minutes, to complete in some cases. The thing is complicated by the fact that there are no exact steps, so bisecting may or may not give accurate results and may take hours or days to track. It may just be easier to try and profile some cases, like replying to a message thread, for example, pasting a chunk of text, then making an undo. Or a deletion of some bigger chunk of text may also produce the same, or undoing that. But then again, it doesn't always seem to happen. Jamie, did I summarize that situation well enough?

Looking at this bug more closely, I actually think we might be dealing with two different issues here. 1. Without e10s, I see an issue when composing large messages in Gmail where changes other than backspacing or deleting a character (such as undoing) are very slow. While this is occurring, the UI stops responding. I don't think I've seen multiple minutes, but I've certainly seen 10-30 seconds, maybe more. I imagine we'd see this with e10s as well, but I haven't had a situation which allowed me to reproduce it yet. 2. That said, without e10s, as I typed, text updated immediately. However, with e10s, I noticed that after I finish typing a few words of text, it seemed like the accessible text took a few seconds to update. What's odd about this is that the UI didn't become unresponsive or anything like that. I could even retrieve accessible text; it just wasn't up to date. It's like my typing was taking a long time to get to the content process, but the content process was still happily handling a11y queries. Again, I do *not* see this without e10s. Marco, I'm starting to think you're referring more to issue 2. For you, is Firefox still responsive even before text is updated? For example, does NVDA's read current line command respond (albeit with outdated text)?

(In reply to James Teh [:Jamie] from comment #5) > Marco, I'm starting to think you're referring more to issue 2. For you, is > Firefox still responsive even before text is updated? For example, does > NVDA's read current line command respond (albeit with outdated text)? You're right, I just re-tested this, and it is definitely both still responsive, just out of date, and slow to update with E10S on, but not with E10S off, when typing. And as you, I am also a fast typist. And, I only see this in Gmail, not in a textarea like this one, for example.

Marco - does this affect 52? Bolter - can yopu find a home for this?

(In reply to Randell Jesup [:jesup] from comment #7) > Marco - does this affect 52? Not so much, since we will disable E10S for accessibility clients on Windows in 52.

This might be closed once aklotz completes some more performance work.

Too late for a fix for 53, as we are in the last week of the 53 beta cycle.

Marco has anything changed here?

Yes, for the better. I no longer see these big delays. I am closing the bug WFM.