300622 - bad focus and behavior after clicking tab

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Felix Miata]

This is on current Linux & OS/2 trunks (e.g. 2005071103) and started somewhere
around the time bug 299454 was fixed.

To reproduce:
1-Open CZ to several channels
2-Click some channel tab other than the one for the currently displayed channel
3-Strike any alphanumeric key(s)

Actual behavior:
1-Focus is on nick button
2-CPU % for suite exectuable is upwards of 90% for many seconds, possibly more
than a minute, depending on system speed and other activity
3-No typed character(s) appear in input box

Expected behavior:
1-Focus is in input box
2-CPU % is normal
3-Typed character(s) appear in input box

Workaround: try to remember to hit <tab> key after each click of a channel tab,
before striking any other key

Comment 1

[Felix Miata]

The amount of time CPU is pegged is dependant upon how many keystrokes are
entered before realizing that focus remains on the button. This is a serious
time waster, as nothing is possible in any app while pegged.

Comment 2

[James Ross]

It appears to be aaronleventhal's doing...

http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/global/resources/content/bindings/tabbox.xml&rev=1.31

That revision of the tabs XBL is what seems to have caused this. Setting
'setfocus' to 'false' on the tabs element does stop it, however, the old code
also checked the attribute and used advanceFocusIntoSubtree (like the new code),
so the behaviour has changed (CZ 0.9.68.6 in Moz 1.7 is fine).

Felix, until I get a better idea of what's actually causing the bug with the
tabs (I'll probably be moving this bug out of CZ soon), you can do the following
eval to fix the problem for the current session:

/eval document.getElementById("views-tbar-inner").setAttribute("setfocus", "false")

Comment 3

[James Ross]

Attachment: Hack around <tabs> bug

Comment 4

[James Ross]

Checked in --> HACKEDAROUND (aka FIXED).

Comment 5

[Felix Miata]

Hack works, but should verification be deferred pending some non-hack fix?

Comment 6

[James Ross]

We've worked around the issue within the scope of the ChatZilla component. There should be a follow-up bug in XPFE for the real issue, however it should not IMHO block verification of this bug.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #6)
> We've worked around the issue within the scope of the ChatZilla component.
> There should be a follow-up bug in XPFE for the real issue, however it should
> not IMHO block verification of this bug.

is there a bug# for XPFE