In recent nightly Minefield builds, using the tab key in a textarea or a designMode="on" iframe causes the focus to switch to the next element, rather than inserting a tab/spaces. I've tracked this change in behavior down to working as expected in 20070626 builds, and switching focus in 20070628 builds. Probably a regression due to contenteditable.

Afact, tabbing in a textarea always used to switch focus to the next element, so that doesn't seem like a bug. But switching focus in a designMode iframe when pressing tab is indeed a bug.

Martijn, you're correct. I made a mistake in asserting that textareas were also affected, but their behavior is unchanged. The relevant part of the content editable patch appears to be: --- editor/libeditor/text/nsEditorEventListeners.cpp 1 May 2007 22:24:22 -0000 1.244 +++ editor/libeditor/text/nsEditorEventListeners.cpp 5 Jun 2007 16:59:07 -0000 @@ -223,7 +224,8 @@ nsTextEditorKeyListener::KeyPress(nsIDOM case nsIDOMKeyEvent::DOM_VK_TAB: if ((flags & nsIPlaintextEditor::eEditorSingleLineMask) || (flags & nsIPlaintextEditor::eEditorPasswordMask) || - (flags & nsIPlaintextEditor::eEditorWidgetMask)) + (flags & nsIPlaintextEditor::eEditorWidgetMask) || + (flags & nsIPlaintextEditor::eEditorAllowInteraction)) return NS_OK; // let it be used for focus switching if (isAnyModifierKeyButShift) Reverting this change restores tab-key functionality to iframe editors. I think that this change is fairly important. The tab key is used extensively for editing lists and sublists, and currently doesn't work for that purpose in applications like Google Docs.

Attached patch reverts the tab behavior change made by the contenteditable patch. I don't know why this change was made, so I am not confident that it should be reverted without some more thought. This fixes the regressed behavior where the tab key doesn't work in designMode windows, and also permits tabs to work in contenteditable areas. I've been working on a tab/list bug (384147) and have built test cases for it using contenteditable areas and this patch, so I'm pretty sure there aren't any obvious problems with enabling tabs for contenteditable areas.

You mean that pressing the tab key inserts a tab in the contenteditable area with the patch? That doesn't seem like the right behavior to me. How can one navigate with the keyboard through the document then? Also IE7 allows tabbing through the document, using the tab key with contenteditable elements and doesn't inset a tab.

Martijn, you're correct of course that navigating through the document with tab is quite nice, and it can be very annoying if focus would get caught on an element. However, that is the behavior that FF2 presents: focus can get caught in a designMode iframe and not released. I suppose with designMode it made sense: the assumption is that you're editing the whole document, so of course capturing tabs makes sense. There are some implications to making this behavior change. For example, Google Docs word processor uses a designMode iframe for editing the content document. With a recent nightly build, hitting tab in the content area of such a document will switch focus, where it typically would enter spaces, indent lists, etc. I am sure there are many rich-text editor components like TinyMCE that would be surprised by this change as well. What do you think of: a) reverting to the FF2 behavior for designMode areas, to not surprise & frustrate folks, and b) leaving the new switch-focus behavior for contentEditable areas (which is consistent with IE), but confirming that said behavior can be overridden (which appears possible with IE, but I'm looking into how: Google Docs as an example, tab works like one would expect).

I've confirmed that by capturing the keydown event, it is possible to manually handle the tab key in contentEditable areas. Since that behavior matches IE, I'm personally content to leave tab as a switch-focus key for contentEditable areas. This is still a behavior change that will affect applications using designMode, and I think it would be good to remove this change. I'm not quite sure how to proceed with a patch though, since I don't know if nsIEditor can identify which area type it is in. The editor flags are the same for designMode areas and contentEditable areas.

I think your suggestions in comment 5 are good ones. Maybe a new execCommand named switchFocusOnTab or something could be created to make it easier to change the behavior for the tab key for website developers?

Please WONTFIX this. P.S. the actual bug to fix tabbing is bug 190513. We're waiting for beltzner to tell us what the decision is. We should work the same as IE and be 508 compliant.

I should say that an easy way for developers to switch behaviors is fine, but please make the default behavior accessible. Not all users have the ability to use the mouse.

Sorry, I was wrong. I thought that IE7 inserted a tab when pressing the tab key in a designMode iframe, but that's not the case. So I agree with Aaron. The behavior in current trunk builds is the same as IE7. I think this bug should become WONTFIX.

Marking WONTFIX per comment 8.