4 ms·

Do you have any crash report IDs in your Firefox's about:crashes page? I can check whether a Bugzilla bug report has already been filed for those crashes.

• gostsamo 5y ago
  I think that the issue is known, but hard to track. It shows with NVDA and heavy web apps like Twitter and Messenger if they are running for some time. I'm posting here some of the crash ids, but it is likely that they are not representative. When the browser starts to clock up, it locks the screen reader as well and I'm not waiting for the crash, but kill the process with extreme prejudice. I'd be glad to help in any other way. bp-cb27fd07-ad27-49bf-b6c2-9dbbb0211005 bp-96eef135-da51-45a8-a792-d28810211005 bp-184a8916-227c-42c4-8308-6e3c00211005 bp-ba6748d3-2d93-4d84-992e-8cf960211005 bp-8bdfb00f-0e30-4cd3-826c-efb910211005 Here is the Bugzilla ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1572915 https://bugzilla.mozilla.org/show_bug.cgi?id=1572915
  • gsvelto 5y ago
    Unfortunately those crashes do not appear to be related to low memory scenarios. They seem to be genuine bugs in the screen reader. I think the right bug tracking them is this one: https://bugzilla.mozilla.org/show_bug.cgi?id=1691928 https://bugzilla.mozilla.org/show_bug.cgi?id=1691928
    • gostsamo 5y ago
      As I said, usually I don't wait for a full crash so there is a survival bias in those ids.
      • gcp 5y ago
        The original ticket seems to indicate this is a leak in a Windows accessibility service and so far there was no luck in finding a way to avoid it. That sucks.
        • gostsamo 5y ago
          Well, if I'd like to have something rewritten in rust, this would be my first choice. :)