Hacker News Reader

Comment by cpeterso | Hacker News Reader

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.

View on HN

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

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

As I said, usually I don't wait for a full crash so there is a survival bias in those ids.

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.

Well, if I'd like to have something rewritten in rust, this would be my first choice. :)

Reply on news.ycombinator.com