Bug 28154 - clicking below end of text in a textarea moves cursor to wrong position
Summary: clicking below end of text in a textarea moves cursor to wrong position
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-10 10:44 PDT by Dan Winship
Modified: 2009-08-24 00:12 PDT (History)
2 users (show)

See Also:


Attachments
editingbehavior.patch (9.63 KB, patch)
2009-08-22 11:22 PDT, Xan Lopez
jmalonzo: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Winship 2009-08-10 10:44:06 PDT
in most apps (eg, normal gtk, firefox, safari), if you have a multi-line editable text thingy, and you click anywhere below the end of the text, it's equivalent to clicking at the very end of the text.

in webkitgtk though, if you click below the end of the text, it's equivalent to clicking on the last line of text *at the same X coordinate as where you clicked*.

(Of course if the text ends with a newline then there's no difference.)

This is especially annoying when trying to middle-button paste something, and instead of being pasted at the end of the line, it ends up being pasted in the middle of a word or something.
Comment 1 Xan Lopez 2009-08-22 11:22:11 PDT
Created attachment 38434 [details]
editingbehavior.patch

Turns out there's already a setting to control precisely this stuff, so just expose it and adjust our default value to be more GTK+-like.
Comment 2 Jan Alonzo 2009-08-22 13:29:44 PDT
Comment on attachment 38434 [details]
editingbehavior.patch

Hi Xan

> +WebCore::EditingBehavior core(WebKitEditingBehavior type)
> +{
> +    return (WebCore::EditingBehavior)type;

Is it possible to use c++ style casts here?

>  
> +typedef enum {
> +    WEBKIT_EDITING_BEHAVIOR_MAC,
> +    WEBKIT_EDITING_BEHAVIOR_WINDOWS
> +} WebKitEditingBehavior;

Is it possible to add a COMPILE_ASSERT for these just in case of future changes?

Thanks. r=me with those changes.
Comment 3 Xan Lopez 2009-08-22 23:37:27 PDT
Thanks, committed as r47687 with those changes.
Comment 4 Jan Alonzo 2009-08-23 04:08:52 PDT
(In reply to comment #3)
> Thanks, committed as r47687 with those changes.

This changed introduced a regression in the following test:
editing/execCommand/toggle-compound-styles.html -> failed

The change in http://trac.webkit.org/changeset/46920 might be helpful. I guess we need to rebaseline the test to match mac?
Comment 5 Xan Lopez 2009-08-24 00:12:23 PDT
(In reply to comment #4)
> (In reply to comment #3)
> > Thanks, committed as r47687 with those changes.
> 
> This changed introduced a regression in the following test:
> editing/execCommand/toggle-compound-styles.html -> failed
> 
> The change in http://trac.webkit.org/changeset/46920 might be helpful. I guess
> we need to rebaseline the test to match mac?

Yeah, I just did this and the bot is green again, thanks!