[10.5] Pressing tab in an editable table view starts editing the current item and prevents tabbing to the next control

RESOLVED FIXED in Camino1.6

Status

Camino Graveyard
Toolbars & Menus
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Assigned: Sean Murphy)

Tracking

({fixed1.8.1.12})

unspecified
Camino1.6
PowerPC
Mac OS X
fixed1.8.1.12

Details

(Whiteboard: [camino-1.5.5])

Attachments

(1 attachment)

1.95 KB, patch
Jeff Dlouhy
: review+
Stuart Morgan
: superreview+
Details | Diff | Splinter Review
In the editor window, the tab chain is busted.  Tab acts like return, selecting the current table cell for editing.  As a consequence, you cannot tab to the the action button when FKA is on, leaving it keyboard-inacessible.
Flags: camino1.6b2?
(Assignee)

Comment 1

11 years ago
I see now that the problem is caused by the ExtendedTableView and new NSTableView tabbing behavior in Leopard's AppKit.

From the AppKit Release Notes, tabbing now works like this:

>Tables now support inter-cell navigation as follows:
>
>- Tabbing forward to a table focuses the entire table.
>- Hitting Space will attempt to 'performClick:' on a NSButtonCell in the selected row, if there is only one instance in that row.
>- Tabbing again focuses the first "focusable" (1) cell, if there is one.
>- If the newly focused cell can be edited, editing will begin.
>- Hitting Space calls 'performClick:' on the cell and sets the datasource value afterwards, if changed. (2)
>- If a text cell is editing, hitting Enter will commit editing and focus will be returned to the tableview, and Tab/Shift-tab will commit the editing and then perform the new tab-loop behavior.
>- Tabbing will only tab through a single row
>- Once the last cell in a row is reached, tab will take the focus to the next focusable control.
>- Back tabbing into a table will select the last focusable cell.

So, tabbing into the engines will start editing the first one, and then (since there's only one column) another tab will stop editing and jump to the next key view.  The reason it's not working in our ExtendedTableView is because of the behavior change being performed in -textDidEndEditing:

"// We just want to keep the selection on what was being editing."
http://mxr.mozilla.org/seamonkey/source/camino/src/extensions/ExtendedTableView.mm#141

I'm trying to decide what our options are here, as we'll want to preserve the ExtendedTableView's behavior pre-Leopard.  I think a change will need to be made, though, because key view navigation will be broken anywhere this table is used.
(Assignee)

Comment 2

11 years ago
Created attachment 296563 [details] [diff] [review]
Patch

Since the actions taken by ExtendedTableView in -textDidEndEditing effectively break the newly established NSTableView key-view looping behavior under Leopard, I think we need to have it back off when running on 10.5.

Furthermore, the reason ExtendedTableView was changing the -textDidEndEditing behavior is no longer an issue on Leopard.

(The SearchEditor's tab chain does work currently on Tiger, so no change is needed for that case).
Assignee: nobody → murph
Status: NEW → ASSIGNED
Attachment #296563 - Flags: review?(Jeff.Dlouhy)
(Assignee)

Updated

11 years ago
Summary: Action button not in tab chain in Search Engine Editor window → [10.5] Action button not in tab chain in Search Engine Editor window

Comment 3

11 years ago
Comment on attachment 296563 [details] [diff] [review]
Patch

From my testing this seems to not have any regressions in other areas where we use table views and works as expected.

r=me
Attachment #296563 - Flags: review?(Jeff.Dlouhy) → review+
(Assignee)

Updated

11 years ago
Attachment #296563 - Flags: superreview?(stuart.morgan)

Comment 4

11 years ago
Comment on attachment 296563 [details] [diff] [review]
Patch

sr=smorgan
Attachment #296563 - Flags: superreview?(stuart.morgan) → superreview+
Comment on attachment 296563 [details] [diff] [review]
Patch

I don't like that the first tab-press in the table view still begins editing the current item, whereas that doesn't happen at all on 10.3 (and presumably 10.4 as well).  This also afflicts other table views (e.g. the Collections table in the Bookmarks Manager, if you have your own collection there).

Oddly enough, shift-tab works fine, as does the first tab after a shift tab.
Attachment #296563 - Flags: review-
Re-summarizing, since this affects other table views (and in the Collections case, FKA is not required).
Summary: [10.5] Action button not in tab chain in Search Engine Editor window → [10.5] Pressing tab in an editable table view starts editing the current item instead of tabbing to the next control
Comment on attachment 296563 [details] [diff] [review]
Patch

Retracting the r-, since murph has showed me other places where the OS does this (and pointed out the part of comment 1 I missed after my eyes glazed over from the AppKit quote).  It's bizarre, but OK ;)

We'll need to fix up the main Bookmarks view to also adopt this behavior (in another bug)
Attachment #296563 - Flags: review-
Landed on the trunk and MOZILLA_1_8_BRANCH in advance of b1.

Since this is a 10.5 bug instead of a bug in the Search Engine Editor, we might want to take it for 1.5.x, too.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Flags: camino1.6b2? → camino1.5.5?
Keywords: fixed1.8.1.12
Resolution: --- → FIXED
Summary: [10.5] Pressing tab in an editable table view starts editing the current item instead of tabbing to the next control → [10.5] Pressing tab in an editable table view starts editing the current item and prevents tabbing to the next control
Target Milestone: --- → Camino1.6
Checked in on the CAMINO_1_5_BRANCH. I forgot "Patch by murph"; sorry about that, murph :(
Flags: camino1.5.5? → camino1.5.5+
Whiteboard: [camino-1.5.5]
You need to log in before you can comment on or make changes to this bug.