Closed Bug 696758 Opened 8 years ago Closed 8 years ago
Filter web progress messages sent to Java
Currently, we send all state and progress events to Java via messages. Desktop uses a browser status filter to filter these messages, letting the UI do less work. I tried to use the same browser status filter, but was failing to get a "network stop", used to signal the document is complete. After banging my head on this problem for a while, I just added some of the optimizations directly to our JS code: * If we have more than one "request" (item downloading on a web page) use the request completions as the basis of "progress", not the raw progress. * Only send progress messages if we have reasonable values and the progress is more than 3% greater than the last message. * Only send DOCUMENT state change messages. Skip NETWORK and REQUEST states that happen more often and are unused. I also removed sending windowID, since we don't use it. We use tabID now.
Attachment #569063 - Flags: review?(mbrubeck)
To make it easier to review
Assignee: nobody → mark.finkle
Quick example of results. Loading Bugzilla Main Page: Without filter # progress msgs: 14 # state msgs: 57 With filter # progress msgs: 7 # state msgs: 3 The results are more significant on pages like Planet Mozilla: Without filter # progress msgs: 256 # state msgs: 1594 With filter # progress msgs: 15 # state msgs: 3 You should note that the progress bar will never "jump back". It will only keep moving to the right. Without the filter you will see the progress bar occasionaly jump to the left as the maxtotal and curtotal values adjust from necko.
Attachment #569063 - Flags: review?(mbrubeck) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.