1793408 - Firefox freezes on some websites with Cache the World enabled

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Emil Ghitta, QA [:emilghitta]]

Attachment: digi24.gif

Found in

• Firefox 107.0a1

Preconditions

• Enable accessibility.cache.enabled pref
• Launch NVDA

Details
We have encountered multiple websites which are causing Firefox to freeze and become unusable while having the accessibility.cache.enabled pref and NVDA enabled.

We are drafting a list of websites (with additional details) in which we spotted this freeze: https://docs.google.com/spreadsheets/d/112-Qrob80pKrte7D8uHZlWAA3i8PgfrkCngdBuD4ZPU/edit?usp=sharing

Expected result

• No freeze is encountered.

Actual result

• Firefox freezes and becomes unusable.

Comment 1

[Emil Ghitta, QA [:emilghitta]]

Updating the link. Something has changed at website level and the issue is now reproducible on https://www.digi24.ro/stiri/actualitate/politica. I'll try to see if we can isolate the faulty element in a reduced tc if possible.

Comment 2

[Emil Ghitta, QA [:emilghitta]]

I've morphed this bug into a more general one that tracks all cases/websites which are causing Firefox to freeze. We'll file separate bugs if it turns out that some websites have different causes.

Removing the regression labels for this bug.

Comment 3

[Daniel Bodea [:danibodea]]

Blocking the main meta due to Jamie's specifications.

Comment 4

[James Teh [:Jamie]]

I can't reproduce this freeze on any of the sites listed. :( Some questions:

1. Does the browser UI freeze or just the tab in question? For example, can you close the tab either with the mouse or control+w when this occurs?
2. If the browser UI does freeze, do you eventually see the Windows "not responding" indicator?
3. If the browser UI can still be used, are you able to take a profile using the Firefox Profiler? I may be able to use a profile to figure out what's going on.
4. If the browser UI does freeze, we'll need to create a dump to figure out what's going wrong. Probably the simplest way to do this is to use crashfirefox64.exe. You'll need to get the process id of the main Firefox process and pass that to the command; e.g. crashfirefox64.exe 12345, where 12345 is the process id of the main Firefox process. One way to get the process id of the main process is to use about:processes.

Comment 5

[James Teh [:Jamie]]

I neglected to mention: once you intentionally crash Firefox, let it submit a crash report and then provide the crash report id.

Comment 6

[Emil Ghitta, QA [:emilghitta]]

(In reply to James Teh [:Jamie] from comment #4)

I can't reproduce this freeze on any of the sites listed. :( Some questions:

Weird...We are able to reproduce the freeze on those listed websites. We are able to reproduce when both accessibility.cache.enabled is set to true and NVDA is running (version: 2022.3)

1. Does the browser UI freeze or just the tab in question? For example, can you close the tab either with the mouse or control+w when this occurs?

The browser UI freezes. I'm unable to close the tab via mouse or control+w

2. If the browser UI does freeze, do you eventually see the Windows "not responding" indicator?

Yes.

3. If the browser UI can still be used, are you able to take a profile using the Firefox Profiler? I may be able to use a profile to figure out what's going on.

Unfortunately, the browser UI freezes and Firefox is unusable.

4. If the browser UI does freeze, we'll need to create a dump to figure out what's going wrong. Probably the simplest way to do this is to use crashfirefox64.exe. You'll need to get the process id of the main Firefox process and pass that to the command; e.g. crashfirefox64.exe 12345, where 12345 is the process id of the main Firefox process. One way to get the process id of the main process is to use about:processes.

I was able to generate the crash report via the crashfirefox64.exe tool: https://crash-stats.mozilla.org/report/index/4416b110-2c6e-4d14-bb3e-8f0fc0221005#tab-details
I've also generated a dump file via procdump ( I've sent it to you on slack)

Comment 7

[James Teh [:Jamie]]

Thanks very much. The dump helped a lot.

The critical missing piece here is that this can only be reproduced when moving the mouse over the document. Since I'm a blind screen reader user, I don't use the mouse and I was thus unable to reproduce this.

I'm working on a fix.

Comment 8

[James Teh [:Jamie]]

Attachment: Bug 1793408: Consistently treat OuterDocAccessibles as a single character in TextLeafPoint.

1. When constructing a TextLeafPoint and searching for a leaf, do not descend inside an OuterDoc (iframe/browser).
   Otherwise, we end up inside another document.
   Other TextLeafPoint code avoids crossing document boundaries, so the constructor must do this too.
2. When searching for a leaf, include an OuterDoc, but don't walk inside it.
   Previously, we skipped OuterDocs altogether.
   This meant that if you started on an OuterDoc, walking backward and then forward by character would never return you to your origin.
   Also, clients walking the document text shouldn't just skip iframes altogether, so exposing them as a single character makes more sense.

This fixes infinite loops in OffsetAtPoint when querying a container with an iframe at the end.

Comment 9

[James Teh [:Jamie]]

Emil, would you mind re-testing with the Win64 opt build from this try run? (It isn't finished yet, but it should be done in an hour or so.) I want to make sure there isn't another freeze on some of the pages that is different to the one I've fixed, especially since it's difficult for me to reproduce. Thanks.

Comment 10

[Emil Ghitta, QA [:emilghitta]]

Hey Jamie.

I can't reproduce the freeze on any of those websites on my Windows 10 machine using this try build but Rares encountered the same hang after performing some actions on the page (clicking on several links, and navigating through the header items). So he had to stress test the pages a little bit for that freeze to occur on his end. I'm sending the dump generated on that machine via slack, hopefully, it points out the cause.

We also tested on a Windows 7 machine. We couldn't reproduce the freeze but we encountered a random crash. Since we don't have any clear steps we are not sure if this is caused by the patch applied to this try build, if it surfaced out now since the freeze is no longer reproducible or if this is something different: https://crash-stats.mozilla.org/report/index/ee91831e-2d96-4ba8-9b7c-190d30221006

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/447cc0286695
Consistently treat OuterDocAccessibles as a single character in TextLeafPoint. r=morgan

Comment 12

[James Teh [:Jamie]]

Thanks for the dump. Both the dump and the crash seem to have some sort of stack corruption, but the corruption is identical in both of them, which makes me think that these are the same issue and also that this is not a one-off problem. Unfortunately, I wasn't able to glean anything useful from either of them; the stack just doesn't go far enough for me to get any useful data. I'm hoping we might have more luck figuring this out once this patch lands in Nightly.

Comment 13

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/447cc0286695

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:Jamie, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox106 to wontfix.

For more information, please visit auto_nag documentation.

Comment 15

[Daniel Bodea [:danibodea]]

I have verified this fix using the following steps:

1. Have an affected browser version opened with accessibility engine force enabled and CTW activated.
2. Have the unaffected (latest Nightly) open with accessibility engine force enabled and CTW activated.
3. Go through the list of websites where the issue was observed and load them one by one on both browsers.
4. Attempt to reproduce the issue on the affected build, then restart the browser.
5. Attempt to reproduce the issue on the unaffected build using the same exact steps it reproduced with, in a few tries.
6. Then I performed a 30 min exploratory on the fixed build to attempt to reproduce the freeze again.

Having reproduced a freeze on 11 out of 13 of the websites on the affected build and absolutely no freeze on the unaffected build on both Windows 10 and Windows 7, I consider this issue fixed. While these issues are intermittent and also not that easy to reproduce, we can't be sure it's completely fixed until we perform a full test run, but the behavior has definitely improved dramatically.

Comment 16

[James Teh [:Jamie]]

Thanks to you and your team for all of your work in testing this. Please file separate bugs for any freezes you subsequently discover. Thank you.