Bugzilla

I haven't been able to figure out what Chrome is doing with respect to the Android progress bar from the perfetto trace
(One is [here](https://drive.google.com/file/d/1qdaet3n6mUXLfrBxd8ScwY4ZoEHPzWlW/view) if anyone is interested).

But I've constructed a simpler site that demonstrates the behaviour of both browsers:
https://github.com/acreskeyMoz/acreskeyMoz.github.io/blob/main/slow/slow_requests.html

Here’s the observed behavior:

- DOMContentLoaded takes a bit over 5 seconds (due to a script loaded via slowfil.es).
- At DOMContentLoaded/ document interactive, Chrome immediately completes the progress bar.
- A new, slow-loading script (8 seconds) is dynamically added to the document.
- Both browsers reach onload at ~16 seconds.
- In Fenix, the progress bar completes only after onload.

This highlights a discrepancy in progress bar handling between Chrome and Fenix.

I think that for the mobile experience, completing the progress bar on the first paint after DomContentLoaded provides a better experience.

I haven't been able to figure out what Chrome is doing with respect to the Android progress bar from the perfetto trace
(One is [here](https://drive.google.com/file/d/1qdaet3n6mUXLfrBxd8ScwY4ZoEHPzWlW/view) if anyone is interested).

But I've constructed a simpler site that demonstrates the behaviour of both browsers:
https://acreskeymoz.github.io/slow/slow_requests.html

Here’s the observed behavior:

- DOMContentLoaded takes a bit over 5 seconds (due to a script loaded via slowfil.es).
- At DOMContentLoaded/ document interactive, Chrome immediately completes the progress bar.
- A new, slow-loading script (8 seconds) is dynamically added to the document.
- Both browsers reach onload at ~16 seconds.
- In Fenix, the progress bar completes only after onload.

This highlights a discrepancy in progress bar handling between Chrome and Fenix.

I think that for the mobile experience, completing the progress bar on the first paint after DomContentLoaded provides a better experience.