A quick fix for Issue 18708....

A quick fix for Issue 18708.
This issue is caused by our WebKit API code that treats the control+enter keys as a keypress of character '\r'.
Both IE and Firefox treat control+enter keys as a keypress of character '\n'. Google Spreadsheet inserts one line-break for character '\n' and two line-breaks for character '\r'.
To solve this issue, this change emulates the above behavior of IE and Firefox.

BUG=18708
"CTRL+enter within a cell inserts two linebreaks"
TEST=Type control+enter keys in Google Spreadsheet, and see it inserts only one line-break.

[Evan Stade, 2009-08-07 18:09:40]

Really do not feel qualified to review this, but I wonder what they do on
windows chrome?

can you take a look Darin?

[darin (slow to review), 2009-08-10 06:20:44]

Provided this matches Windows Chrome behavior, I'm fine with it.  Otherwise,
should we also change Windows Chrome?

[Hironori Bono, 2009-08-10 07:35:25]

Thank you for your comments.

To write from a conclusion, Windows Chrome also sends a keypress event whose
keyCode is 0x0A ('\n') when we type control+enter keys and this change is for
matching the behavior of Windows Chrome.

For what it's worth, this key-code issue is caused by a design of Windows, i.e.
Windows sends a WM_CHAR message whose parameter is 0x0A when we type
control+enter keys. So, as far as I tested with a test page of Google Web
Toolkit <http://www.danilatos.com/event-test/ExperimentTest.html>, Windows
browsers (IE, Firefox, and Safari) send a keypress event whose keyCode is 0x0A
('\n') when we type control+enter keys.
on the other hand, Linux firefox sends a keypress event whose keyCode is 0x0D
('\r') when we type control+enter keys because GTK sends 0x0D ('\r') when typing
control+enter keys.

Even though it is always a difficult question which browser (Windows Chrome or
Linux Firefox) Linux Chrome should follow for such situation, this change
follows the behavior of Windows Chrome since Google Docs and Spreadsheet depend
on it. (Nevertheless, if Spreadsheet fix this issue before we fix it, this
change doesn't make much sense.)

Regards,

Hironori Bono

On 2009/08/10 06:20:44, darin wrote:
> Provided this matches Windows Chrome behavior, I'm fine with it.  Otherwise,
> should we also change Windows Chrome?

[darin (slow to review), 2009-08-10 18:08:41]

Thanks for the details.  Matching Window Chrome sounds good to me.  Docs +
Spreadsheets may not be the only web sites impacted.-Darin


On Mon, Aug 10, 2009 at 12:35 AM, <hbono@chromium.org> wrote:

> Thank you for your comments.
>
> To write from a conclusion, Windows Chrome also sends a keypress event
> whose keyCode is 0x0A ('\n') when we type control+enter keys and this
> change is for matching the behavior of Windows Chrome.
>
> For what it's worth, this key-code issue is caused by a design of
> Windows, i.e. Windows sends a WM_CHAR message whose parameter is 0x0A
> when we type control+enter keys. So, as far as I tested with a test page
> of Google Web Toolkit
> <http://www.danilatos.com/event-test/ExperimentTest.html>, Windows
> browsers (IE, Firefox, and Safari) send a keypress event whose keyCode
> is 0x0A ('\n') when we type control+enter keys.
> on the other hand, Linux firefox sends a keypress event whose keyCode is
> 0x0D ('\r') when we type control+enter keys because GTK sends 0x0D
> ('\r') when typing control+enter keys.
>
> Even though it is always a difficult question which browser (Windows
> Chrome or Linux Firefox) Linux Chrome should follow for such situation,
> this change follows the behavior of Windows Chrome since Google Docs and
> Spreadsheet depend on it. (Nevertheless, if Spreadsheet fix this issue
> before we fix it, this change doesn't make much sense.)
>
> Regards,
>
> Hironori Bono
>
>
> On 2009/08/10 06:20:44, darin wrote:
>
>> Provided this matches Windows Chrome behavior, I'm fine with it.
>>
> Otherwise,
>
>> should we also change Windows Chrome?
>>
>
>
>
> http://codereview.chromium.org/164139
>