WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
53995
editing/selection/end-of-document.html is failing in the GTK 64-bit debug bot
https://bugs.webkit.org/show_bug.cgi?id=53995
Summary
editing/selection/end-of-document.html is failing in the GTK 64-bit debug bot
Mario Sanchez Prada
Reported
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.
Attachments
Patch proposal
(2.43 KB, patch)
2011-02-08 09:20 PST
,
Mario Sanchez Prada
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Mario Sanchez Prada
Comment 1
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
Mario Sanchez Prada
Comment 2
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.
Mario Sanchez Prada
Comment 3
2011-02-08 09:30:34 PST
Committed
r77949
: <
http://trac.webkit.org/changeset/77949
>
WebKit Review Bot
Comment 4
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
Mario Sanchez Prada
Comment 5
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.
Ryosuke Niwa
Comment 6
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.
Zan Dobersek
Comment 7
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug