Bug 84991 – Add a test for crash in DOMSelection::deleteFromDocument

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Ryosuke Niwa]

We need a test for the bug 44153.

[Ryosuke Niwa]

Created attachment 139050 [details]
Adds a regression test

[Alexey Proskuryakov]

Comment on attachment 139050 [details]
Adds a regression test

View in context: https://bugs.webkit.org/attachment.cgi?id=139050&action=review

> LayoutTests/editing/selection/deleteFromDocument-after-document-open-crash.html:25
> +    layoutTestController.notifyDone();

This test doesn't appear to need waitUntilDone/notifyDone - all the work is done from unload.

[Ryosuke Niwa]

Comment on attachment 139050 [details]
Adds a regression test

View in context: https://bugs.webkit.org/attachment.cgi?id=139050&action=review

>> LayoutTests/editing/selection/deleteFromDocument-after-document-open-crash.html:25
>> +    layoutTestController.notifyDone();
> 
> This test doesn't appear to need waitUntilDone/notifyDone - all the work is done from unload.

document.open() sometimes ends DRT so without this, the test will be flaky.

[Alexey Proskuryakov]

> document.open() sometimes ends DRT so without this, the test will be flaky.

How can this possibly be non-deterministic? Is there an uninitialized variable somewhere?

Looks like you're covering up a real bug.

[Ryosuke Niwa]

(In reply to comment #4)
> > document.open() sometimes ends DRT so without this, the test will be flaky.
> 
> How can this possibly be non-deterministic? Is there an uninitialized variable somewhere?
> 
> Looks like you're covering up a real bug.

Maybe. The last time I checked, this was expected behavior per spec and non-determinism was due to some race conditions. But then I'm not too familiar with this area.

[Ryosuke Niwa]

Hm... it appears that this problem no longer reproduces at least on this test. I'm gonna just remove waitUntilDone/notifyDone for now.

[Ryosuke Niwa]

Committed r115360: <http://trac.webkit.org/changeset/115360>

[Alexey Proskuryakov]

> it appears that this problem no longer reproduces at least on this test

Perhaps it's more complicated when the script runs during load, as opposed to unload handler.

[Ryosuke Niwa]

(In reply to comment #8)
> > it appears that this problem no longer reproduces at least on this test
> 
> Perhaps it's more complicated when the script runs during load, as opposed to unload handler.

Hm... that's possible. I guess Chromium WebKit gardeners will notice if this test becomes flaky :)

[Alexey Proskuryakov]

> unload

onload, thank you autocorrection :)