Closed
Bug 98624
Opened 23 years ago
Closed 15 years ago
unification of tab / shift-tab behavior in Composer
Categories
(SeaMonkey :: Composer, defect)
SeaMonkey
Composer
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: sujay, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: embed, topembed-, Whiteboard: [QAHP] verify 89117 when this is fixed. EDITORBASE- (3 days))
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 beppe@netscape.com 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 brade@netscape.com 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 sujay@netscape.com 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 beppe@netscape.com 2001-08-02 11:38 -------
handing over to charley
------- Additional Comments From beppe@netscape.com 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 beppe@netscape.com 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 brade@netscape.com 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.
*** Bug 92287 has been marked as a duplicate of this bug. ***
Comment 2•23 years ago
|
||
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•23 years ago
|
||
Unfortunately the original bug did need to be made confidential. I'm very sorry
for the pain incurred by having to create new bugs. :-(
Priority: -- → P3
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?
Updated•23 years ago
|
Whiteboard: [QAHP] verify 89117 when this is fixed. → [QAHP] verify 89117 when this is fixed. EDITORBASE (3 days)
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 8•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Erk, modes. Modes bad.
Comment 12•23 years ago
|
||
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 14•23 years ago
|
||
*** Bug 98616 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
In wordpad, tab just positions the caret. why are we not just doing that?
Comment 17•23 years ago
|
||
Wordpad doesn't do tables or indenting.
Comment 18•23 years ago
|
||
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.
Updated•23 years ago
|
Comment 20•23 years ago
|
||
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•23 years ago
|
||
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.
Updated•23 years ago
|
Reporter | ||
Comment 22•23 years ago
|
||
*** Bug 139791 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla1.1alpha → mozilla1.2beta
Updated•23 years ago
|
Comment 24•22 years ago
|
||
nsbeta1- per buffy traige
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 25•20 years ago
|
||
*** Bug 162469 has been marked as a duplicate of this bug. ***
Updated•17 years ago
|
Assignee: cmanske → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: sujay → composer
Target Milestone: Future → ---
Comment 26•16 years ago
|
||
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
Status: NEW → UNCONFIRMED
Comment 27•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•15 years ago
|
||
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
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•