In WebView::closeWindowSoon() (WebView.cpp) m_closeWindowTimer is set to a timer, unless it’s already non-zero, in which case the function immediately returns.
Since m_closeWindowTimer is never set back to zero (even after the timer has fired), it means that if the HTML calls window.close() and the UI delegate decides not to dispose the web view, then any future call to window.close() will be a no-op.
A fix is likely to let WebView::closeWindowTimerFired() set “m_closeWindowTimer = 0;” (WebView.cpp)
Allan, would you be willing to submit a patch with a fix? Please see <http://www.webkit.org/coding/contributing.html> for some pointers and guidelines.
Changing platform from Mac to Windows, as the quoted code is in Windows WebKit.
Created attachment 213159 [details]
Fix missing zeroing of timer
It should be a one line change which I attached a patch for.
I didn’t do any changelog, run tests, etc. as I do not have a build environment for WebKit. I ran into the issue working with the system’s standard WebView on OS X 10.8.4 and read through the source of WebKit to figure out why it didn’t behave as expected.
Disregard that patch, it leaks the timer.
Created attachment 213161 [details]
Fix missing zeroing of timer (2)
This deletes the timer and replaces the previous patch.
The patch is not marked for review, and doesn't have a ChangeLog.
While we are grateful for a contribution in any form, following the normal process can make it move faster.
As I am unfamiliar with your normal process and does not have a WebKit build environment (the patch was submitted only because it was requested from me), I would be grateful if someone else can follow the required steps to get this bug fixed.