Closed Bug 426690 Opened 16 years ago Closed 13 years ago

tab key in designMode does not indent (e.g. bullets)

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: subs, Unassigned)

References

(
URL
)

Details

Attachments

(3 files, 1 obsolete file)

example of how to catch keyboard events
1.02 KB, text/html
Details
Example how to indent/outdent a list
1.41 KB, text/html
Details
Extended example with support for table, list and arrow navigation (fix)
5.91 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

When you hit the tab key in a designMode frame, it switches focus to the next form element, rather than indenting the text or bullets.

For instance, visiting the given URL in Firefox 2 gives the expected behaviour on creating a bullet point list and then pressing the tab key. In Firefox 3 beta 5, the tab key instead shifts the focus.

Reproducible: Always
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → editor
Hardware: PC → All
Version: unspecified → Trunk
Requesting blocking since this seems to effect YUI. Manuel, can you provide a bit more detail on impact to help drivers decide if this blocks or not?
Flags: blocking1.9?
Verified and confirmed on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040904 Minefield/3.0pre. 

And verified it does work properly on Fx 2.0.0.13
It feels like a FF3 blocker to me. 

For mail, it impacts these core features:

Composing Mail: Users can no longer indent text or increase indent for bullet points. Clicking the tab key will annoy the user since they want to indent, but will instead be taken out of compose. 

Autocomplete (Mac only):  Clicking the tab key moves the cursor to the next field instead of selecting the email address from the autocomplete list. Very annoying for certain execs here at Yahoo. 

YUI: This library is used by most of the properties here at Yahoo, so this would be a huge impact on user experience, but I don't have the resources to list all of the properties. For example, I noticed that Yahoo's Search Assistant (www.yahoo.com) does not work on tab. Same as our autocomplete.

More importantly, YUI is used by many companies outside of Yahoo - even Google :-) I definitely don't know the impact on all of them. Perhaps Thomas Sha can speak to that?

Manuel
FWIW, this also affects Wordpress blog editors, and probably a lot of others. Did we do this on purpose for accessibility reasons? I notice that once in that sort of control, there's no way for me to get out of it again with the keyboard.
Yes, I believe this was changed for keyboard navigation among controls. As Mike points out, with some controls there's no way to get out of them if tabbing away isn't possible. However since it was already this way when i came aboard, cc'ing Aaron in the hopes he can provide more detail. Also, Mats Palmgren might know something about it (he's our Focus guru).
This was done on purpose, yes. If a web page wants tab to do something different than navigate they need to override what it does via JavaScript. They're going to need to do that for IE support as well. Firefox works the same way now.

I believe peterv did the actual bug fix.
I feel that this is a design flaw. Tabbing while inside an IFRAME with designMode on is an expected behavior by most users. Yes we have to work around that in other browsers, but I personally feel that the other browsers are broken.

Taking this option out of FF3, will make FF3 as crippled as the other browsers are for tabbing and list manipulation.

Just my two cents.
It's a major problem either way. It's a terrible keyboard conflict.

I'd rather have all browsers be wrong the same way and create consistency for the author to work with. The author can work around it.

Or, maybe we can come up with some grand solution to improve the situation and allow both uses of tab key for everyone. I haven't thought of one but maybe it's an issue of know one thinking hard enough.
Agreed, in the YUI RTE I have worked around the navigation issue by placing Header elements before and after the IFRAME and placed instructions for shortcut keys inside the first Header. So a screen reader user can use certain key commands to jump from the IFRAME to the toolbar or from the IFRAME to the last Header element to continue their navigation.

Personally I think designMode needs some configuration options to allow us to deal with it better.. We should be able to say: Tabbing allowed, Image Resize allowed.. I have a whole list of things I want it to do, but that is another subject ;)
How about using the escape key? Tabbing would send you into the editor directly, with all the useful editor keybindings (rather than the usual browser key bindings). Hitting escape would then give the editor control focus (and restore browser keybindings), and you could tab to go forward to the next control or shift-tab to go back. Alternatively, hitting escape again would cancel and put you back in the editor with editor keybindings.

