-
ggaren authored
Reviewed by Sam Weinig. Tests for <rdar://problem/5334483> REGRESSION: JavaScript-induced loads not added to back/forward list * fast/history/location-assign-adds-history-item-expected.txt: Added. * fast/history/location-assign-adds-history-item.html: Added. * fast/history/location-href-set-adds-history-item-expected.txt: Added. * fast/history/location-href-set-adds-history-item.html: Added. * fast/history/location-replace-adds-history-item-expected.txt: Added. * fast/history/location-replace-adds-history-item.html: Added. * fast/history/location-set-adds-history-item-expected.txt: Added. * fast/history/location-set-adds-history-item.html: Added. * fast/history/window-open-adds-history-item-expected.txt: Added. * fast/history/window-open-adds-history-item.html: Added. * fast/history/window-open-adds-history-item2-expected.txt: Added. * fast/history/window-open-adds-history-item2.html: Added. * http/tests/navigation/redirect-load-no-form-restoration-expected.txt: Updated results. Adding a history entry here is correct behavior. WebCore: Reviewed by Sam Weinig. Fixed <rdar://problem/5334483> REGRESSION: JavaScript-induced window.open loads not added to back/forward list I did an audit of our history rules in loading and tried to establish some sane uniformity. The uniform rule is: - HTTP redirects and HTTP redirects simulated by <meta http-equiv> add a history item if and only if the redirect takes > 1 second. - Other navigations, including JavaScript navigations, always add a history item, except for location.replace navigations. In the future, we'll want to refine the second case to be more like the first. I've filed <rdar://problem/5339292> about that. * bindings/js/JSHTMLDocumentCustom.cpp: (WebCore::JSHTMLDocument::setLocation): Don't pass 'true' for userGesture unconditionally. userGesture is used to determine popup blocking, not history item creation. * bindings/js/kjs_window.cpp: Pass 'false' for lockHistory in all loads except location.replace, which intends to lock history. * loader/FrameLoader.cpp: Distinguish between lockHistory and userGesture. The former determines whether a new history item gets created. The latter determines whether JavaScript can open popup windows. Start passing these variables in functions that used to swallow or conflate them. (WebCore::FrameLoader::requestFrame): Pass 'true' for lockHistory here because that's usually correct when setting the 'src' attribute of a child frame, and we want to avoid regressing <rdar://problem/4921797>. (WebCore::FrameLoader::load): Use the lockHistory variable to determine whether to start a history-creating load. Using userGesture for this purpose is wrong, as explained above. * loader/FrameLoader.h: Renamed one variant of scheduleRedirection to scheduleHTTPRedirection because the behavior there of measuring elapsed time is specific to the HTTP redirection case. * page/ContextMenuController.cpp: (WebCore::ContextMenuController::contextMenuItemSelected): lockHistory can always be false here because this navigation is never the result of a redirection. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24353 268f45cc-cd09-0410-ab3c-d52691b4dbfc
bcd93e64