Better distinguish didFinishLoad and didStopLoading
Currently, they mean roughly the same thing. didFinishLoad
fires when a navigation successfully completes and no other
navigations are in progress. didStopLoading does the same
thing, but fires whether or not the navigation was successful.
This changes didFinishLoad to mean "a navigation successfully
completed", while didStopLoading still means "there are now
no navigations in progress in this frame". For each
didStartProvisionalLoad, there will be exactly one of:
didFailProvisionalLoad, didFailLoad, didFinishLoad. Prior to
this change, there would be at most one, but it could be that
a load would complete without a matching notification.
This also reverses the order of didFinishLoad and
didStopLoading. didStartLoading and didStopLoading will now
bracket zero to many individual navigation notifications,
which may be interleaved.
This requires 4 changes to consumers of these notifications:
asserted the old finish/stop ordering, and did nothing
else. Remove it and its test harness logic.
2. web_navigation_api.cc assumed that didFinishLoad would not
be sent if a new provisional navigation began before the
finish notification. Change a DCHECK to an early exit.
3. password_autofill_agent.cc depends on stop firing before
finish for determining whether all loading is done. Give
it the ability to determine loading state for itself
4. chrome/android/ incorrectly listens to the browser process
equivalents of didStartProvisionaLoad and didFinishLoad to
determine whether loading is in progress and start/stop
the progress bar. Switch it to the equivalent of
didStartLoading and didStopLoading.
Review URL: https://codereview.chromium.org/1381003004
33 files changed