Bug 36141 – Fix webkit win test failures for smart delete

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Ojan Vafai]

fix webkit win test failures for smart delete

[Ojan Vafai]

Created attachment 50743 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 50743 [details]
Patch

Is doubleClickAtSelectionStart() used in any other tests? Does it misbehave in those? Would it be a good idea to change it instead, adding 1 pixel to coordinates?

I was going to say r=me, but then realized that I don't understand why Mac test results changed.

[Ojan Vafai]

(In reply to comment #2)
> (From update of attachment 50743 [details])
> Is doubleClickAtSelectionStart() used in any other tests?

Yes.

> Does it misbehave in those?

Doesn't seem to. I haven't dug enough to really understand what the underlying issue is, so it's hard to say whether all cases of doubleClickAtSelectionStart could have this problem.

> Would it be a good idea to change it instead, adding 1 pixel to
> coordinates?

I can certainly do that. I considered it, but it seemed a bit strange given that a collapsed selection is zero-width. In either case, I was going for the minimal change that would green the tree.

> I was going to say r=me, but then realized that I don't understand why Mac test
> results changed.

Yeah, it took me a minute to make sense of that as well. I'm pretty sure what's happening is that the initial click of the double click is now moving the selection and the second click is selecting the word. Before, the initial click was in the same place as the caret, so there was no selection change.

[Alexey Proskuryakov]

Comment on attachment 50743 [details]
Patch

Oh, that's an unfortunate limitation of eventSender.

> I can certainly do that. I considered it, but it seemed a bit strange given
> that a collapsed selection is zero-width.

Yes - but that can only applied to non-collapsed selections.

[Ojan Vafai]

Committed r56089: <http://trac.webkit.org/changeset/56089>