It is not clear to me how this pr stops Chrome from crashing.

It is not clear to me how this pr stops Chrome from crashing.

Chrome does not crash. NVDA freezes. My bad, I rephrased the title.
I fully agree this quick and dirty fix is not ideal, but it does solve at least our faulty real life scenario.
By dramatically reducing the size of the string to process, it avoids IAccessibleHandler.splitIA2Attribs taking to long to process when the incriminated element gets focus.
Any better solution would be very welcome.

As this would impact any Assistive Technology, I really think this should be reported to and fixed in both Firefox and Google Chrome itself. They should not be exposing data:image URIs via IAccessible2 attributes.

As this would impact any Assistive Technology, I really think this should be reported to and fixed in both Firefox and Google Chrome itself. They should not be exposing data:image URIs via IAccessible2 attributes.

I agree, despite someone might nitpick with a convoluted use case.
I guess @jcsteh is the one of us with the better grasp of Firefox bug reports.
Do you know of someone involved in chromium?

Nevertheless, we should IMHO pragmatically implement this workaround (or another) in NVDA in the meantime.
For the record, we already did it in the same context as of #4793 back in 2015.

I don't think it will be too hard to do this also in the Gecko vbufBackend for this pr.
At line 536 of nvdaHelper/vbufBackends/gecko_ia2/gecko_ia2.cpp
You'll want to create a c++ regex object matching on base64 similar to what you did in Python, and then use regex_replace, before passing the string to ia2AttribsToMap.
Note that we probably shouldn't do it directly inside ia2AttribsToMap as that function is also used for IAccessible2 text attribute parsing.

As this would impact any Assistive Technology, I really think this should be reported to and fixed in both Firefox and Google Chrome itself. They should not be exposing data:image URIs via IAccessible2 attributes.

That's fair. What would you prefer we exposed? The obvious solution is not to expose the src attribute at all in this case. On the other hand, the presence of the src attribute might be meaningful (i.e. this image came from a URL).

Note that we probably shouldn't do it directly inside ia2AttribsToMap as that function is also used for IAccessible2 text attribute parsing.

@michaelDCurran, is there any chance that on the Python side IAccessibleHandler.splitIA2Attribs also receive text of any kind?
If so, I'm afraid the regex should be replaced by something like
r"(([^\\](\\\\)*);src:data\\:[^\\;]+\\;base64)\\,[A-Za-z0-9+/=]+"
and the replacement parameter by r"\1<truncated>".

As for the vbuf impact:
I used a regex on the Python side because it was processed in C and thus had a lesser performance cost than the current custom parsing of the string.
In C++, however, I believe it is the opposite: matching a regex is probably more time consuming than the current custom parsing of the string.
I think that appending a test of the value for the "src" attribute at the end of IA2AttribsToMap would be just fine, unless of course if you know of another use of the "src" attribute.
What do you think?

@michaelDCurran
I prepared two alternatives for the vbuf impact:

• accessolutions/nvda@bdeed0fddatargetsIA2AttribsToMap`
• accessolutions/nvda@2b72bcd5f7targetsGeckoVBufBackend_t::fillVBuf`

I feel the first one (IA2AttribsToMap) is more logical and future-proof as live regions handling also uses this, but I've included the GeckoVBufBackend_t::fillVBuf as you foresaw it would have your preference.
They are otherwise quite identical and I've successfully tested both of them with Firefox and Chrome.
Please let me know if either suits your expectations and I'll file a PR accordingly.