This has the advantage of being muscle-memory compatible with other 'wrong' browsers. (If you hit escape in any of those, they'll behave the same way.)
That is a great idea, I will run that past our accessibility team and see what they have to say..
I agree with "subs" and Dav. Actually this morning I worked on this issue for Y! Mail and using the escape key was a good solution;yet a little bit disappointed

 I hope we (developers) dont get anymore of these IE surprises on FF3.

cheers!


As Aaron said, it is a major problem either way. I thought it better to be accessible by default and let the web apps handle a more complicated setup with overloading of tabbing instead of relying on every single web editing app to make itself accessible. IIRC there was also the inconsistency where shift-tab to navigate worked, but tab did't. I'm fine with reconsidering this, but note that without this change you actually get 'stuck' in the editor when using tab to navigate. The fact that we're now compatible with IE wasn't the reason to do this.
It sounds like we've agreed to that the current behaviour is reasonable (although merely the least-bad of some bad options), so this is not a blocker (and should be WONTFIX). If I've misunderstood, please re-request blocking status.
Flags: blocking1.9?
The main reason to reconsider this would obviously be backwards compatibility.
If we don't reconsider we should definitely get this documented, it wasn't
supposed to be a surprise.
I still think that the current behavior is wrong. By removing this functionality, you have removed a major feature of FF in designMode. That is list editing. How is list editing supposed to work if you are taking out the tab key.. If I prevent the default event or stop the event on the tab key inside the iframe will keyboard list editing still work? If not, then this is a major removal of a really nice feature.

[rant]
As for the IE comments, this needs to be said (not meant to start a flame war, it just needs to be said). It is a very lame excuse to change/remove things like this just "because IE does it". FF is supposed to be better than IE, so to me using this excuse is a cop-out. We heard it from WebKit with the forced update that killed the keypress event on the arrows.
[/rant]
(In reply to comment #17)
> If I prevent the default event or stop the event on the tab key
> inside the iframe will keyboard list editing still work?

You could then use execCommand with indent/outdent, no?

> [rant]
> As for the IE comments, this needs to be said (not meant to start a flame war,
> it just needs to be said).

I'd rather you read the comments made (for example comment 14) :-/.
(In reply to comment #18)
> You could then use execCommand with indent/outdent, no?

AFAIK indent/outdent doesn't apply to list editing, it's applied to blockquote levels? Did I miss a change in that it supports creating a new UL/OL when executed from an LI? I'm talking about the ability to have an LI element focused inside the IFRAME and then hit tab to create a sub list (UL/OL) and insert the current LI as the first in the list. The when Shift+Tab it reverses that behavior. That is the functionality that is "fully" removed from the Edit area when the tab key is hijacked by the focus.

> I'd rather you read the comments made (for example comment 14) :-/.

I did read them, my apologies, I read that statement wrong and it caused me to start ranting about breaking backwards compatibility and removing features without being able to control them. The WONFIX comment told me that was what was happening. I apologize for assuming that it was to be like IE.

My main concern here is that we loose a great feature in the browser that has the best support for designMode.
(In reply to comment #19)
> AFAIK indent/outdent doesn't apply to list editing, it's applied to blockquote
> levels? Did I miss a change in that it supports creating a new UL/OL when
> executed from an LI?

No change, in http://www.mozilla.org/editor/midasdemo/ with both FF2 and FF3 I can create a new UL/OL in a list by using the "Indent" button and remove it by using the "Outdent" button (they use execCommand with the commands indent and outdent). Is that not the behaviour you're looking for?
Yes, that is what I want it to do. But now you are saying that I have to write the interface for something that I was given for free before this change? In my opinion that is a regression failure and removal of features.

So given that I will have to trap the tab key and mimic the old interface, we still have to deal with the ability to focus the control again to make it accessible. I don't see how this change really fixes anything. The only thing it really does is make editors add code for FF3 to make it act like FF2 but loose the accessibility that this fix is supposed to add..
I think this discussion has gone on long enough and isn't going to change anything.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
This bug is a severe blocker for all editor-based applications. It affects all midas-based web applications and extensions, it already affects the successor to Nvu I am currently working on. It affects Blogger, Movable Type, Dotclear and most blog systems.

Because of text processors or Office-like apps, users are *used* to use the tab/shift-tab combination to indent/outdent a list, and changing that behavior that we probably have since Netscape Gold is IMHO a major mistake.

Even if we have an accessibility problem here, solving the problem is supposed to bring the user experience of people having accessibility issues to the user experience quality level of people with no accessibility issue, not the contrary. Lowering the bar and impacting that way *all users* to solve a bug is an error.

We've been having this feature forever, and we suddenly put the burden on webapps that don't implement indent and outdent buttons. It'll take time until all webapps using designMode fix their editor. In the meantime, millions of users cannot create a sublist, which is absolutely ridiculous.

As the editor guy, I ***VERY*** strongly disagree with the WONTFIX.

Aaron, I would like to read your take on this issue : is fixing the accessibility issue worth the price here ?
Ok, I am requesting this bug is reopened and becomes a blocker for next Firefox release. I am even requesting a fix for this bug to be integrated in the forthcoming security releases of Firefox. The sooner, the better.

Because of the change, it's now impossible to even insert a \t char inside an editor !!! Man, this is crazy, how can such a change with such an impact be checked in without studying in detail the effect on the editor.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I have pinged MSFT, Opera and Webkit (+Peter and Aaron for Moz) to see if we can fix this in a cross-browser way, allowing tab in the editor AND a common key combination to leave an editor's focus for accessibility reasons.
> solving the problem is supposed to bring the user experience of people having
> accessibility issues to the user experience quality level of people with no
> accessibility issue, not the contrary.

For what it's worth, I don't have "accessibility issues", and this change improved my user experience...  That is, this change improves user experience on one axis across the board while making it worth on another axis (user experience is not exactly one-dimensional).

Honestly, we've had this discussion for years for <textarea>.  I don't see why different considerations apply for HTML vs plaintext.
[quote]As Aaron said, it is a major problem either way. I thought it better to be
accessible by default and let the web apps handle a more complicated setup with
overloading of tabbing instead of relying on every single web editing app to
make itself accessible.[/quote]

I could live with this, but how do we go about doing it?  Passing keyboard events to an iframe is no simple task (not for me anyway).  Perhaps a NOFIX would be acceptable if FFX provided some documentation, and in any case some resources other than this bugzilla page...it *is* a major behavioural change, and not one that can be carried out without some preparation.  I agree in principal with how you made that decision, but it's worth remembering that many developers will need your help if you change FFX's behaviour in such a way, myself included.
Clancy, here is an example of how to catch keyboard events.
> We've been having this feature forever, and we suddenly put the burden on
> webapps that don't implement indent and outdent buttons. It'll take time until
> all webapps using designMode fix their editor. In the meantime, millions of
> users cannot create a sublist, which is absolutely ridiculous.
> 
> As the editor guy, I ***VERY*** strongly disagree with the WONTFIX.

I just want to echo Daniel's comments in #26 above. If you use these apps on a regular basis (eg. Blogger, Moveable Type, etc), this "bug" becomes a showstopper - I downgraded back to FF2 within hours of installing FF3 when it first came out. It's simply to painful to try and work around. I can't move to FF3 (as much as I want to) until this is either fixed or there's some kind of workaround to allow the old behavior to continue. 

A quick search on the web reveals this is a fairly common problem. You can argue that the apps need to fix their implementation; the reality is that it's going to take a long time for that to happen, and that means folks (like me) will continue to live with FF2.

Please do something about this sooner rather than later...
Christian
This example show a possible patch for existing editor implementations to get the old indent/outdent behaviour for lists.

One could improve the behaviour for tables. Therefore one need to check for the focused node and walk up the hirarchy to check for parent elements. What should happen if I'm in a list that's in a table cell?

A good starting point is:
https://developer.mozilla.org/en/DOM/Selection

To get the current focused node something like this might help:
  iframe.contentWindow.getSelection().focusNode
Extended example 
- A list will be in/outdented when the focus is at a list item and the user presses TAB
- The content of the next/previous cell will be selected if the user presses TAB
- The current selection will be collapsed to the end when the user presses the RIGHTARROW key
- The current selection will be collapsed to the start when the user presses the LEFTARROW key
This is pretty similar to the default behaviour in applications like MS WORD.

I use this as a workaround. Maybe it is of any use for you as well.

There is also a workaround included for showing the selection (see bug 592229). 

And I found another bug: When stepping through all table cells by pressing TAB, the selection in the last cell will not be collapsed when moving outside the table. The same behaviour exists for the first table cell. Maybe someone find's a workaround for that too.
Update for the previous example with a fix for the selection update problem. (See bug 592229 for details.)
Attachment #470756 - Attachment is obsolete: true
Marking as WONTFIX because:
• in a XUL editor you can always use the eEditorAllowInteraction flag;
• in a web page you can catch the <tab> key as Daniel Kirsch suggests.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: