| Summary: | Duplicate load progress start notifications | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brett Wilson (Google) <brettw> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | cmarcelo |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
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).