251513 - content of tabs not focused to keyboard scrolling when switching tabs

Status: RESOLVED FIXED

(Firefox :: General, defect, P1)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The content of tabs doesn't get the focus for keyboard scrolling reliably when
switching between tabs.  It seems to get into a state where it works for one tab
but not the other.  This seems like it might be a regression from bug 175893,
which landed today.  I can't reproduce in last night's Firefox nightly
(2004-07-14-08-trunk), but I can reproduce reliably in my cvs Firefox build from
6pm today, and I'm reasonably sure the behavior is new because I was trying to
scroll and it wasn't working when I was expecting it to.  (All Linux.)

Steps to reproduce:
 1. Open a new firefox window
 2. press control-L (focus URL bar)
 3. type "www.mozilla.org", and press enter
 4. hit the down arrow a few times to show scrolling works
 5. press control-T (open new tab, which focuses URL bar)
 6. type "www.mozilla.org", and press enter
 7. hit the down arrow a few times to show scrolling works
 8. Press Ctrl-PgUp (switch tab)
 9. hit the down arrow a few times

Actual results (after 9): no scrolling
Expected results (after 9): scrolling

Note: When opening more than two tabs, the most recently opened tab seems to be
OK, but previously open tabs all seem to be in the bad state.  Clicking in the
body of the page of one of the tabs puts that tab into the good (focusing)
state, and all the others into the bad (not focusing) state.

I could not reproduce in Seamonkey nightlies, 2004-07-14-07-trunk or
2004-07-14-19-trunk

Comment 1

[Aaron Leventhal]

I think the focusable tab fix isn't working as well on Firefox. The tab might be
getting focus when it's not supposed to. Another issue is that it didn't mix
well with the fix for -moz-outline on the outside of the frame (bug 151375).

Do you notice a focus ring at all on the tab when scrolling isn't working?

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I can confirm that the bug is present in the 2004-07-15-08-trunk FF nightly, so
it is a regression, and not something in my tree.

I haven't noticed any focus outlines on tabs themselves, under any conditions. 
(Maybe that's related to native theme rendering?)

Comment 3

[Aaron Leventhal]

David, I'm sure I caused the regression.

Can you tell me though, when you're in that state do left/right arrows change
what tab is selected?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, left/right don't do anything.

Comment 5

[Aaron Leventhal]

This is WFM. I can't reproduce this on Windows XP. 

The problem I did see is unrelated afaict. Ctrl+[shift]+Tab and Ctrl+PgUp/PgDn
don't work when you're in the location bar.

Comment 6

[Aaron Leventhal]

Attachment: Update firefox tabbrowser code to have Seamonkey fixes

Not sure if this fixes your bug, but it might, and this needs to get in.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, that fixes it.

Comment 8

[Martin Cracauer]

The bug is actually worse.

Not only does the currently visible tab not get the keyboard focus when
switching between tabs with the keyboard.

The wrong tab actually has the keyboard focus. You cannot tell by using the
arrow keys because the other tab isn't visible.

But you can test by using typehead and by the display on the bottom the the
browser. Imagine you have a first tab which has a link named "foobar" and you
have a different tab which does not have a link named "foobar", and the latter
is the visible tab. If this bug occurs and you start typing "foobar" you see
that Firefox happily find the link in the first (invisible tab). If you hit
return then it follows that link in the invisible tab.

I am building with the appended patch as we speak, stand by.

Comment 9

[Martin Cracauer]

The diff as posted above

http://bugzilla.mozilla.org/attachment.cgi?id=153337&action=view

fixes the problem for me. On first glance I observe no ill side effects. I will
use the patched browser for the day for further testing.

I am using tonight's CVS version on Linux/X11, BTW, in a firefox build with SVG,
no debugging/logging.

Commit of diff as posted recommended.

Comment 10

[Martin Cracauer]

OK, update. First of all, today's CVS doesn't work right for me, some cookie
breakage makes my online banking and my verizon wireless account website forget
that I was logged in.

I now run -D 20040717 with the patch which almost works.

I thill have some harder to reproduce losses of input focus after tab switching.

I had several cases where going back in tabs with shift-control tab to the first
tab would leave the first tab without the focus. But right now it works :-/ Must
be some combination of a third tab having been closed right before that.

Still recommend to commit patch as proposed. Will try to narrow down that
remaining issue.

Comment 11

[Mike Connor [:mconnor]]

Comment on attachment 153337 [details] [diff] [review]
Update firefox tabbrowser code to have Seamonkey fixes

r=[e-mail]

Comment 12

[Aaron Leventhal]

Checking in autocomplete.xml;
/cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v  <--  autocomplete.xml
new revision: 1.27; previous revision: 1.26
done
Checking in tabbrowser.xml;
/cvsroot/mozilla/toolkit/content/widgets/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.41; previous revision: 1.40
done

Comment 13

[Martin Cracauer]

It's broken again.

Today's build on Linux, when opening a link (apparently any, used slashdot) with
the middle mouse button and then using control-tab to switch to it will not have
the keyboard focus on the new (displayed) tab.

Comment 14

[Ian Neal]

Relanding relevant parts of patch following aviary branch landing

Comment 15

[Asaf Romano (gone)]

Comment on attachment 153337 [details] [diff] [review]
Update firefox tabbrowser code to have Seamonkey fixes


>         <![CDATA[
>           this.mCurrentBrowser = this.mPanelContainer.firstChild;
>           this.mCurrentTab = this.mTabContainer.firstChild;
>+          this.mTabBox.handleCtrlTab = !/Mac/.test(navigator.platform);
>         ]]>
>       </constructor>
> 

Aaron, what was the reason to exculde ctrl+tab/shift-tab on mac? (bug 264787)

Comment 16

[Aaron Leventhal]

> Aaron, what was the reason to exculde ctrl+tab/shift-tab on mac? (bug 264787)
I don't remember. Ask Neil Rashbrook, Mike Pinkerton or someone more
knowledgeable about the Mac. Or, go back to the original bug and find the
discussion.

Comment 17

[[e-mail]]

(In reply to comment #15)
>Aaron, what was the reason to exculde ctrl+tab/shift-tab on mac?
See bug 169589.

Comment 18

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381