Closed Bug 475102 Opened 16 years ago Closed 15 years ago

Can't switch tabs with the keyboard on whitehouse.gov

Categories

(Camino Graveyard :: Accessibility, defect)

Product:
Camino Graveyard
Component:
Accessibility
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: alqahira, Assigned: stuart.morgan+bugzilla)

References

(
URL
)

Details

(Keywords: access, regression)

Attachments

(1 file)

offending script
4.33 KB, text/plain
Details 
Ever since the Obama version of the site went live, we've been unable to switch tabs with the keyboard in 2.0* on any page on whitehouse.gov (1.6.x works fine).

As far as I can tell, that's the only keystroke that doesn't work; other Cmd-Opt keystrokes work, Cmd-{l|r}arrow work for the alternate back/forward commands, arrows work for scrolling....

Tab-switching with Cmd-Opt-{l|r}arrow works in Firefox 3.

Sam and I don't know if this is a site bug (there's tons of js there) or a Gecko bug or what.
...and you can switch tabs with JS off.  (Cmd-L followed by the Cmd-{l|r}arrow also works, as does Cmd-F and then the shortcut.)
The js used on that site is all jquery based. As far as I can see.

This regressed:
works
2.0a1pre (1.9pre 2008050100)
fails
2.0a1pre (1.9pre 2008050200)


http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-05-01+00%3A00%3A00&maxdate=2008-05-02+03%3A00%3A00&cvsroot=%2Fcvsroot

hmm.

Bug 383085: Stop building console, updates, alerts, and extensions in xpfe/ for non-MOZ_XUL_APP (only affects Camino). r=mento a1.9=beltzner 

Bug 430499 [10.5] Can't switch tabs with CTRL + Tab r=josh, sr=vlad, a=dsicore 

Maybe
Yeah, I think it's bug 430499. In the interest of completeness, I suppose bug 431429 could also be guilty, though.

See also bug 417466. I think this is more of the same root issues behind bug 459744.

cl
First of all, big thanks for finding that regression range!  Any chance of being able to create a reduced testcase?

Second, hendy saw 

WARNING: GetCharCode used for wrong key event; should use onkeypress.: file nsDOMKeyboardEvent.cpp, line 116

when attempting this (that line gets called when keyDown is hit, which is one of the things mentioned in bug 430499).  Dunno if that message shows up all the time when switching tabs or not, nor if that warning also shows up in Firefox when doing the same thing.

Third, does this bug exist on 10.4, or only on 10.5?

Fourth, have I mentioned that I hate key handling?
Not a test case really.

But here is what I found out:

In http://www.whitehouse.gov/includes/eop/jqfunctions.js there is call to 'hotkeys' (line 191 & 192)

> $.hotkeys.add('left', function(){$.galleria.prev();});
> $.hotkeys.add('right', function(){$.galleria.next();});

'hotkeys' is defined in http://www.whitehouse.gov/includes/eop/jquery-plugins.js
(line 457 and down)

The source for that 'hotkeys' jquery plugin is (google sez)
http://code.google.com/p/js-hotkeys/

Here is another page that shows the bug
http://jshotkeys.googlepages.com/test-static-01.html

----
Keyboard shortcuts that fail: cmd-opt left/right, cmd-opt - (textzoom out), cmd-opt R, cmd-opt H, ....

Minefield works as expected with cmd-opt left/right and cmd-opt H.
----
PS somethin's wrong with that whitehouse site, I've never seen such a clean code in that type of site.
(In reply to comment #4)
> Third, does this bug exist on 10.4, or only on 10.5?

I tested this with 2009-01-24-00-2.0-M1.9 on 10.4.11.
I also can't switch tabs with the keyboard shortcuts.
(In reply to comment #4)
> Second, hendy saw 
> 
> WARNING: GetCharCode used for wrong key event; should use onkeypress.: file
> nsDOMKeyboardEvent.cpp, line 116
> 
> when attempting this (that line gets called when keyDown is hit, which is one
> of the things mentioned in bug 430499).  Dunno if that message shows up all the
> time when switching tabs or not, nor if that warning also shows up in Firefox
> when doing the same thing.

1) It doesn't show up all the time when switching tabs, just on this site
2) It also shows up in Firefox 3.0.x, which can switch tabs just fine

It's possible that the warning is completely spurious in this case.

Other interesting discoveries:

a) the JS on the page also breaks {L|R}Arrow, Cmd-{L|R}Arrow and Opt-{L|R}Arrow in the text fields on the page (in both apps) but *does not* break Shift-{L|R}Arrow, Cmd-Shift-{L|R}Arrow or Opt-Shift-{L|R}Arrow

b) loading MODi unbreaks all the keyboard shortcuts
Blocks: 430499
(In reply to comment #7)

> Other interesting discoveries:
> 
> a) the JS on the page also breaks {L|R}Arrow, Cmd-{L|R}Arrow and Opt-{L|R}Arrow
> in the text fields on the page (in both apps) but *does not* break
> Shift-{L|R}Arrow, Cmd-Shift-{L|R}Arrow or Opt-Shift-{L|R}Arrow

This is also broken in Minefield latest, Shiretoko latest and Fx 3.05. I verified that those work on a simple form page.

Keyboard shortcuts that use cmd+shift+option (as opposed to only cmd+option) work correctly in Camino.


---------
> b) loading MODi unbreaks all the keyboard shortcuts.

Interesting.
After loading MODi, I get a truckload of js errors
[JavaScript Error: "that.all[element] is undefined" {file: "http://www.whitehouse.gov/includes/eop/jquery-plugins.js" line: 514}]
(line 514 is part of the code of that jquery plugin that causes the problem(s) in this page).
1. The issue with the broken arrow keys in textfields is actually cross-Gecko browser and cross-platform (using left/right arrows is equally broken in Minefield/Linux). The script seems to intentionally disable those.
Worth a separate (TE) bug, I think. [1]

2. the tab switching issue. There appears to be a bug in the script, the existence of the command key is not taken into account. 
http://code.google.com/p/js-hotkeys/issues/detail?id=31.

'patching' that script on my local copy fixes the tab-switching issue.


[1] and those are br0ken in WebKit as well
Attached file offending script — 
(saved/extracted from the WhiteHouse.gov site)
It sounds like both of the identified problems are perhaps resolvable via TE, but I'm still puzzled as to why Firefox is not affected, because that means there's either a bug in Gecko or one of the two FEs.

Wild guesses:

1) Firefox somehow processes the command before the page is able to eat the keystrokes (seems unlikely given bug 459744)
2) Firefox is generating a different set of keycodes than we generate
2a) We're not generating a "Cmd" keycode to go along with the arrow keycode
3) Some sort of difference between keyup, keydown, and keypress (either what the menu system looks at, or what order they're posted, or something)

I really have no idea how we'd go about testing/investigating these wild guesses, though.
(In reply to comment #11)

Filed bug 477453 for the textfield issue. It annoyed me today (uncle google found what I was looking for).

I've no idea either about the second issue. I wouldn't be surprised if Fx was actually buggy.
(In reply to comment #12)

> I've no idea either about the second issue. I wouldn't be surprised if Fx was
> actually buggy.

What came to my mind the other day to test this was to find some way of having the problematic script annotate what it's seeing at certain points, e.g. by adding some logging code to it on a local-web copy of, say, the 404 page (we've got a bunch of samples of logging code hung off of bug 373680).
FIXED by the 1.9.0.8 checkin for bug 459744.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(In particular, by Stuart's patch there, so he owns the FIXED bug ;-) )
Assignee: nobody → stuart.morgan+bugzilla
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: