98624 - unification of tab / shift-tab behavior in Composer

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, defect)

Description

[sujay]

If I type some text and make it a blockquote, I can't outdent it with
shift-tab.  
However, it does work if you are inside a list.  This seems inconsistent to me.

Perhaps the real inconsistency is the use of tab to insert spaces instead of a 
blockquote?



------- Additional Comments From [e-mail] 2001-07-25 13:20 -------

we can't outdent/indent with tab, outdent/indent shortcut is ctrl+[ ctrl+]



------- Additional Comments From Håkan Waara 2001-07-25 13:33 -------

We can't outdent/indent with tab/shift-tab?   it works in the editor today!



------- Additional Comments From [e-mail] 2001-07-25 14:40 -------

ok, generalize this bug
The intent of this bug is to unify tab/shift-tab behavior in Composer rules.
Tab should not insert spaces.
Tab should not do form navigation.
Tab should insert blockquote (except in lists where it increases the list
level).
Shift-tab should remove a level of blockquote or list (if possible).
Tab should not do table cell navigation.
Table cell navigation will be accomplished with accel-tab and accel-shift-tab.

Comments?



------- Additional Comments From Charles Manske 2001-07-25 17:35 -------

I totally agree with Kathy's suggestion (I've made similar suggestions before)!
Tab should to the same thing everywhere. I suggest using 
Ctrl+Tab for navigate to next cell, Ctrl+Shift+Tab for previous cell.



------- Additional Comments From Akkana 2001-07-25 18:29 -------

This discussion keeps coming up, and the problem with using [mod key]-tab is
that it's already overloaded to do various other things in various operating
systems (for example, I just tried it in kde and it switches between workspaces,
which I think is fairly typical in Unix window managers).



------- Additional Comments From Charles Manske 2001-07-25 18:40 -------

Good point. Let's try to collect all the modified uses of Tab.
In Windows, Alt+Tab switches among application windows. Ctrl+Tab switches 
among windows in a multiwindow app.



------- Additional Comments From Aaron Leventhal 2001-07-25 18:45 -------

Here you go:

http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html#TAB



------- Additional Comments From [e-mail] 2001-08-01 13:49 -------

also two more behaviors:

using tab for a list item inside table cell, doesn't go to next cell

and

Tabs in table cells should focus next cell.

I'm DUPing two bugs against this bug...



------- Additional Comments From Charles Manske 2001-08-02 08:54 -------

We are trying to NOT use tab to navigate from table cell to table cell, so its
use as an indent key is consistent when you are in or out of a table. The 
problem is finding alternative keys to use for table navigation.



------- Additional Comments From [e-mail] 2001-08-02 11:38 -------

handing over to charley



------- Additional Comments From [e-mail] 2001-08-07 18:34 -------

really giving to cmanske



------- Additional Comments From Charles Manske 2001-08-08 15:25 -------

As much as we don't like to add prefs, how does this sound as a new pref:

Tab key behavior when inside a table:
() Tab moves caret to next table cell, Shift+Tab moves to previous cell
() Tab indents paragraph or list item; Shift+Tab removes indent
   [ ] Ctrl+Tab moves caret to next table cell, 
       Ctrl+Shift+Tab moves to previous cell



------- Additional Comments From Charles Manske 2001-08-08 15:29 -------

Just to be sure, we all agree that using Tab key to insert spaces is dead,
right? I.e., ignoring the table issue, it should should indent a paragraph 
just as it indents a list item, right?



------- Additional Comments From [e-mail] 2001-08-08 15:49 -------

great compromise



------- Additional Comments From Akkana 2001-08-08 16:32 -------

I like the pref, since I don't like the setting where tab indents the current
paragraph, and I hate to lose out on using it for table navigation.

I actually liked having tab insert spaces, but I'm probably the only one, and
it's not that big a deal to me (I don't depend on it to do that in html editors,
or even expect it).



------- Additional Comments From [e-mail] 2001-08-09 07:12 -------

The tab will not insert spaces in Composer.  It might in some other editor but 
that's not for us to determine/restrict.

I wish we didn't need a pref; or at least a visible pref.  It just makes for
more 
QA testing and potential bugs.  I assume the default is to navigate table with 
the alternate keybinding (not sure why this would be a checkbox pref tho).

What is the alternate keybinding going to be?  My understanding is that we can't 
use control-tab on windows because it is used for cycling through windows in a 
multi-window application.

Charley--Is there some reason why this bug is restricted so non-Netscape people 
can't see what we are discussing?  I'm not sure why you changed the permissions.



------- Additional Comments From Charles Manske 2001-08-09 16:29 -------

Using prefs is the only way to satisfy everyone, I'm afraid.
According to:
http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html#TAB
Ctrl+Tab is supposed to move from frame to frame in Browser.
Ctrl+Tab is used in a "multiple document Windows" app to move from window to
window, but we aren't that kind of app, so there's no conflict.
The selection of that alternate keybinding is a checkbox because it only makes
sense to use it if you select the second radio button item ("Tab indents...").
It would be grayed out if you select the radio button to use Tab to navigate
cells.

