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: | P2 | Keywords: | GoogleBug, InRadar | ||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
Chris Petersen
2006-09-29 08:24:49 PDT
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. |