Tab focus on editor with tabindex after the editor has been focused is wrong

[Martin Kou]

Steps to reproduce:

1. Add 6 text areas in sample.html around the script tag with document.write( CKEDITOR.samples.htmlData ); - 3 text areas before it and 3 text areas after it.
2. Added tabindex attributes to the text areas as 1,2,3,5,6,7 respectively.
3. Add tabindex="4" to the textarea in replacebyclass.html.
4. Open replacebyclass.html in Firefox or IE.
5. Select one of the text areas before the editor, press tab until the editor is focused.
6. Press tab again.
7. The text boxes after the editor are skipped.

The skipping problem occurs also for Shift-Tab.

[Martin Kou]

It seems there's no way of making tab index work normally with iframes - the browsers are treating the tab key press from inside the iframe inconsistently within themselves. It seems the only real way to fix it is that the developer tells CKEditor what element to put focus on if his user presses Tab or Shift-Tab within CKEditor.

[Martin Kou]

The solution is found to be unacceptable after talking with Senthil - they don't always know in advance what elements would come before and after the editing area. A different approach is needed.

[Martin Kou]

Turns out the logic implemented in #3098 was headed for the wrong direction.

The bug we're having now is caused by the tab focus logic implemented in the tab plugin - so it's not a browser bug as I've previously suspected. The tab plugin is actually handling ta and shift-tab events from within the editing area but it's not well integrated with the tab index fix in #3098 and so it didn't work. So the better way of handling this is - instead of adding hacks into wysiwygarea and sourcearea plugins, we should add the missing integration logic between the tabindex fix in #3098 and the tab plugin.

[Martin Kou]

Ouch, it's not working for IE.

[Martin Kou]

Ok, it's found to be a small bug in the tab plugin - domElement.setAttribute('tabindex', x) does not work in IE. It must be domElement.setAttribute('tabIndex', x);

[Frederico Caldeira Knabben]

• The custom key handled in the sourcearea plugin is not needed. You can use the editor.keytrokeHandler for that, which will give you the benefit of still having all other keys workings (like ALT+F10).

• The IE fix for tabindex should go into setAttribute, not at the origin.

• Base visibility check on styles only is not accurate, as it has no difference for children of hidden elements. There is a better way for that check.

• There are still some cases where the TAB is not moving properly (replacebycode sample, for example).

I've also noted that the tab plugin needs some review. I'm taking over this ticket as I've already worked on it while reviewing, and for urgency of it.

[Frederico Caldeira Knabben]

• This new patch also makes it possible to configure a tabindex for the editor, even if the textarea doesn't have it.

• The tab plugin has been totally reviewed.

• element::getPreviousSourceElement has been fixed as it has been ported from V2 wrongly.

[Frederico Caldeira Knabben]

Fixed with [3222].