Summary: With caret placed in document body, pressing the Tab key doesn't move the caret on the current line Steps to Reproduce: 1) With TOT Webkit r16622, login into writely.com 2) Create a new document ( Click New link) 3) Place caret in document body then press the Tab key 4) Notice the caret is not advanced in message body but instead focus moves to the Title field Expected Results: The caret should advance a extra space on the current line but doesn't
This issue is covered in <rdar://problem/4757650>
This is not specific to Google Docs. It is a recent regression that effects any editable region.
11/6/06 7:36 AM David Harrison: This actually the expected behavior in a browser. FireFox does the same thing. Browsers are different from email clients in this way. 3/7/07 12:35 AM Adele Peterson: While its true that this is expected behavior in regular editable regions, it seems that Google Docs is doing something special here to insert the tab - probably using an event handler. In Firefox, a tab is actually inserted in this specific page.
This isn't how other browsers behave. Open this in FF: <body><script>document.designMode="on";</script></body> Click inside the body and press tab. A tab is inserted.
Created attachment 13592 [details] let tabs through in design mode, keep backtab behavior
Comment on attachment 13592 [details] let tabs through in design mode, keep backtab behavior I'm not sure this is correct. I think that tabs in form elements in design mode should behave as they normally do. On the other hand, I don't think that's an important case and I really don't understand much about the behavior of form elements in a design mode document at all. But this needs a layout test. So, review- until we have a layout test.
I think the patch should allow tab insertion at any editable selection, not just those in designMode documents. Use m_frame->selectionController()->isContentEditable().
(In reply to comment #6) > (From update of attachment 13592 [details] [edit]) > I'm not sure this is correct. I think that tabs in form elements in design mode > should behave as they normally do. On the other hand, I don't think that's an > important case and I really don't understand much about the behavior of form > elements in a design mode document at all. According to 12257, form elements in editable regions shouldn't be active, so eventually we won't have to worry about this case because we won't allow those types of selections.
I disagree that we want to allow tab insertion at any editable selection. We definitely want to retain the ability to tab into and out of form controls.
I don't know if GMail has changed or something, but now in Firefox, I can no longer insert tabs in a a GMail message.
> I disagree that we want to allow tab insertion at any editable selection. We > definitely want to retain the ability to tab into and out of form controls. Oops right. Any editable selection that's not inside a form element.
Firefox allows entering tab character in designMode (and does not support contentEditable) IE does not allow entering tab character in designMode or contentEditable regions. Whether or not allow tabs in contentEditable is a separate issue from this bug, I think. Current behavior matches IE there.
Created attachment 13612 [details] added additional layout test for forms in design mode, no code changes I think what should be done with form elements in designMode (Firefox disables them completely) or what to do with tabs in contentEditable (enabling tab insertion there would disable tabbing between them, arguably a regression) are outside scope of this bug, so no code changes.
Comment on attachment 13612 [details] added additional layout test for forms in design mode, no code changes Index: LayoutTests/editing/inserting/typing-tab-designmode-expected.txt The expected result for this test is identical to the result it produces in TOT. Is that intentional?
Comment on attachment 13612 [details] added additional layout test for forms in design mode, no code changes r=me, although I think the back-tab behavior is kinda wierd
Commited as r20159 Back tab thing sort of makes sense if you try it in Docs. You can still get out of the editing area.