Bug 11083

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>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

abob, adele, bdakin, koivisto

Priority:

Keywords:

GoogleBug, InRadar

Version:

420+

Hardware:

Mac

OS:

OS X 10.4

Attachments:

Description	Flags
let tabs through in design mode, keep backtab behavior	darin: review-
added additional layout test for forms in design mode, no code changes	darin: review+

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-	Details Formatted Diff Diff
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+	Details Formatted Diff Diff
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.