Closed Bug 1411453 Opened 7 years ago Closed 5 years ago

Nasty freeze after typing characters into Bugzilla Splinter comment

Categories

(Core :: Disability Access APIs, defect, P2)

Product:
Core
Component:
Disability Access APIs
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: Jamie, Assigned: Jamie)

References

Details

(Whiteboard: aes+) 

STR:
1. Star NVDA and Firefox.
2. Log into bugzilla.mozilla.org if you aren't already.
3. Open this URL: https://bugzilla.mozilla.org/page.cgi?attachment=8895528&id=splinter.html&bug=1363595
4. Select "All Files".
5. Double click a line number to add a comment.
6. In the comment field, type any single character.
7. Use the left and right arrow keys to review the text. Observe that response is just fine.
8. Wait about 15 seconds.
9. Try to use the left and right arrow keys to review the text.
Expected: Characters should be read responsively.
Actual: Browser is frozen for over 10 seconds.
10. When the browser recovers, repeat steps 6 through 9, with the same results.
11. Scream in pure frustration at the futility of doing Mozilla code review with Firefox at present.
I dug into this. The reasons for it are unfortunately very simple.

1. A few seconds after you type into a Splinter comment, a little notice appears saying that a draft is being saved (id saveDraftNotice).
2. In the accessibility tree, this notice is a direct child of a node with id bugzilla-body. That node contains the majority of the page.
3. When the notice appears, a text inserted event is fired on bugzilla-body indicating that the node got inserted.
4. That causes NVDA to re-render that entire node. Since that node contains the majority of the page and this is quite a big patch and thus contains a lot of nodes, that takes a long time (~10 seconds).
5. Shortly after the draft notice appears, it then disappears.
6. That causes a text removed event to get fired on bugzilla-body indicating that the notice was removed.
7. So NVDA re-renders bugzilla-body again, taking ~10 seconds.

This was never an issue in single process because despite the size of the page, the render happens much faster. You can feel a slight hiccup, but that's about it.

So, I guess this is basically the same root cause as the World War I case: it's just a big page and requires lots of calls. However, this is a lot worse because it happens while typing. Unfortunately, this technique of adding transient info/pop-ups to the end of a node containing the bulk of the page (even <body> itself) is pretty common on the web, so we're only going to see more and more complaints like this.
Blocks: 1365655
Whiteboard: [aes?] → aes+

This should be a lot better now that NVDA's buffer avoids re-rendering nodes that haven't changed in an updated subtree. See https://github.com/nvaccess/nvda/pull/8678. Closing.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.