|Summary:||REGRESSION: Typing tab key fails to insert a tab character in Google Docs editable area|
|Product:||WebKit||Reporter:||Chris Petersen <c.petersen87>|
|Component:||HTML Editing||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||abob, adele, bdakin, koivisto|
|OS:||OS X 10.4|
Description Chris Petersen 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
Comment 2 Justin Garcia 2006-10-20 13:38:11 PDT
This is not specific to Google Docs. It is a recent regression that effects any editable region.
Comment 3 Adele Peterson 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.
Comment 4 Justin Garcia 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.
Comment 5 Antti Koivisto 2007-03-12 08:23:26 PDT
Created attachment 13592 [details] let tabs through in design mode, keep backtab behavior
Comment 6 Darin Adler 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.
Comment 7 Justin Garcia 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().
Comment 8 Justin Garcia 2007-03-12 13:06:40 PDT
(In reply to comment #6) > (From update of attachment 13592 [details] ) > 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.
Comment 9 Adele Peterson 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.
Comment 10 Adele Peterson 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.
Comment 11 Justin Garcia 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.
Comment 12 Antti Koivisto 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.
Comment 13 Antti Koivisto 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.
Comment 14 mitz 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?
Comment 15 Darin Adler 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