140140 - keyboard shortcuts don't work in new tabs until click in web page

Status: RESOLVED DUPLICATE of bug 138237

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Carey Tilden]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020421
Debian/1.rc1-1
BuildID:    20020421 Debian/1.rc1-1

After opening links from web pages into new tabs (with middle click, for
example), various keyboard shortcuts do not work. Upon clicking somewhere within
the web page in the newly opened tab, all keyboard shortcuts begin to work as
normal. I have tested this with CTRL+-, CTRL++, CTRL+F, CTRL+W and UP/DN
scrolling... so I assume it's a general problem.

Reproducible: Always
Steps to Reproduce:
1. Go to any web page that has a link.
2. Open link in a new tab (with middle click, for example).
3. Try to scroll with UP/DN keys, or use CTRL+F to search.

Actual Results:  Keyboard shortcuts do nothing.

Expected Results:  Keyboard shortcuts perform desired task.

This behaviour does not occur when opening a new tab with CTRL+T and typing in a
url. It also does not occur when opening a link into a new window.

Comment 1

[Boris Zbarsky [:bzbarsky]]

worksforme, linux trunk build 2002-04-24-07.  Opening a link in a new tab
followed by Ctrl-W closes the new tab.  Opening in new tab, click back to
original tab, click to new tab, Ctrl-w also closes the new tab.

Comment 2

[Carey Tilden]

I downloaded a "stock" mozilla 1.0RC1 (as opposed to a debian package), and the
same behavior is observed. I also downloaded and tried the latest nightly build
from ftp.mozilla.org, and yet again the behavior is the same.

I tested the following builds, and each one does the same thing:
 - 2002041711
 - 20020421 Debian/1.rc1-1
 - 2002042610

Comment 3

[Andrew Schultz]

I'm seeing this... might be related to windowmanager.  I'm using blackbox.

This seems to have started between build 2002032808 and 2002032921
backing out checkin for bug 133382 "fixes" this bug, although I have no idea how
it could possibly be related.

cc'ing Christian for any insight.

marking NEW

Comment 4

[Carey Tilden]

Using sawfish window manager here.

Comment 5

[Andrew Schultz]

now I *really* don't understand.  If I
1) comment out the patch for bug 133382  ==> keyboard works
2) add the following line to nsBrowserStatusHandler.js ==> keyboard broken

        location = "";
    }

    // Disable menu entries for images, enable otherwise
    var confusion=content.document;  //  **** add this line ****
//    if (content.document &&
this.mimeTypeIsTextBased(content.document.contentType))
//      this.isImage.removeAttribute('disabled');
//    else
//      this.isImage.setAttribute('disabled', 'true');

just accessing content.document blocks keyboard access.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

arg
this content.document stuff has already caused bug 134664, now fixed...

I have no idea why my patch could have caused this bug.

Comment 7

[Dan Keshet]

*** Bug 148413 has been marked as a duplicate of this bug. ***

Comment 8

[Andrew Schultz]

linux trunk build 20020608 still has the bug, but build 20020609 worksforme (yeah)

Carey, is this working for you?

Comment 9

[Carey Tilden]

Interesting. Tried 2002060921-trunk build, and it seemed to be working. Noticed
keyboard shortcuts stopped working after first time opening a link. Seems
keyboard (tested Up/Dn scrolling and CTRL+W) works only for first time opening
page... even after closing browser, any pages previously opened in new tabs
block keyboard.

Comment 10

[Andrew Schultz]

are you saying you do:
1. open link(www.mozilla.org) in new tab
2. close new tab (keyboard works)
3. open same link in new tab
4. keyboard doesn't work
?

those steps work fine (do not exhibit this bug) for me.

Comment 11

[Carey Tilden]

Ok, it isn't doing it with every link. If I go to the Mozilla Start page, and
click to open open Patch Maker in a new link, keyboard is blocked after first
page access.

URLs:
  http://www.mozilla.org/start/
  http://www.gerv.net/software/patch-maker/build-mode.html

This seems to be the only link on the mozilla start page that causes the
behavior. Could it have something to do with the fact that it's an offsite link?

Comment 12

[Andrew Schultz]

It appears to be somehow related to network or cache.  Loading any local page
always exhibits this bug (even the first time).   and clearing the cache fixes
loading pages off the network (temporarily).  I still don't know why loading
most Mozilla pages works...

Comment 13

[Andrew Schultz]

this is actually bug 138237 (fix there is what helped here)

*** This bug has been marked as a duplicate of 138237 ***