I wasn't able to find out much out about the purpose of the script from p11.techlab-cdn.com. It seems to be part of an Akamai product and my best guess is that it's hooking a bunch of stuff to try to detect malicious script running on the page. If anyone knows more, please share.

Chrome handles the Proxy case better but it's still 11x slower than if it wasn't there: bugzilla.mozilla.org/show_bug.cgi.... Safari's slower than Firefox.

If I block the techlab-cdn script the amount of time that the page blocks the main thread when I clear the search field goes down from 600ms to 350ms.

One of the reasons it takes so long is that these sites run a script from p11.techlab-cdn.com that overrides String.charCodeAt with a Proxy. They also seem to use github.com/emotion-js/e... which hashes CSS strings a lot. The Proxy slows down this hashing by 40x in Firefox.

I filed bugzilla.mozilla.org/show_bug.cgi... for that case

Is it correct that the `filter()` function stuff is only supported by Safari?

SVG filter performance should be better in a lot of cases as of bugzilla.mozilla.org/show_bug.cgi...

Do you have specific cases that are still slow?

bugzilla.mozilla.org/show_bug.cgi...

bugzilla.mozilla.org/show_bug.cgi...

The Outlook's parsing looks like:
```
o = e.headers.get('Content-Disposition') ||
'',
a = /filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/.exec(o);
return a &&
a[1] &&
(n = a[1].replace(/['"]/g, '')) &&
(n = decodeURIComponent(n)),
```

We ended up doing a Firefox release to deal with this: bugzilla.mozilla.org/show_bug.cgi...

Like 300 times per day of active use in the last 14 days for every instrumented event.

e.g. in my profile with 7 days of active use it does it 2072 times for every hover, click etc.

During this entire process Gmail gives no indication that anything is happening at all. This encouraged me to click the download button multiple times which initiated multiple downloads of the 500MB file causing my Gmail process in Firefox to balloon to roughly 80GB of memory. 🙁

After that, Gmail converts the combined byte string to an ArrayBuffer using charCodeAt which takes another 148ms. Finally the ArrayBuffer is converted to a Blob and '<a>' element is used to get the browser to download it.

Each chunk is passed to atob() which returns a string containing all the byte values. These strings are then added to an array that's join("")ed to produce a byte string 2x the size of the attachment. It takes Chrome one second to do this conversion of a 100MB file on M3 MacBook Pro

Gmail uses this regex:
/(([\r\n]{0,2}[A-Za-z0-9+\/]){4,4}){0,1024}([\r\n]{0,2}[A-Za-z0-9+\/][\r\n]{0,2}[AQgw]([\r\n]{0,2}=){2,2}|([\r\n]{0,2}[A-Za-z0-9+\/]){2,2}[\r\n]{0,2}[AEIMQUYcgkosw048][\r\n]{0,2}=|([\r\n]{0,2}[A-Za-z0-9+\/]){4,4})[\r\n]{0,2}/g
to turn the responseText into 4100 length chunks

Once the download has completed Gmail needs to convert the base64 string into binary that can Gmail can give to the browser as a download.

This response ends up in the responseText property of the XHR object. In Firefox, that means that the utf8 base64 response is converted to utf16 doubling its size. Combined with the base64 overhead, when downloading a 512MB file, you'll end up with a 1.3GB responseText property sitting in memory.

Because the arguments to memcpy are marked as being nonnull. See godbolt.org/z/o58W65hnT.

The nonnull attribute is then presumably propagated to the arguments of test and the if condition is removed.

bugzilla.mozilla.org/show_bug.cgi...