Closed Bug 1275525 Opened 5 years ago Closed 3 years ago

NVDA build result pages take forever to load in Firefox

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox49 --- affected

People

(Reporter: MarcoZ, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: perf)

Report from Jamie over IRC:

1. Run NVDA and Firefox.
2. Visit https://ci.appveyor.com/project/NVAccess/nvda/build/next-13333%2C74785a37
3. Wait for ages, and I mean huge amounts of time, for the page to load.

4. Do the same in Chrome.
5. Page loads much much faster.
Some more precise measurements:
1. Firefox 47 Beta 8 takes about 45 seconds from pressing Enter on the link to NVDA becoming responsive again. There is chatter in-between, but keys are not processed.
2. Firefox 49 Nightly 2016-05-24 takes about 35 seconds for the same.
3. Current Chrome 51 beta takes about 15 seconds.
Marco, what is the status of the bug?
Flags: needinfo?(mzehe)
This bug is fixed. Loading the page from comment #0 takes under a second for me now.
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(mzehe)
Resolution: --- → WORKSFORME
I think this fix is actually largely due to some change in AppVeyor, rather than Firefox. I mean, we've improved performance a lot, but not *that* much. :) AppVeyor now now seems to load the main UI, then output the entire existing console log in one shot (it says "Rendering console" while it renders). Previously, it seemed to progressively add the log output to the DOM, resulting in a lot of tiny a11y events and resultant buffer updates. Regardless, this is a good thing.

Having said that, it still seems to take several seconds for me. The initial page loads that quickly, but the build output takes a bit longer to appear. Marco, were you seeing the bottom line saying "Build success"?

I do suspect we're going to hit some problems for builds which are actually in progress, as those will still update the DOM line by line, which is in turn going to cause lots of buffer updates. The more output, the longer each buffer update will take. Even so, let's cross that bridge if and when we need to... and the only *real* solution to that is bufferless anyway.
You need to log in before you can comment on or make changes to this bug.