nsBrowserStatusFilter::OnStateChange delivers asymmetric numbers of STATE_START & STATE_STOP

RESOLVED FIXED in Firefox 59

Status

()

enhancement
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: freesamael, Assigned: freesamael)

Tracking

(Depends on 1 bug)

unspecified
mozilla59
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox59 fixed)

Details

Attachments

(1 attachment)

I noticed this problem when working on bug 1402689. It seems nsBrowserStatusFilter::OnStateChange tends to deliver more STATE_STOP than STATE_START (but sometimes reversely, I found a case in bug 463210 comment 5), and that's likely an existing problem for many years.

Now that we applied nsBrowserStatusFilter on both parent and child processes, so on parent side mFinishedRequests often exceeds mTotalRequests [1], and make the filter be broken frequently.

I don't see a specific bug it causes at this moment, but if consumers of the filter care about STATE_REQUEST we should fix it.

[1] http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/toolkit/components/statusfilter/nsBrowserStatusFilter.cpp#159,169,203
It seems browser.js & tabbrowser only care about STATE_IS_NETWORK, and we don't seem to use the fake progress generated by the statusfilter either (the value is incorrect with current implementation).
https://searchfox.org/mozilla-central/rev/550148ab69b2879bfb82ffa698720ede1fa626f2/toolkit/components/statusfilter/nsBrowserStatusFilter.cpp#164,174-175

Maybe we can simply filter out all state changes except `(STATE_IS_NETWORK & STATE_START) || (STATE_IS_NETWORK & STATE_STOP)`?
Comment hidden (mozreview-request)
Hi Mike,

It may look a bit too aggressive, but given that we've already filtered out most non-network STATE_IS_REQUEST and don't have correct number for the fake onProgressChange, I think removing the mFinishedRequests / mTotalRequests counters and only delivering STATE_IS_NETWORK reflect our use case now.

Since you're familiar with both gecko and frontend, I'd like to hear your feedback on this change.
Assignee: nobody → sawang

Comment 5

2 years ago
mozreview-review
Comment on attachment 8929369 [details]
Bug 1414745 - Filter out everything except STATE_IS_NETWORK in nsBrowserStatusFilter::OnStateChange.

https://reviewboard.mozilla.org/r/200690/#review206358

Thanks! Code seems great - just a few notes. See below.

::: commit-message-40df5:25
(Diff revision 1)
> +Firefox no longer shows the ratio of progressChange on the UI (and the number
> +is incorrect anyway with current nsBrowserStatusFilter), and Fennec's progress
> +bar is based on some predefined constants [1] which doesn't rely on
> +progressChange either, so it not necessary to keep calculating a progress
> +number with request counters.
> +
> +In addition, it seems tabbrowser & browser.js mostly only care about
> +STATE_IS_NETWORK, and Fennec has already filtered out everything else [2], it
> +should be safe to only pass STATE_IS_NETWORK to the listener, and we get the
> +benefit of reducing unused IPC messages.

If you wouldn't mind, could you please send a message to dev-platform about this change? Or, alternatively, maybe find a way of communicating the change to the TB and SM communities?

I ask, because I see a non-zero amount of usage of @mozilla.org/appshell/component/browser-status-filter;1 in comm-central, and I'm not certain what assumptions they make about its behaviour.

::: toolkit/components/statusfilter/nsBrowserStatusFilter.cpp:153
(Diff revision 1)
>  {
>      if (!mListener)
>          return NS_OK;
>  
>      if (aStateFlags & STATE_START) {
> -        if (aStateFlags & STATE_IS_NETWORK) {
> +        // Reset members on begining of document loading, but we don't want

Typo: "begining" -> "beginning"

::: toolkit/components/statusfilter/nsBrowserStatusFilter.cpp
(Diff revision 1)
>  void
>  nsBrowserStatusFilter::ResetMembers()
>  {
> -    mTotalRequests = 0;
> -    mFinishedRequests = 0;
> -    mUseRealProgressFlag = false;

Seems we're explicitly not resetting `mIsLoadingDocument` back to `false` here, likely because `ResetMembers()` is only called in one place, and that one place now sets `mIsLoadingDocument` to `true` immediately after calling it.

Would you mind adding a comment in ResetMembers about how we're explicitly not resetting mIsLoadingDocument to false?
Attachment #8929369 - Flags: review?(mconley) → review+
Comment hidden (mozreview-request)
Sent a mail to dev-platform. I'll wait for a day or 2 before landing in case someone found the change is inappropriate.

Comment 8

2 years ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/6dd2a65b4c3e
Filter out everything except STATE_IS_NETWORK in nsBrowserStatusFilter::OnStateChange. r=mconley
Keywords: checkin-needed

Comment 9

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/6dd2a65b4c3e
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59

Updated

a year ago
Depends on: 1421183
You need to log in before you can comment on or make changes to this bug.