Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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. :)




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: