Bugzilla – Full Text Bug Listing
| Summary: | Shift+Tab in editor changing focus instead of unindent | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> |
| Component: | Editor | Assignee: | Silenio Quarti <Silenio_Quarti> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | carolynmacleod4, eclipse.felipe, Silenio_Quarti |
| Version: | 0.3 | ||
| Target Milestone: | 0.4 M1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
John Arthorne
If the line does not start if a tab our shift-tab handlers does nothing and returns to the user-agent (which run the the default handler for shift tab that moves the focus to thre previous sibling). silenio, should the editor always consume all tabs and shift-tabs events ? Note that we will need to provide a way for the user to nagivate out of the editor using the keyboard (this is an accessibility problem). To make matters worse, the ctrl+tab, is used by the user agent to switch tabs. There are two things: - It's confusing if Shift+Tab sometimes does unindent and sometimes changes focus. I think it should always consume the key. For the accessibility problem I guess we need another key like we do in the desktop - If I use whitespace instead of tabs, I still expect Shift+Tab to unindent. The desktop editor seems to be able to handle any combination of spaces and tabs. As long as there are at least 4 space characters it will unindent by removing them. I get the feeling it has an algorithm like this: If there is a tab character between start of line and first-non whitespace, remove it. Otherwise, if there are at least four spaces, remove four spaces (maybe this depends on "spaces per tab" display setting). (In reply to comment #2) > There are two things: > > - It's confusing if Shift+Tab sometimes does unindent and sometimes changes > focus. I think it should always consume the key. For the accessibility problem > I guess we need another key like we do in the desktop Ye, we should consume the shift+tab key. Carolyn, could you try to figure out what is the appropriated keys to traverse out of the editor (forwards and backwards)? Would Ctrl+Alt+Tab and Ctrl+Alt+Shift+Tab be acceptable? > - If I use whitespace instead of tabs, I still expect Shift+Tab to unindent. > The desktop editor seems to be able to handle any combination of spaces and > tabs. As long as there are at least 4 space characters it will unindent by > removing them. I get the feeling it has an algorithm like this: If there is a > tab character between start of line and first-non whitespace, remove it. > Otherwise, if there are at least four spaces, remove four spaces (maybe this > depends on "spaces per tab" display setting). We can do this, but first we need to add API to know what is the tabSize in spaces. This value is hard coded in editor features.js to 4. We need API in the textview to get (and change?) the creation options. (In reply to comment #3) > We can do this, but first we need to add API to know what is the tabSize in > spaces. This value is hard coded in editor features.js to 4. We need API in > the textview to get (and change?) the creation options. see Bug 349670 I think this support should go in editorFeatures since it is where line indent/un-indent is implemented. > Yes, we should consume the shift+tab key. Carolyn, could you try to figure > out what is the appropriate keys to traverse out of the editor (forwards > and backwards)? Would Ctrl+Alt+Tab and Ctrl+Alt+Shift+Tab be acceptable? Unfortunately, there aren't that many web-based editors out there. The ones I have tried all allow Shift+Tab to traverse out in the reverse direction. (i.e. they don't need to support any special behavior like the indent/outdent which our Eclipse users have become used to <g>). I did find one web-based editor, called CKEditor, that avoids the issue completely by not consuming tabs at all (i.e. the user cannot enter tabs into the text). The editors that do consume Tab keys (i.e. email create message) do allow Shift+Tab to traverse out backwards, but they don't seem to have a way to traverse out in the forward direction. So I have asked this question of a screen reader user that I know, and we will see what he says, although I suspect he will say that he just uses the screen reader's navigation capabilities (i.e. in JAWS, go into nav mode by typing numpad minus key, then type L to go to next link, H to go to next heading, etc. See the "Navigation Quick Keys for HTML" table on this page for an idea of how powerful the screen reader's browser navigation mode can be: http://www.freedomscientific.com/doccenter/archives/training/JAWSKeystrokes.htm). > Would Ctrl+Alt+Tab and Ctrl+Alt+Shift+Tab be acceptable?
These seem to be available in Windows XP and Mac, but unfortunately, they are consumed by Windows 7 and the Linux OS for the application switcher, so I don't think we would see them at all on those platforms.
Fixed http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=76d99e9926ac5edea1e4360bf0b6566ad21ab287 Still need to find keys to traverse out of the editor, but I will open a separate bug for this. Adding this additional comment for now. When you open the new bug, please point back to this bug. ------------------ Found another online editor called jsfiddle: http://jsfiddle.net/ They consume tabs in a similar way to our indent/outdent feature (tab indents selected lines by one tab, shift+tab outdents selected lines by one tab). They don't seem to allow tabs to be inserted in the middle of a line (but their page says they are in "alpha", so this may just be a bug... or a feature). Anyhow, one cannot use tab or shift+tab to traverse out of a jsfiddle editor once one has traversed in. I clicked on their "Keyboard shortcuts" link in the bottom left corner of the page, and they have set up the following shortcuts: * CTRL+UP/DOWN ARROW to switch editors * CTRL+SHIFT+UP ARROW to toggle the sidebar These are typically used in Windows and Linux editors and word processors for: * CTRL+UP ARROW move the insertion point to the beginning of previous line break or paragraph * CTRL+DOWN ARROW move the insertion point to the beginning of the next line break or paragraph (adding SHIFT to the above does the same, but with selection). And on Mac for: * CMD+UP ARROW go to start of document * CMD+DOWN ARROW go to end of document In Eclipse, we used them for scrolling the current line up or down. These keys seem to be currently unmapped in the Orion editor, but someone may request the Eclipse feature. I opened bug 363714. Please cc that bug if interested. |