RESOLVED FIXED 11083
REGRESSION: Typing tab key fails to insert a tab character in Google Docs editable area 
https://bugs.webkit.org/show_bug.cgi?id=11083
Summary REGRESSION: Typing tab key fails to insert a tab character in Google Docs edi...
Chris Petersen
Reported 2006-09-29 08:24:49 PDT
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
Attachments
let tabs through in design mode, keep backtab behavior (3.16 KB, patch)
2007-03-12 08:23 PDT, Antti Koivisto 		darin: review-
DetailsFormatted DiffDiff
added additional layout test for forms in design mode, no code changes (17.85 KB, patch)
2007-03-13 09:02 PDT, Antti Koivisto 		darin: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Chris Petersen
Comment 1 2006-09-29 11:16:45 PDT
This issue is covered in <rdar://problem/4757650>
Justin Garcia
Comment 2 2006-10-20 13:38:11 PDT
This is not specific to Google Docs. It is a recent regression that effects any editable region.
Adele Peterson
Comment 3 2007-03-07 00:45:59 PST
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.
Justin Garcia
Comment 4 2007-03-07 15:07:54 PST
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.
Antti Koivisto
Comment 5 2007-03-12 08:23:26 PDT
Created attachment 13592 [details] let tabs through in design mode, keep backtab behavior
Darin Adler
Comment 6 2007-03-12 08:28:57 PDT
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.
Justin Garcia
Comment 7 2007-03-12 13:01:54 PDT
I think the patch should allow tab insertion at any editable selection, not just those in designMode documents. Use m_frame->selectionController()->isContentEditable().
Justin Garcia
Comment 8 2007-03-12 13:06:40 PDT
(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.
Adele Peterson
Comment 9 2007-03-12 13:33:34 PDT
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.
Adele Peterson
Comment 10 2007-03-12 13:43:23 PDT
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.
Justin Garcia
Comment 11 2007-03-12 14:17:41 PDT
> 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.
Antti Koivisto
Comment 12 2007-03-12 15:49:07 PDT
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.
Antti Koivisto
Comment 13 2007-03-13 09:02:32 PDT
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.
mitz
Comment 14 2007-03-13 09:14:47 PDT
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?
Darin Adler
Comment 15 2007-03-13 10:11:27 PDT
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
Antti Koivisto
Comment 16 2007-03-13 14:59:38 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.