Open Bug 1125713 Opened 5 years ago Updated 6 months ago

Browser API: Add event for page download progress

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set

Tracking

()

ASSIGNED
mozilla38
tracking-b2g backlog
Tracking Status
firefox38 --- fixed

People

(Reporter: paul, Assigned: paul)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, perf)

Attachments

(3 files, 1 obsolete file)

Today, the browser API only tells if a frame is loading or not. It makes it impossible to build a progress bar.

Having something like `onProgressChange(CurTotalProgress,MaxTotalProgress)` from nsIWebProgressListener would probably work.
Blocks: graphene
There's semi-related discussion in https://github.com/whatwg/fetch/issues/19, too.
Attached patch progress.patchSplinter Review
This patch adds loadprogresschanged event.
Attachment #8564753 - Flags: review?(fabrice)
Attachment #8564753 - Flags: review?(fabrice) → review+
Attached file dump
Results are not very satisfying. Pretty often, the max value is lower than the current value. Sometimes the max value is 10 times smaller than the current value.

Not sure what we can do about it.
https://hg.mozilla.org/mozilla-central/rev/c7c68c4389d6
Assignee: nobody → amarchesini
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
This makes chorme process main thread quite busy when launch an app on FxOS and delay sync IPCs from child. Do we need this event all the time?
We actually need only the first download progress event to indicate download has started.
I have tried to gather visuallyLoaded event of launching SMS on my Flame [1], with and without the path here:

                   AVG          MED          MIN          MAX          STD
With the patch     1642.380661  1620.661354  1528.798750  1822.307707  99.2765441
Without the patch  1355.260708  1363.919010  1234.469479  1515.148748  85.04832144

It's ~300ms regression. Can we back this out and revise the patch if we need only the first download progress event?

Version:
  Gaia: c4835abe080b20aaec6e736ad6f4a74c444c244c
  Gecko: https://hg.mozilla.org/mozilla-central/rev/fd8e079d6335

Device:
  Flame 1024MB v18D

Test steps:
  1. Launch SMS with empty load
  2. Kill the app
  3. Wait for 5s, go to 1
  4. Repeat 1-3 for 10 times
Flags: needinfo?(amarchesini)
Ting-Yu, please backout.
I couldn't find a backout flag, how should I request that?
Flags: needinfo?(amarchesini)
(In reply to Ting-Yu Chou [:ting] from comment #10)
> I couldn't find a backout flag, how should I request that?

There's no flag, just do it yourself.
(In reply to Fabrice Desré [:fabrice] from comment #11)
> (In reply to Ting-Yu Chou [:ting] from comment #10)
> > I couldn't find a backout flag, how should I request that?
> 
> There's no flag, just do it yourself.

I have only level 1 access...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Keywords: perf
(In reply to Paul Rouget [:paul] from comment #7)
> We actually need only the first download progress event to indicate download
> has started.

Well... can you use mozbrowserloadstart for that?
Flags: needinfo?(paul)
(In reply to Andrea Marchesini (:baku) from comment #14)
> (In reply to Paul Rouget [:paul] from comment #7)
> > We actually need only the first download progress event to indicate download
> > has started.
> 
> Well... can you use mozbrowserloadstart for that?

We want to do something similar to what Firefox does: indicate when load starts (reaching the server, grey throbber), indicate when the server responded (starting downloading, blue throbber).

So mozbrowserloadstart is not enough.
Flags: needinfo?(paul)
Attached patch v2 (obsolete) — Splinter Review
I've updated the patch to only send an event (mozbrowserconnected) once the server has been reached. The goal is to be able to differentiate the phase when the browser is connecting to the server and the phase when the browser is downloading and loading the page.
Attached patch v2Splinter Review
Assignee: amarchesini → paul
Attachment #8644239 - Attachment is obsolete: true
Status: REOPENED → ASSIGNED
This still sends multiple "connected" event. We should send only one.
For Servo, we are planning to fire a "mozbrowserconnected" event once the server has been reached.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.