[WK2] Crash when accessing window.localStorage after calling window.close()
https://bugs.webkit.org/show_bug.cgi?id=135328
<rdar://problem/17315237>

Reviewed by Sam Weinig.

Source/WebCore:
Fixes an issue where accessing local storage for the first time after calling window.close()
causes a crash.

For now, we should disallow accessing local storage after calling window.close() regardless of
whether it's the first access to local storage as this seems like a bad idiom to support. Note,
this represents a change in behavior from WebKit1. If such usage of window.localStorage turns
out to be reasonable then we can visit this decision again in <https://bugs.webkit.org/show_bug.cgi?id=135330>.

Tests: storage/domstorage/localstorage/access-storage-after-window-close.html
       storage/domstorage/localstorage/access-storage-then-set-value-in-storage-after-window-close.html
       storage/domstorage/localstorage/set-value-in-storage-after-window-close.html

* page/DOMWindow.cpp:
(WebCore::DOMWindow::localStorage): Modified to only return the cached local storage or
create a new local storage so long as the page isn't being closed. Also, substitute nullptr
for 0.
(WebCore::DOMWindow::close): Call Page::setIsClosing() to mark that the page is closing.
* page/Page.cpp:
(WebCore::Page::Page): Initialize m_isClosing to false.
* page/Page.h:
(WebCore::Page::setIsClosing): Added.
(WebCore::Page::isClosing): Added.

LayoutTests:
Added test by Andy Estes, LayoutTests/storage/domstorage/localstorage/access-storage-after-window-close.html,
to ensure that we don't crash when accessing local storage for the first time after calling window.close().

Additionally added tests that ensure that updates to local storage are ignored after calling
window.close() regardless of whether local storage was accessed before the call to window.close().

* storage/domstorage/localstorage/access-storage-after-window-close-expected.txt: Added.
* storage/domstorage/localstorage/access-storage-after-window-close.html: Added.
* storage/domstorage/localstorage/access-storage-then-set-value-in-storage-after-window-close-expected.txt: Added.
* storage/domstorage/localstorage/access-storage-then-set-value-in-storage-after-window-close.html: Added.
* storage/domstorage/localstorage/resources/access-storage-close-window-and-set-value-in-storage.html: Added.
* storage/domstorage/localstorage/resources/close-window-and-access-storage.html: Added.
* storage/domstorage/localstorage/resources/close-window-and-set-value-in-storage.html: Added.
* storage/domstorage/localstorage/set-value-in-storage-after-window-close-expected.txt: Added.
* storage/domstorage/localstorage/set-value-in-storage-after-window-close.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171661 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[REGRESSION][ftlopt merge][32-bit] stress/prune-multi-put-by-offset-replace-or-transition-variant.js.dfg-eager hits an assertion in SpeculativeJIT::silentSavePlanForGPR
https://bugs.webkit.org/show_bug.cgi?id=135323

Reviewed by Oliver Hunt.
        
SpeculativeJIT::silentSavePlanForGPR likes to believe that if a node is a constant,
then it's a constant that can be represented using that node's current DataFormat.
This doesn't work if the constant had been filled as a JSValue, and then one of the
fillSpeculateBlah() methods had speculated that it's of some type that the constant
isn't. Unless fillSpeculateBlah() specifically defends against this case, we'll have
a constant that claims to have a contradictory data format.
        
This patch fixes such a bug in the 32-bit fillSpeculateCell(). The 64-bit
fillSpeculateCell() appears to not have this bug, but I added a similar defense
mechanism anyway just in case, since this is one of those mistakes that keeps
reappearing.

* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171662 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Don't rely on reading applicationState from within DidEnterBackground/WillEnterForeground
https://bugs.webkit.org/show_bug.cgi?id=135329
rdar://problem/17818308

Reviewed by Sam Weinig.

API may not be stable.

* UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::isViewVisible):
    - changed to use -[WKContentView isBackground]
* UIProcess/ios/ProcessAssertionIOS.mm:
(-[WKProcessAssertionBackgroundTaskManager init]):
    - split notification handlers
(-[WKProcessAssertionBackgroundTaskManager _applicationWillEnterForeground:]):
(-[WKProcessAssertionBackgroundTaskManager _applicationDidEnterBackground:]):
(-[WKProcessAssertionBackgroundTaskManager _applicationDidEnterBackgroundOrWillEnterForeground:]): Deleted.
    - Assume application is background is after DidEnterBackground, and not after WillEnterForeground
* UIProcess/ios/WKContentView.h:
    - added isBackground.
* UIProcess/ios/WKContentView.mm:
(-[WKContentView initWithFrame:context:configuration:webView:]):
    - check applicationState at init.
(-[WKContentView isBackground]):
    - accessor
(-[WKContentView _applicationDidEnterBackground:]):
(-[WKContentView _applicationWillEnterForeground:]):
    - update isBackground



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171663 268f45cc-cd09-0410-ab3c-d52691b4dbfc