[Webkit-unassigned] [Bug 21068] New: Duplicate load progress start notifications

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=21068

           Summary: Duplicate load progress start notifications
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: brettw at chromium.org


On some layout tests, such as LayoutTests/fast/forms/empty-get.html,
FrameLoaderClient::postProgressStartedNotification() will get called twice in a
row without a corresponding "Finished" notification.

Clients use this message to start and stop throbbers and such, so duplicate
start messages probably don't matter, but it's a waste of time to restart them,
and it's potentially confusing.

When I load the layout test, the first call to progress start is the actual
page starting to load (from FrameLoader::load()). Then that kicks off a form
submit (I think) before that load has finished. 

The second one starts by calling FrameLoader::submitFormAgain. This makes its
way to ProgressTracker::progressStarted() with m_numProgressTrackedFrames = 1
(the currently loading main frame). The test:
  if (m_numProgressTrackedFrames == 0 || m_originatingProgressFrame == frame) {
passes because the frames match, and reset() is called which changes the
tracked frames back to 0. Then it dispatches another started notification.

I think having reset() call
frame->loader()->client()->postProgressFinishedNotification() is probably the
right solution, since it could be called from any number of places, and if the
progress tracker is reset, the client app should be notified of it.

An alternative solution would be to just not fire the started notification from
ProgressTracker::progressStarted if the tracked frames at the start of the
function was nonzero (effectively continuing the same load from the client's
perspective).


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.