The nsBrowserStatusFilter flushes pending status and progress updates when an
OnStateChange event for a STATE_STOP state is triggered. This may run its
OnProgressChange and OnStatusChange listeners, which may in turn run arbitrary
JavaScript or even remove the web progress listener from the filter. When this
happens, we will continue to call the OnStateChange event handler on a listener
that is now a nullptr, causing a crash.
We now explicitly check that we still have a web progress listener before
continuing and have renamed the ProcessTimeout function to a more descriptive
name (CallDelayedProgressListeners) that indicates what it actually does.
Differential Revision: https://phabricator.services.mozilla.com/D28123
--HG--
extra : moz-landing-system : lando
nsBrowserStatusFilter is updated to not filter out STATE_IS_REDIRECTED_DOCUMENT.
The test here is adding a way to have a "login form" do a post to a server script, which then does a 303 redirect. This mimics what some services, including LinkedIn do during this stage.
Differential Revision: https://phabricator.services.mozilla.com/D26969
--HG--
extra : moz-landing-system : lando
nsBrowserStatusFilter is updated to not filter out STATE_IS_REDIRECTED_DOCUMENT.
The test here is adding a way to have a "login form" do a post to a server script, which then does a 303 redirect. This mimics what some services, including LinkedIn do during this stage.
Differential Revision: https://phabricator.services.mozilla.com/D26969
--HG--
extra : moz-landing-system : lando
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
The mFinishedRequests / mTotalRequests counters in nsBrowserStatusFilter has
been known buggy for around a decade. With e10s we double filtered in both
parent and child processes which makes it worse.
There are a few problems with the counters / filter:
1. The ResetMembers() were invoked on each network request starts, which means
a iframe document loading followed by the root document loading would also
reset the members incorrectly.
2. The filter for non-network request was incorrect. The basic idea seems to be
that if `mFinishedRequests == mTotalRequests` and `!isLoadingDocument`, it
should be the STOP request right after document loading finishes, and that
STOP should be delivered so listener would get symmetric numbers of START /
STOP of STATE_IS_REQUEST. However some requests such as imgRequest can start
after document loading finishes, in this case the START would be filtered
out (since mFinishedRequests != mTotalRequests), but STOP would be delivered
to the listener. It's the reason that nsBrowserStatusFilter tend to deliver
much more STATE_STOP than STATE_START.
3. When applying the filter on both parent & child side, the above issues often
make the mFinishedRequests / mFinishedRequests be unmatched on parent side,
eseentially filtered out most non-network requests and make the
progressChange based on the counters useless.
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.
[1] https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/mobile/android/base/java/org/mozilla/gecko/Tab.java#111-115
[2] https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/mobile/android/chrome/content/browser.js#4356-4357
MozReview-Commit-ID: 5tUP5SRwDoP
--HG--
extra : rebase_source : 9be66bf79f08fac176d9c35eb7a2b2d78484d8d3
If the busy attribute was not set by (STATE_IS_NETWORK & STATE_START), and the
loading results in an error, it's possible that the busy flag never gets
cleared. In this case we can clear it when receiving location change with
LOCATION_CHANGE_ERROR_PAGE.
When digging into this bug I found nsBrowserStatusFilter::mFinishedRequests
and mTotalRequests counters can be incorrect on parent side since we've applied
the filter on both child and parent processes. This hasn't seem to be causing
a bug yet but it's potentially problematic, so adding a warning in
nsBrowserStatusFilter.
MozReview-Commit-ID: H25R60ozGtM
--HG--
extra : rebase_source : 3b6f9b6c974e65d540fdae495017dd3b7fffdbb6
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements or calling a function for side effects within an expression. Check NS_SUCCEEDED() to use HasMoreElement() in an expression and confirm that it actually returned a legitimate out parameter.
toolkit/components/startup/nsAppStartup.cpp:436:58 [-Wcomma] possible misuse of comma operator here
toolkit/components/statusfilter/nsBrowserStatusFilter.cpp:165:66 [-Wcomma] possible misuse of comma operator here
toolkit/xre/CreateAppData.cpp:60:51 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: HuZRoOjQTGj
--HG--
extra : rebase_source : c159e26d619b960163fda11069e722010a21d2f8
extra : source : c405a2ab8ec4b6b96373fe3812a6d30bb0641d6f
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973