Changeset 13441 in webkit
- Timestamp:
- Mar 22, 2006 2:30:39 PM (18 years ago)
- Location:
- trunk
- Files:
-
- 4 added
- 5 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/WebCore/ChangeLog
r13440 r13441 1 2006-03-22 Tim Omernick <timo@apple.com> 2 3 Reviewed by Kevin Decker. 4 5 Part of <rdar://problem/4351664> REGRESSION (420+): extra URL in b/f list - navigating back to previous page fails at apple.com/retail/) 6 This also fixes <rdar://problem/4477821> REGRESSION (10.4.5-TOT): meta tag specifying refresh is being added to history. 7 8 * bridge/mac/FrameMac.h: 9 * bridge/mac/FrameMac.mm: 10 Removed redirectionTimerFired(). This was added as attempt to fix <http://bugzilla.opendarwin.org/show_bug.cgi?id=7058>. The 11 aim was to cause Safari and WebKit to update their loading status after a redirect. Unfortunately, the fix had a bad side 12 effect. Calling -reportClientRedirectCancelled: on a successful redirect causes WebKit to forget that the redirect was supposed 13 to lock history (i.e. reuse the current back/forward entry for the new page). The end result was that intermediate "quick" redirects 14 were creating back/forward entries when they should not have been. See 4351664. That fix was almost correct, in that we do need to 15 notify the frame load delegate when a redirect ends, either because it succeeded or because it was cancelled. However, this is the 16 wrong place to do it. WebCore's redirect notification logic did not need to change to fix 7058. The never-ending spinning indicators 17 problem was actually caused by a bug at the WebKit level. 18 19 * manual-tests/redirectHistory: Added. 20 * manual-tests/redirectHistory/redir-1.html: Added. 21 * manual-tests/redirectHistory/redir-2.html: Added. 22 * manual-tests/redirectHistory/redir-3.html: Added. 23 Manual test case. I couldn't figure out how to create a layout test for this, because it involves navigation through history and 24 it was unclear how/when to tell DumpRenderTree to dump its output. 25 1 26 2006-03-22 Eric Seidel <eseidel@apple.com> 2 27 -
trunk/WebCore/bridge/mac/FrameMac.h
r13440 r13441 310 310 virtual void startRedirectionTimer(); 311 311 virtual void stopRedirectionTimer(); 312 virtual void redirectionTimerFired(Timer<Frame>*);313 312 314 313 private: -
trunk/WebCore/bridge/mac/FrameMac.mm
r13440 r13441 836 836 if (wasActive && d->m_scheduledRedirection != historyNavigationScheduled) 837 837 [_bridge reportClientRedirectCancelled:d->m_cancelWithLoadInProgress]; 838 }839 840 void FrameMac::redirectionTimerFired(Timer<Frame>* timer)841 {842 // Note, despite its name, we must call "redirect cancelled" even when the843 // redirect has completed successfully. Although that may not have been our844 // original intent, Safari depends on this behavior at the time of this writing.845 // See Radar 4432562 and Bugzilla 7058.846 847 // Don't report history navigations, just actual redirection.848 if (d->m_scheduledRedirection != historyNavigationScheduled)849 [_bridge reportClientRedirectCancelled:d->m_cancelWithLoadInProgress];850 851 Frame::redirectionTimerFired(timer);852 838 } 853 839 -
trunk/WebKit/ChangeLog
r13431 r13441 1 2006-03-22 Tim Omernick <timo@apple.com> 2 3 Reviewed by Kevin Decker. 4 5 Better fix for <rdar://problem/4432562> REGRESSION (TOT): Safari's "stop loading" active, "view source" inactive after page load [7058] 6 7 * WebView/WebFrame.m: 8 (-[WebFrame _transitionToCommitted:]): 9 Cancel the client redirect when we commit the provisional load, if we were waiting for a redirect. 10 This is a better fix for 7058 (<rdar://problem/4432562>). The original fix for 7058 changed the timing of the redirect cancel 11 in such a way that WebKit was precluded from ever reusing back/forward list entries for redirects. Clearing the redirect state 12 here actually makes logical sense, as the redirect's target page is being committed at this point. 13 1 14 2006-03-21 Darin Adler <darin@apple.com> 2 15 -
trunk/WebKit/WebView/WebFrame.m
r13269 r13441 779 779 // see -_opened 780 780 } 781 782 // This dataSource was a client redirect (we checked above, remember?). Now that it is being 783 // committed, there can no longer be a pending redirect. Call -_clientRedirectCancelled: here 784 // so that the frame load delegate is notified that the redirect's status has changed. The 785 // frame load delegate may have saved some state about the redirect in its 786 // -webView:willPerformClientRedirectToURL:delay:fireDate:forFrame:. 787 [self _clientRedirectCancelled:NO]; 781 788 } 782 789 [self _makeDocumentView];
Note: See TracChangeset
for help on using the changeset viewer.