It looks like the p11.techlab-cdn.com stuff is also currently breaking viewing bills on rogers.com in Firefox
It looks like the p11.techlab-cdn.com stuff is also currently breaking viewing bills on rogers.com in Firefox
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.
Clearing the search field on Loblaws online shopping sites like nofrills.ca blocks the main thread with JS for 600ms on my M3 MacBook Pro. This is a pretty noticeable jank and is presumably a lot worse if you're not using a computer as fast as an MBP
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?
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)),
```
Outlook sends attachments to Firefox with `content-disposition: attachment; filename*=UTF-8''Backup.pdf`. Browsers with a non-Firefox UA get `content-disposition: attachment; filename="Backup.pdf"`. Outlook then fails to properly the parse this harder and starts a download of `UTF-8Backup.pdf`
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.
TikTok does `new Date((new Date).getTime() - 864e5 * e).toLocaleDateString("en-US")` a lot
"Perl's efficiency likely contributes to its rising usage, as teams leverage it for automation tasks where speed is a priority." - CircleCI's "Programming language trends 2025"
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.
When Gmail receives an email containing a Google Drive link it displays as an attachment. What happens when you click on the attachment to download it?
Gmail does an XHR to a URL like clients6.google.com/drive/.
This request responds with a base64 encoded version of the Google Drive file.
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.
`s.type` is checked but `e.newsInfoDetail.date` is used.
Spidermonkey's sort algorithm ends up with a comparison where e.type = "rss" and s.type == "news" and then throws an exception. Chrome and Safari avoid this.
Webcompat diagnosis of the day:
toei-anim.co.jp has the following bug:
```
l = s.sort( (e, s) => {
let r = "news" == e.type ? Date.parse(e.newsInfoDetail.date) : e.published
, l = "news" == s.type ? Date.parse(e.newsInfoDetail.date) : s.published;
return l - r
}
```
Diagnosing bugzilla.mozilla.org/show_bug.cgi... has been difficult