[webkit-reviews] review canceled: [Bug 67074] REGRESSION (r93913): Failures in fast/replaced/frame-removed-during-resize.html and scrollbars/scrollable-iframe-remove-crash.html : [Attachment 105555] Patch

[bugzilla-daemon at webkit.org]

Dmitry Titov <dimich at chromium.org> has canceled Dmitry Titov
<dimich at chromium.org>'s request for review:
Bug 67074: REGRESSION (r93913): Failures in
fast/replaced/frame-removed-during-resize.html and
scrollbars/scrollable-iframe-remove-crash.html
https://bugs.webkit.org/show_bug.cgi?id=67074

Attachment 105555: Patch
https://bugs.webkit.org/attachment.cgi?id=105555&action=review

------- Additional Comments from Dmitry Titov <dimich at chromium.org>
Thanks! Renamed the method.

Here is more info on what exactly caused the crashes: The EventQueue contains a
loop that processes all the accumulated events. Now with the r93913 landed, the
Frame may be destroyed upon exiting from event dispatch. This may immediately
queue more events  (Frame::setSelection() in this case, clearing the frame's
selection state) - and the new events would be processed on the next loop
iteration, while the timer which is started when new event is enqued would be
not reset. Next time the timer fires we get an empty queue (because the event
was actually processed before) and ASSERT fires.

Instead of removing ASSERT and say it's ok when events enque other events (this
apparently started to happen after r93913), I think we can stop accepting new
events after EventQueue was explicitly 'stopped', which is a good thing to do
anyways. That covers the cases of failing tests and still keeps ASSERT in place
so we can find out what other events can cause new events to be added.