Bug 53995

Summary: editing/selection/end-of-document.html is failing in the GTK 64-bit debug bot
Product: WebKit Reporter: Mario Sanchez Prada <mario>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, eric, justin.garcia, mrobinson, webkit.review.bot, zan
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
Patch proposal none

Description Mario Sanchez Prada 2011-02-08 05:50:30 PST
This test is eventually failing on the GTK 64-bit debug bot. Last related events are:

  - It failed in SVN revisions 77916, 77917, 77918 and 77919
  - Didn't fail in SVN revision 77920 (unrelated, just skipping a test)
  - Started failing again after SVN revision 77921 (unrelated, just skipping a test)

Not sure it's a flaky test (it's been there since 2006!), perhaps it's a matter of interdependency between layout tests or something like that. Not sure, though.

This is the diff output from the log:

--- /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/editing/selection/end-of-document-expected.txt	2011-02-08 04:52:55.016867429 -0800
+++ /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/editing/selection/end-of-document-actual.txt	2011-02-08 04:52:55.016867429 -0800
@@ -1,5 +1,3 @@
-EDITING DELEGATE: shouldBeginEditingInDOMRange:range from 0 of DIV > BODY > HTML > #document to 4 of DIV > BODY > HTML > #document
-EDITING DELEGATE: webViewDidBeginEditing:WebViewDidBeginEditingNotification
 EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
 EDITING DELEGATE: shouldChangeSelectedDOMRange:range from 0 of DIV > DIV > DIV > BODY > HTML > #document to 0 of DIV > DIV > DIV > BODY > HTML > #document toDOMRange:range from 0 of #text > DIV > DIV > DIV > BODY > HTML > #document to 2 of DIV > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
 EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification


Skipping for now in the GTK platform, and CCing author of the test.
Comment 1 Mario Sanchez Prada 2011-02-08 05:57:41 PST
(In reply to comment #0)
> This test is eventually failing on the GTK 64-bit debug bot. Last related events are:
> 
>   - It failed in SVN revisions 77916, 77917, 77918 and 77919
>   - Didn't fail in SVN revision 77920 (unrelated, just skipping a test)
>   - Started failing again after SVN revision 77921 (unrelated, just skipping a test)

Sorry, this is not correct. It failed in 77921 and no longer failed after that, so perhaps it's a flaky test after all.

> Not sure it's a flaky test (it's been there since 2006!), perhaps it's a matter of interdependency between layout tests or something like that. Not sure, though.
> 
> This is the diff output from the log:
> 
> --- /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/editing/selection/end-of-document-expected.txt    2011-02-08 04:52:55.016867429 -0800
> +++ /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/editing/selection/end-of-document-actual.txt    2011-02-08 04:52:55.016867429 -0800
> @@ -1,5 +1,3 @@
> -EDITING DELEGATE: shouldBeginEditingInDOMRange:range from 0 of DIV > BODY > HTML > #document to 4 of DIV > BODY > HTML > #document
> -EDITING DELEGATE: webViewDidBeginEditing:WebViewDidBeginEditingNotification
>  EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
>  EDITING DELEGATE: shouldChangeSelectedDOMRange:range from 0 of DIV > DIV > DIV > BODY > HTML > #document to 0 of DIV > DIV > DIV > BODY > HTML > #document toDOMRange:range from 0 of #text > DIV > DIV > DIV > BODY > HTML > #document to 2 of DIV > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
>  EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
> 
> 
> Skipping for now in the GTK platform, and CCing author of the test.

As it's not actually failing now, I'm not skipping it yet.

Let's keep this bug open just in case it happens again
Comment 2 Mario Sanchez Prada 2011-02-08 09:20:55 PST
Created attachment 81649 [details]
Patch proposal

Ok, it started to fail again for builds 19094, 19095 and 19096, seems it's flaky after all, hence skipping it for the gtk platform.

IMHO, it could be a timing issue, due to trying to execute the editing commands too early in the test:

    [...]
    <script>
    function editingTest() {
        selectAllCommand();
        moveSelectionForwardByCharacterCommand();
        moveSelectionBackwardByLineCommand();
    }
    </script>

    <body>

    [...]

    <script>
    runEditingTest();
    </script>

Perhaps just calling to runEditingTest() in body.onload event could help fixing this.

Attaching patch with that little change.
Comment 3 Mario Sanchez Prada 2011-02-08 09:30:34 PST
Committed r77949: <http://trac.webkit.org/changeset/77949>
Comment 4 WebKit Review Bot 2011-02-08 10:15:22 PST
http://trac.webkit.org/changeset/77949 might have broken Qt Linux Release
The following tests are not passing:
http/tests/websocket/tests/workers/close-in-onmessage-crash.html
Comment 5 Mario Sanchez Prada 2011-02-15 08:44:36 PST
Reopened bug, as it seems it's still failing every now and then, exactly because of the very same reason as pointed out in the description of this bug:

http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r78558%20(19344)/editing/selection/end-of-document-diffs.txt

Justin, as the author of this test, do you have any idea of why could this be happening?

Thanks in advance for any feedback you could provide.
Comment 6 Ryosuke Niwa 2011-06-18 10:17:29 PDT
Comment on attachment 81649 [details]
Patch proposal

Clearing r+ from the patch so that it won't show up on the commit queue.
Comment 7 Zan Dobersek 2012-06-23 07:43:34 PDT
The test is consistently passing so its expectation was removed in http://trac.webkit.org/changeset/120476. Closing the bug.