I never noticed the "Netscape Confidential" setting before! I see no reason
to restrict, so removing that limitation.



------- Additional Comments From Charles Manske 2001-08-28 16:03 -------

*** Bug 89117 has been marked as a duplicate of this bug. ***



------- Additional Comments From Charles Manske 2001-08-28 16:04 -------

*** Bug 96734 has been marked as a duplicate of this bug. ***



------- Additional Comments From Charles Manske 2001-08-28 16:05 -------

*** Bug 97091 has been marked as a duplicate of this bug. ***



------- Additional Comments From Charles Manske 2001-08-28 16:07 -------

See bug 96734 for issues relating to tab not working in certain paragraph
styles;
bug 97091 is about tab not working in table when cell is center-aligned.

Comment 1

[sujay]

*** Bug 92287 has been marked as a duplicate of this bug. ***

Comment 2

[Håkan Waara]

Why are you creating all these new bugs and making the real ones confidential?

I originally filed that bug. There was no confidential/interesting information
about Netscape in it.

Comment 3

[Kathleen :Brade]

Unfortunately the original bug did need to be made confidential.  I'm very sorry 
for the pain incurred by having to create new bugs.  :-(

Comment 4

[Syd Logan]

No non-administrative activity on this bug for a month. Is it reasonable to
expect this for 0.9.5, or should it be pushed out?

Comment 5

[Charles Manske]

0.9.5 seems reasonable

Comment 6

[Syd Logan]

spam composer change

Comment 7

[Charles Manske]

*** Bug 92284 has been marked as a duplicate of this bug. ***

Comment 8

[Charles Manske]

As noted in bug 92284, be sure this work includes the correct setting of the
accel text in relevant menuitems, such as Format | Increase Indent / 
Decrease Indent

Comment 9

[:deanis74]

Regarding navigating table cells, MS Word (on Windows, at least) allows
Ctrl+Arrows to navigate.  Wouldn't it be more consistent to support this
keybinding instead of introducing a new one?

Comment 10

[Charles Manske]

I thought Ctrl+left/right arrow moved "by word"? Does it switch to cell to cell 
navigation inside a table? I do like that idea, though.

Comment 11

[Simon Fraser [no longer active]]

Erk, modes. Modes bad.

Comment 12

[Aaron Leventhal]

Ctrl+left and Ctrl+right are move by word on Windows and Linux. On Mac OS,
Alt+left and Alt+right move by word. Move by word is still extremely important
in the context of table cells (especially in web documents where tables might be
used for layout).

Of course, moving by table cells is also crucial in an HTML editor.

Therefore I suggest the following keys for moving by table cell in Composer:
Windows/Linux - Alt+arrow 
Macintosh - Ctrl+arrow (not cmd+arrow) 

Comment 13

[Charles Manske]

load balancing

Comment 14

[Kathleen :Brade]

*** Bug 98616 has been marked as a duplicate of this bug. ***

Comment 15

[Charles Manske]

moving milestone

Comment 16

[Syd Logan]

In wordpad, tab just positions the caret. why are we not just doing that?

Comment 17

[Charles Manske]

Wordpad doesn't do tables or indenting. 

Comment 18

[Syd Logan]

Kevin and I recommend this to make it easier on users and simpify:

tab inserts non-breaking space
shift tab removes non-breaking space

This is natural for users who are used to tab and shift-tab navigation in
dialogs where one is undoing the other, and editors that insert tab characters
or spaces.

Let indents be done with the indent button and command key versions ctrl]+ etc,
and be based on blockquote.

If in list, the tab should add non-breaking space, and shift tab undo them. If
you want to indent, use the indent button.

Tab == nonbreaking space
Indent == blockquotes.

Comment 19

[Charles Manske]

changing milestone

Comment 20

[Syd Logan]

There are plenty of workarounds, minusing. I don't see this as an accessibility
issue since needed controls are in the menus and toolbar. EDITORBASE-, nsbeta1-

Comment 21

[Charles Manske]

What workarounds? In what context: in a list? in a paragraph? in body text? 
in a table?
In each of those cases, the tab key behaves differentently.

Comment 22

[sujay]

*** Bug 139791 has been marked as a duplicate of this bug. ***

Comment 23

[Susie Wyshak]

I see the comment "We are trying to NOT use tab to navigate from table cell to
table cell...The problem is finding alternative keys to use for table navigation."

Wondering why I expected to be able to tab from cell to cell, I looked at Word,
Dreamweaveer, and Composer 4.x and confirmed that my expectation was based on
the fact that all of those use tab to navigate from cell to cell. 

Comment 24

[Syd Logan]

nsbeta1- per buffy traige

Comment 25

[Robin Monks]

*** Bug 162469 has been marked as a duplicate of this bug. ***

Comment 26

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 27

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 28

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 29

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 30

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 31

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 32

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 33

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420