WebCore:
authorsullivan <sullivan@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 1 Mar 2005 00:07:16 +0000 (00:07 +0000)
committersullivan <sullivan@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 1 Mar 2005 00:07:16 +0000 (00:07 +0000)
        Reviewed by Ken.

        - WebCore part of fix for <rdar://problem/4023490> REGRESSION (125-185): Tabbing through links
        on frameset page gets stuck at end (tivofaq.com)

        * kwq/WebCoreBridge.h:
        add nextValidKeyViewOutsideWebFrameViews (code is in WebKit)

WebKit:

        Reviewed by Ken.

        - WebKit part of fix for <rdar://problem/4023490> REGRESSION (125-185): Tabbing through links
        on frameset page gets stuck at end (tivofaq.com)

        This tab-to-links stuff has been in shaky condition ever since AppKit futzed with
        tabbing behavior in Tiger to add support for including the toolbar in the key loop.
        I made some changes months ago to compensate for that, but some cases, such as this
        one, still weren't fixed.

        * WebCoreSupport.subproj/WebBridge.m:
        (-[WebBridge _nextKeyViewOutsideWebFrameViewsWithValidityCheck:]):
        new bottleneck method, extracted from nextKeyViewOutsideWebFrameViews; handles
        nextKeyView or nextValidKeyView depending on parameter.
        (-[WebBridge nextKeyViewOutsideWebFrameViews]):
        now calls extracted method
        (-[WebBridge nextValidKeyViewOutsideWebFrameViews]):
        new method, calls new bottleneck method

        * WebView.subproj/WebHTMLView.m:
        (-[WebHTMLView nextValidKeyView]):
        when we're stuck at the end of a nextKeyView chain inside a nexted frame, use
        nextValidKeyViewOutsideWebFrameViews. Make sure we don't end up looking inside
        the web frame views while doing this.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@8721 268f45cc-cd09-0410-ab3c-d52691b4dbfc

WebCore/ChangeLog-2005-08-23
WebCore/kwq/WebCoreBridge.h
WebKit/ChangeLog
WebKit/WebCoreSupport.subproj/WebBridge.m
WebKit/WebView.subproj/WebHTMLView.m

index c4cb04afa5b139975ffa342e99a342ecafeb353c..f9bfa163a53d636193551f93292e620399e9430d 100644 (file)
@@ -1,3 +1,13 @@
+2005-02-28  John Sullivan  <sullivan@apple.com>
+
+        Reviewed by Ken.
+        
+        - WebCore part of fix for <rdar://problem/4023490> REGRESSION (125-185): Tabbing through links 
+        on frameset page gets stuck at end (tivofaq.com)
+
+        * kwq/WebCoreBridge.h:
+        add nextValidKeyViewOutsideWebFrameViews (code is in WebKit)
+
 2005-02-28  Ken Kocienda  <kocienda@apple.com>
 
         Reviewed by John
index 08ac31e9dcfb51629fb3e96dc52520ba4eed9e3d..73ac37e88090d8b6fc7505afdff9a426e661c4f0 100644 (file)
@@ -503,6 +503,7 @@ typedef enum {
 - (void)unfocusWindow;
 
 - (NSView *)nextKeyViewOutsideWebFrameViews;
+- (NSView *)nextValidKeyViewOutsideWebFrameViews;
 - (NSView *)previousKeyViewOutsideWebFrameViews;
 
 - (BOOL)defersLoading;
index 819e84ed8b184252df704a27c4113b2709b829c6..2dc4488da96ebb6cf7fddfe7ede2b2ab892eae58 100644 (file)
@@ -1,3 +1,30 @@
+2005-02-28  John Sullivan  <sullivan@apple.com>
+
+        Reviewed by Ken.
+        
+        - WebKit part of fix for <rdar://problem/4023490> REGRESSION (125-185): Tabbing through links 
+        on frameset page gets stuck at end (tivofaq.com)
+        
+        This tab-to-links stuff has been in shaky condition ever since AppKit futzed with
+        tabbing behavior in Tiger to add support for including the toolbar in the key loop.
+        I made some changes months ago to compensate for that, but some cases, such as this
+        one, still weren't fixed.
+
+        * WebCoreSupport.subproj/WebBridge.m:
+        (-[WebBridge _nextKeyViewOutsideWebFrameViewsWithValidityCheck:]):
+        new bottleneck method, extracted from nextKeyViewOutsideWebFrameViews; handles
+        nextKeyView or nextValidKeyView depending on parameter.
+        (-[WebBridge nextKeyViewOutsideWebFrameViews]):
+        now calls extracted method
+        (-[WebBridge nextValidKeyViewOutsideWebFrameViews]):
+        new method, calls new bottleneck method
+        
+        * WebView.subproj/WebHTMLView.m:
+        (-[WebHTMLView nextValidKeyView]):
+        when we're stuck at the end of a nextKeyView chain inside a nexted frame, use
+        nextValidKeyViewOutsideWebFrameViews. Make sure we don't end up looking inside
+        the web frame views while doing this.
+
 2005-02-25  Darin Adler  <darin@apple.com>
 
         Reviewed by John.
index 143adbe88d157d793dfe7050ea8328acbc353d1e..63eee5cc70cc727b64ce0d2ca96f3026382dec71 100644 (file)
@@ -721,7 +721,7 @@ NSString *WebPluginContainerKey =   @"WebPluginContainer";
     return _inNextKeyViewOutsideWebFrameViews;
 }
 
-- (NSView *)nextKeyViewOutsideWebFrameViews
+- (NSView *)_nextKeyViewOutsideWebFrameViewsWithValidityCheck:(BOOL)mustBeValid
 {
     if (_inNextKeyViewOutsideWebFrameViews) {
         // We should never get here, but unrepro bug 3997185 says we sometimes do.
@@ -737,11 +737,22 @@ NSString *WebPluginContainerKey =   @"WebPluginContainer";
     // the next key view of the last view in its key view loop.
     // Doing so gives us the correct answer as calculated by AppKit, 
     // and makes HTML views behave like other views.
-    NSView *nextKeyView = [[webView _findLastViewInKeyViewLoop] nextKeyView];
+    NSView *lastViewInLoop = [webView _findLastViewInKeyViewLoop];
+    NSView *nextKeyView = mustBeValid ? [lastViewInLoop nextValidKeyView] : [lastViewInLoop nextKeyView];
     _inNextKeyViewOutsideWebFrameViews = NO;
     return nextKeyView;
 }
 
+- (NSView *)nextKeyViewOutsideWebFrameViews
+{
+    return [self _nextKeyViewOutsideWebFrameViewsWithValidityCheck:NO];
+}
+
+- (NSView *)nextValidKeyViewOutsideWebFrameViews
+{
+    return [self _nextKeyViewOutsideWebFrameViewsWithValidityCheck:YES];
+}
+
 - (NSView *)previousKeyViewOutsideWebFrameViews
 {
     WebView *webView = [_frame webView];
index a7efe60968910f90eb498da7c766ce0b2ff5b5dd..62a156afedcd432deccb61c907ace89e72972823 100644 (file)
@@ -2855,12 +2855,36 @@ static WebHTMLView *lastHitView = nil;
 - (NSView *)nextValidKeyView
 {
     NSView *view = nil;
-    if (![self isHiddenOrHasHiddenAncestor]) {
+    BOOL lookInsideWebFrameViews = YES;
+    if ([self isHiddenOrHasHiddenAncestor]) {
+        lookInsideWebFrameViews = NO;
+    } else if ([self _frame] == [[self _webView] mainFrame]) {
+        // Check for case where first responder is last frame in a frameset, and we are
+        // the top-level documentView.
+        NSResponder *firstResponder = [[self window] firstResponder];
+        if ((firstResponder != self) && [firstResponder isKindOfClass:[WebHTMLView class]] && ([(NSView *)firstResponder nextKeyView] == nil)) {
+            lookInsideWebFrameViews = NO;
+        }
+    }
+    
+    if (lookInsideWebFrameViews) {
         view = [[self _bridge] nextKeyViewInsideWebFrameViews];
     }
+    
     if (view == nil) {
         view = [super nextValidKeyView];
+        // If there's no next view wired up, we must be in the last subframe.
+        // There's no direct link to the next valid key view; get it from the bridge.
+        // Note that view == self here when nextKeyView returns nil, due to AppKit oddness.
+        // We'll check for both nil and self in case the AppKit oddness goes away.
+        // WebFrameView has this same kind of logic for the previousValidKeyView case.
+        if (view == nil || view == self) {
+            ASSERT([self _frame] != [[self _webView] mainFrame]);
+            ASSERT(lookInsideWebFrameViews);
+            view = [[self _bridge] nextValidKeyViewOutsideWebFrameViews];
+        }
     }
+        
     return view;
 }