Bug 48107 – REGRESSION: editing/spelling/context-menu-suggestions.html, spelling-backspace-between-lines.html, spelling-contenteditable.html, & spelling-textarea.html fail on Leopard

• Status: NEW
• Component: Tools / Tests

[Ryosuke Niwa]

The following tests currently fail on Leopard:

editing/spelling/context-menu-suggestions.html
editing/spelling/spelling-backspace-between-lines.html
editing/spelling/spelling-contenteditable.html
editing/spelling/spelling-textarea.html

[Ryosuke Niwa]

It appears to be these tests are flaky.  While the tests started failing during r70183-r70191, tests didn't fail on r70285 http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r70285%20(21971)/ but started failing on r70286 http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r70286%20(21972)/ even though the change was a simple rebaseline: http://trac.webkit.org/changeset/70286.

These tests have probably been flaky before r70183 but didn't show up on waterfall until now.

[Hajime Morrita]

(In reply to comment #1)
> It appears to be these tests are flaky.  While the tests started failing during r70183-r70191, tests didn't fail on r70285 http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r70285%20(21971)/ but started failing on r70286 http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r70286%20(21972)/ even though the change was a simple rebaseline: http://trac.webkit.org/changeset/70286.
> 
> These tests have probably been flaky before r70183 but didn't show up on waterfall until now.

I cannot reproduce this on my MacBook pro (with OS X 10.5.8.)
It might be fine to unskip them againt green tree and watch the bots out.

[Ryosuke Niwa]

(In reply to comment #2)
> (In reply to comment #1)
> > It appears to be these tests are flaky.  While the tests started failing during r70183-r70191, tests didn't fail on r70285 http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r70285%20(21971)/ but started failing on r70286 http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r70286%20(21972)/ even though the change was a simple rebaseline: http://trac.webkit.org/changeset/70286.
> > 
> > These tests have probably been flaky before r70183 but didn't show up on waterfall until now.
> 
> I cannot reproduce this on my MacBook pro (with OS X 10.5.8.)
> It might be fine to unskip them againt green tree and watch the bots out.

They are flaky so failure do not reproduce all the time.  See http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r70472%20(23150)/results.html for example.

[Hajime Morrita]

> They are flaky so failure do not reproduce all the time.  See http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r70472%20(23150)/results.html for example.
Hmm, interesting.
It looks that spellchecking doesn't work at all in these failure.
(I think what failed covers all our text-based spellcheck tests in LayoutTests/.)

Some configuration related trouble is possible, but I'm not sure.

[Ryosuke Niwa]

Jia said manual tests in http://trac.webkit.org/changeset/69841.  Maybe we need to move these tests to manual tests as well?  Jia, could you elaborate on why manual-tests/autocorrection/autocorrection-cancelled-by-typing-1.html had to be a manual test?

[Jia Pu]

(In reply to comment #5)
> Jia said manual tests in http://trac.webkit.org/changeset/69841.  Maybe we need to move these tests to manual tests as well?  Jia, could you elaborate on why manual-tests/autocorrection/autocorrection-cancelled-by-typing-1.html had to be a manual test?


The reason for this particular manual test is because it requires calling setTimeout() with at least 0.3. Darin said that it's probably better to be put in manual tests directory.

[Hajime Morrita]

> 
> The reason for this particular manual test is because it requires calling setTimeout() with at least 0.3. Darin said that it's probably better to be put in manual tests directory.

It makes sense that the autocorrection feature need some delay.
Thank you for your explanation!

For these failing tests, marking is done in blocking manner. So there should be another story to fail.
But ~/LibrarySpelling/ might be suspicious. 
If some buildbot has misspelled entry, the checker will not work.
I wonder if it's possible, though...

[Jia Pu]

(In reply to comment #7)
> 
> For these failing tests, marking is done in blocking manner. So there should be another story to fail.
> But ~/LibrarySpelling/ might be suspicious. 
> If some buildbot has misspelled entry, the checker will not work.
> I wonder if it's possible, though…

Don't know how buildbot is set up. But this can be verified by:
1. rm ~/Library/Spelling/*
2. kill AppleSpell.service process.