Skip to content
  • ggaren's avatar
    LayoutTests: · bcd93e64
    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