[Webkit-unassigned] [Bug 51357] REGRESSION (r66428/r71892): Crash after assertion failure (!m_reachedTerminalState) in ResourceLoader::didCancel()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=51357





--- Comment #15 from Adam Barth <abarth at webkit.org>  2011-03-08 12:28:16 PST ---
> Based on previous patches around window.print(), it's not supported by the DRT, so I'm not sure this layout test is actually testing anything:

I'll try running it without the patch to check.

> There is no need to call stop before start on a Timer. Calling any version of start automatically cancels any previously-scheduler timer as stop does.

Ok.  I was modeling this off other code that does this, but that code is probably confused.

> What will this do if window.close() is called right after window.print()? It's pretty common for Web pages to call window.open()/print()/close() in one script. I'm not sure if a timer will result in correct behavior.

That's the test case for this bug.  It seems to fix the problem.

> Please also try less practical variations of this (e.g. setTimeout("window.close()", 0); calling window.close() before window.print(); opening a separate window or not; testing whether the whole page actually gets parsed before printing). I've been getting some crashes and assertion failures even without your patch - although my build is old, and some may have been fixed.

Hum...  I'm not entirely sure what you have in mind here.  The issue in this bug is that calling DOMWindow::print synchronously from inside a load cancel spins an event loop and leaves the loader in an inconsistent state.  This patch just makes the call async so we don't spin an event loop inside the cancel handler.

Do you mean there are other bugs we should try to address at the same time?

> Also, interaction with any work performed in onload could cause incompatibilities, perhaps even practical ones.

That's certainly possible.  Do you have a suggestion for another approach to fixing this bug?  We might want to try the fix and see if we have compat problems.

> It seems like we're adding layers of patches without fully understanding what other browsers do, and without support from HTML5. Unsurprisingly, this hasn't worked so well.

I definitely get that sense too.  Unfortunately, we don't even seem to have good test coverage of the changes we're making.  I certainly don't have global understanding of how this all should work...  How do you think we should proceed?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.