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



15 years ago
13 years ago


(Reporter: Chris Petersen, Assigned:




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt2])


(1 attachment)

1.11 KB, patch
Kathleen Brade
: review+
Brian Ryner (not reading)
: superreview+
Details | Diff | Splinter Review


15 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

Comment 1

15 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.


15 years ago
Keywords: nsbeta1, regression

Comment 2

15 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

15 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

Comment 5

15 years ago
This bug might be a dup of

Comment 6

15 years ago
*** Bug 201408 has been marked as a duplicate of this bug. ***

Comment 7

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

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


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

Comment 8

15 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?

Comment 9

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

Comment 10

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

Neil, I just updated the docs at:
Hope they're useful.

Comment 11

15 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]

Comment 12

15 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

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

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

15 years ago
*** Bug 202193 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
Fix checked in (two days ago!).
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 17

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