Bug 153747 - REGRESSION(r195949): [GTK] Test /webkit2/WebKitWebView/insert/link is failing since r195949
Summary: REGRESSION(r195949): [GTK] Test /webkit2/WebKitWebView/insert/link is failing...
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Keywords: Gtk, Regression
Depends on:
Reported: 2016-02-01 09:36 PST by Carlos Garcia Campos
Modified: 2016-02-24 02:41 PST (History)
4 users (show)

See Also:

Test (772 bytes, text/html)
2016-02-10 00:48 PST, Carlos Garcia Campos
no flags Details
Makes the test pass (690 bytes, patch)
2016-02-16 11:23 PST, Adrien Plazas
mcatanzaro: review-
Details | Formatted Diff | Diff
Test case as a patch (2.04 KB, patch)
2016-02-22 05:08 PST, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff
Patch (5.54 KB, patch)
2016-02-22 06:09 PST, Carlos Garcia Campos
mcatanzaro: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2016-02-01 09:36:02 PST
/webkit2/WebKitWebView/insert/link:                                  **

ERROR:../../Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestWebViewEditor.cpp:445:void testWebViewEditorCreateLink(EditorTest*, gconstpointer): assertion failed: (javascriptResult)


I haven't had time to investigate this yet, just noticed it in the bots.
Comment 1 Carlos Garcia Campos 2016-02-09 04:06:28 PST
Ok, what r195949 broke is MoveToEndOfLine and MoveToBeginningOfLine editing command when there's only one word and it's selected. It can be reproduced using any input field:

1. Write a single world
2. Select it entirely from left to right to ensure the cursor is at the end of the word. Double clicking should also work.
3. Press End key

The selection should be cleared, but it's not. Same happens if you select the word from right to left and press the Start key. So, my guess is that when the cursor is already at the desired position, it does nothing. I'm not sure if this happens in mac too, or depends on the editor behavior, so I'm leaving this as GTK specific for now, could someone confirm?
Comment 2 Darin Adler 2016-02-09 09:13:44 PST
On Mac it is Control-Right-Arrow, not End. The “End key moves cursor to the end of line” behavior comes from Windows; on Mac the End key scrolls to the end of the document and does not move the cursor. Also, this particular keyboard command is overridden by Mission Control by default in recent versions of Mac, so you have to turn off Mission Control’s "Move right a space" key binding in System Preferences Keyboard Shortcuts to test it.

I tried to reproduce this with the local copy of Safari with the latest WebKit that I built and I could not reproduce the bug on Mac; it seemed to work fine. Might have done the testing wrong.
Comment 3 Carlos Garcia Campos 2016-02-10 00:48:30 PST
Created attachment 270981 [details]

Thanks for looking at this, Darin. I've written a test that fails with current trunk and passes with r195949 reverted, at least for the GTK+ port. It should be copied to LayoutTests/editing/selection.
Comment 4 Adrien Plazas 2016-02-16 11:23:30 PST
Created attachment 271455 [details]
Makes the test pass

DISCLAIMER: This is very probably not the right thing to do, it makes the test pass though.
Comment 5 Adrien Plazas 2016-02-17 00:36:58 PST
The problem seems to be caused by FrameSelection::modify() returning too early (in the added section) and hence not performing the switch (alter) {...} bloc.
Comment 6 Adrien Plazas 2016-02-17 00:44:14 PST
I'm not sure how to fix this properly though, any help is welcome.
Comment 7 Doug Russell 2016-02-17 10:36:41 PST
In the event that shouldNotify is true and the early return would kick in, I'd expect the position to be isNull() == true and the code path would have bailed early on the follow isNull() check, but if you have a case where that's not true, we should be able to adjust accordingly. Probably by moving the if (shouldNotify...) farther down when position isn't null.
Comment 8 Michael Catanzaro 2016-02-20 07:41:51 PST
Comment on attachment 271455 [details]
Makes the test pass

I think this requires further investigation.
Comment 9 Carlos Garcia Campos 2016-02-22 05:02:56 PST
The thing is why we are returning early in case of notifying the AT about the selection change. I guess we are assuming that reaching a boundary means that there won't be a selection change. Also, why aren't we also notifying when reaching a boundary in case of character granularity?
Comment 10 Carlos Garcia Campos 2016-02-22 05:08:34 PST
Created attachment 271916 [details]
Test case as a patch

Just to check Mac behavior in EWS.
Comment 11 Carlos Garcia Campos 2016-02-22 06:03:33 PST
Ok, so it seems to pass in Mac, I don't understand why, though.
Comment 12 Carlos Garcia Campos 2016-02-22 06:09:00 PST
Created attachment 271920 [details]

This patch fixes the problem for GTK+, and hopefully doesn't break Mac.
Comment 13 Doug Russell 2016-02-22 10:20:32 PST
This change looks sensible and as long it doesn't break the mac tests I'm on board.
Comment 14 Michael Catanzaro 2016-02-22 12:06:29 PST
Comment on attachment 271920 [details]

OK then, I was waiting for Doug to comment. :)

Thanks for the investigation, Adrian!
Comment 15 Carlos Garcia Campos 2016-02-24 02:41:15 PST
Committed r197024: <http://trac.webkit.org/changeset/197024>