Bug 7058 - REGRESSION: Tab seems to be loading forever after redirect
Summary: REGRESSION: Tab seems to be loading forever after redirect
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Nobody
URL:
Keywords: InRadar, Regression
: 3552 7106 9269 (view as bug list)
Depends on:
Blocks: 9610 6309
  Show dependency treegraph
 
Reported: 2006-02-03 16:05 PST by Daniele Metilli
Modified: 2006-06-26 14:05 PDT (History)
7 users (show)

See Also:


Attachments
Patch committed to svn (4.48 KB, patch)
2006-02-06 22:13 PST, David Kilzer (:ddkilzer)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniele Metilli 2006-02-03 16:05:11 PST
Follow these steps:
- Open WebKit, latest nightly.
- WebKit will load the "thank you" page. Open another tab.
- Look at the tab bar: the first tab has always that spinning symbol.

Please note that:
- This happens with every site, not just the "thank you" page.
- It happens also with the fourth tab, not just the first.
Comment 1 John Sullivan 2006-02-03 18:19:19 PST
I suspect this is the same as radar bug 4432562. That bug has to do with redirects. Apparently WebKit isn't sending all the same webView: delegate callbacks to Safari, and Safari thinks there's still a pending reload forever.

This bug claims that it happens for every page though, which would be different. Radar bug 4432562 only happens on windows/tabs in which a redirect has occurred. (Once the redirect occurs though, loading additional pages in the same window/tab still shows the problem.)
Comment 2 Daniele Metilli 2006-02-04 06:21:57 PST
I am the original reporter, and I can confirm that it is a duplicate of 4432562. I hadn't fully understood the problem. I should have said:

- It happens with every tab when loading Webkit.app/Contents/Resources/start.html or any other redirect.
- It happens with every page loaded in the same tab after the redirect.
Comment 3 John Sullivan 2006-02-04 08:01:27 PST
It would be great to figure out when this broke, by checking older nightly builds.
Comment 4 David Kilzer (:ddkilzer) 2006-02-04 08:45:04 PST
I did a binary search of the nightly builds and found the following (we lucked out!):

Not broken: WebKit-SVN-r12514.dmg
Broken:     WebKit-SVN-r12515.dmg

Revision r12515 was Darin's Timer update (no Bugzilla bug to reference), so adding him to the CC list and confirming bug.

Note that I can always get this bug to occur when I click the "Check Mail" button on Yahoo! Mail after I've logged in.  (I'm not sure if a redirect needs to occur within the window before that, but I always get to Yahoo! Mail after typing in http://mail.yahoo.com/ in the address bar.)

Also note that no amount of hitting Cmd-. or clicking the "X" button will stop the spinner after this occurs.
Comment 5 John Sullivan 2006-02-04 09:14:25 PST
Great work tracking this down! I presume this means the checkin in WebCore with the following comment in ChangeLog:

        - use Timer for everything, kill timer features of QObject, QTimer, QTimerEvent

Safari gets into a state where it knows an instant client redirect is pending, but then this state never gets cleared. So it thinks an instant client redirect is pending forever, hence the UI looks like we're still loading as we wait. So the change that broke it is either something about sending a 0-interval client redirect webView: delegate call back where one was not sent before, or something about not cancelling such a redirect.
Comment 6 David Kilzer (:ddkilzer) 2006-02-04 10:25:42 PST
(In reply to comment #5)
>         - use Timer for everything, kill timer features of QObject, QTimer, QTimerEvent

That's the one!

> Safari gets into a state where it knows an instant client redirect is pending,
> but then this state never gets cleared. So it thinks an instant client redirect
> is pending forever, hence the UI looks like we're still loading as we wait. So
> the change that broke it is either something about sending a 0-interval client
> redirect webView: delegate call back where one was not sent before, or
> something about not cancelling such a redirect.

I added some debugging printf statements to the code and found that the bug only occurs when MacFrame::startRedirectionTimer() is called.  It, in turn, calls Frame::startRedirectionTimer() which calls d->m_redirectionTimer.startOneShot(d->m_delayRedirect) with d->m_delayRedirect equal to 0.0.

I can't figure out why MacFrame::startRedirectionTimer() is only called on some redirects but not others, though.
Comment 7 David Kilzer (:ddkilzer) 2006-02-04 11:41:27 PST
Interestingly enough, Attachment 6173 [details] ("Test case") from Bug 6309 triggers this bug every time.
Comment 8 David Kilzer (:ddkilzer) 2006-02-04 22:16:21 PST
(In reply to comment #7)
> Interestingly enough, Attachment 6173 [details] [edit] ("Test case") from Bug 6309 triggers this
> bug every time.

Ignore.  This is probably a different cause.
Comment 9 John Sullivan 2006-02-06 14:12:29 PST
*** Bug 7106 has been marked as a duplicate of this bug. ***
Comment 10 David Kilzer (:ddkilzer) 2006-02-06 22:13:08 PST
Created attachment 6315 [details]
Patch committed to svn
Comment 11 David Kilzer (:ddkilzer) 2006-02-07 21:21:25 PST
*** Bug 3552 has been marked as a duplicate of this bug. ***
Comment 12 David Kilzer (:ddkilzer) 2006-02-07 21:21:30 PST
*** Bug 6309 has been marked as a duplicate of this bug. ***
Comment 13 David Kilzer (:ddkilzer) 2006-06-02 20:46:53 PDT
*** Bug 9269 has been marked as a duplicate of this bug. ***