Using a Galaxy S6 I saw a 7s delay between the end of the page visually painting and the completion of the animation for the progress bar. see bug 1454474 comment 2 for some initial findings.

Progress bar progress is currently set to 100 % when our onStateChange() listener says that loading has stopped [1][2]. [1] https://dxr.mozilla.org/mozilla-central/rev/6276ec7ebbf33e3484997b189f20fc1511534187/mobile/android/chrome/content/browser.js#4416 [2] https://dxr.mozilla.org/mozilla-central/rev/6276ec7ebbf33e3484997b189f20fc1511534187/mobile/android/base/java/org/mozilla/gecko/Tabs.java#635

For comparison, Chrome shows a progress bar for about 2 seconds when loading cnn.com on my Moto G5. Firefox shows a progress bar for 10+ seconds even though the visible page content appears to be all loaded and displayed.

When tracking protection is turned off this is even more common. There are often scripts running in the background holding the progress bar from going to 100% even though the pages loads visually completed. Can we change the progress bar to only take into account main content being loaded?

Eugen has done some work on this previously. There may be some knobs we can turn. I don't think, though, that we really know what "main content" is in all cases.

I think this is at least a P2 since it blocks perf "apples to apples" test work. Eugen do we need anything from gecko here or can we fix more directly?

Note: this is an old pre-ProgressTracker (bug 1437988) report, but it may still apply to some individual sites. We already have bug 1454477 for the centralized discussion on progress bar differences between other engines and GeckoView. To make this issue actionable, we need to pick an individual (major) site to address a specific issue since the page load progress characteristics heavily vary between sites.