After placing focus in a table cell, I can't navigate to the next cell using the tab key

VERIFIED FIXED

Status

--
critical
VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: chrispetersen, Assigned: neil)

Tracking

({regression})

Trunk
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2])

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Build: 2003-04-11-03
Platform: All
Expected Result: When editing a table, I should be able to tab to the next cell
in the table.
What I got: After placing focus in a table cell, I can't navigate to the next
cell using the tab key.

Steps to reproduce:

1) Insert a table in a new composer document
2) Place focus in the first table cell so the carat appears
3) Now, press the tab key
4) Carat remains in the current cell instead of appearing in the next cell
(Reporter)

Comment 1

16 years ago
This appeared to regress on the 04-02-03 Macho build and 04-02-09 Win32 build
since it was working correctly on the 04-01-08 trunk builds.
(Reporter)

Updated

16 years ago
Keywords: nsbeta1, regression
(Reporter)

Comment 2

16 years ago
For some reason this isn't happening in Mail compose, just the Composer application.
daniel or brian, any idea why this is occuring? could it be related to bug
198976? (not sure, since this bug still occurs with 4/10 builds, and bug 198976
was verified fixed...)

Comment 4

16 years ago
bryner landed his patch for "ctrl-enter" in mail in this timeframe

my guess is that the composer app has a listener and it's now getting the event
(and eating it) before the editor sees it
(Reporter)

Comment 5

16 years ago
This bug might be a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=201408

Comment 6

16 years ago
*** Bug 201408 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 7

16 years ago
Created attachment 120435 [details] [diff] [review]
Proposed patch

AFAIK only a <key> sits between an <editor> and the focus controller. bryner?
(Assignee)

Updated

16 years ago
Attachment #120435 - Flags: superreview?(bryner)
Attachment #120435 - Flags: review?(brade)

Comment 8

16 years ago
Comment on attachment 120435 [details] [diff] [review]
Proposed patch

The above is fine but don't we also need to address meta-tab (command-tab)? 
What about alt-tab?
(Assignee)

Comment 9

16 years ago
Or perhaps aaronl knows all those focus-moving keys I need to eat...

Comment 10

16 years ago
Does your proposed fix need a line for an unmodified Tab?

Neil, I just updated the docs at:
http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html#TAB
Hope they're useful.

Comment 11

16 years ago
Editor triage team: nsbeta1+/adt2

Over to Neil since he has a patch in progress.  Hope that's OK with you, Neil.
Assignee: composer → neil
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
(Assignee)

Comment 12

16 years ago
aaronl, feedback from mac users in #mozilla suggests that cmd+tab is mac
equivalent of alt+tab?

also, editor can always do something with a unmodified tab so I shouldn't need
to trap it, but I can add code if someone especially asks.

Comment 13

16 years ago
Comment on attachment 120435 [details] [diff] [review]
Proposed patch

r=brade
please add key for TAB with no modifiers for completeness/consistency (in case
some day core editor doesn't handle tab in all cases)
Attachment #120435 - Flags: review?(brade) → review+
Comment on attachment 120435 [details] [diff] [review]
Proposed patch

sr=me, though it might be nice to extend XUL so you can use
preventDefault="true" on <key> elements like you can on XBL <handler>s. Some
other time.
Attachment #120435 - Flags: superreview?(bryner) → superreview+

Comment 15

16 years ago
*** Bug 202193 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

16 years ago
Fix checked in (two days ago!).
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 17

16 years ago
Cool. Verified in the 2003-04-22-08 Win32 and 2003-04-23-08 Macho builds.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.