If entering fullscreen for a window fails, don't leave things in a bad state
https://bugs.webkit.org/show_bug.cgi?id=119179
<rdar://problem/14517068>

Reviewed by Sam Weinig.

On Lion, attempting to take a video fullscreen when the Safari window is already
fullscreen can sometimes fail, and AppKit informs us via windowDidFailToEnterFullScreen:

When this happens we have to undo the work done when entering fullscreen, to
avoid leaving things in a bad state.

* UIProcess/mac/WKFullScreenWindowController.mm:
(-[WKFullScreenWindowController finishedEnterFullScreenAnimation:]):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153402 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix builds against an SDK.

* gtest/xcode/Config/FrameworkTarget.xcconfig: Ensure that gtest.framework is installed
in a location compatible with the SDK generation process.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153403 268f45cc-cd09-0410-ab3c-d52691b4dbfc
AX: VoiceOver not working with data detection page overlays
https://bugs.webkit.org/show_bug.cgi?id=118680

Reviewed by Sam Weinig.

Expose API in BundlePageOverlay so that accessibility attributes can be retrieved through the overlay.
This requires two methods in a new callback struct. One to copy the attribute names, and the other to
copy the attribute values. I've folded both parameterized and non-parameterized attribute names into one method
with a boolean to determine which one should be used. The non-parameterized attributes are not used or passed to the
overlay at this time as there are no clients with such a need.

* WebProcess/InjectedBundle/API/c/WKBundlePageOverlay.cpp:
(PageOverlayClientImpl::setAccessibilityClient):
(PageOverlayClientImpl::PageOverlayClientImpl):
(PageOverlayClientImpl::copyAccessibilityAttributeValue):
(PageOverlayClientImpl::copyAccessibilityAttributeNames):
(WKBundlePageOverlaySetAccessibilityClient):
* WebProcess/InjectedBundle/API/c/WKBundlePageOverlay.h:
* WebProcess/WebPage/PageOverlay.cpp:
(WebKit::PageOverlay::copyAccessibilityAttributeValue):
(WebKit::PageOverlay::copyAccessibilityAttributeNames):
* WebProcess/WebPage/PageOverlay.h:
(WebKit::PageOverlay::Client::copyAccessibilityAttributeValue):
(WebKit::PageOverlay::Client::copyAccessibilityAttributeNames):
(WebKit::PageOverlay::client):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::pageOverlayCopyAccessibilityAttributeValue):
(WebKit::WebPage::pageOverlayCopyAccessibilityAttributesNames):
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/mac/WKAccessibilityWebPageObject.mm:
(-[WKAccessibilityWebPageObject accessibilityParameterizedAttributeNames]):
(-[WKAccessibilityWebPageObject _convertScreenPointToWindow:]):
(-[WKAccessibilityWebPageObject accessibilityAttributeValue:forParameter:]):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153404 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make SuspendableTimer safer
https://bugs.webkit.org/show_bug.cgi?id=119127

Reviewed by Sam Weinig.

SuspendableTimer now enforces that it stays suspended until resumed (or until stopped
and started again). To ensure this, TimerBase is now a private base class, and parts of
its interface that clients use are reimplemented with suspend/resume in mind.

Derived classes are still allowed to override TimerBase virtual functions (notably
fired() and alignedFireTime()).

* dom/DocumentEventQueue.cpp:
(WebCore::DocumentEventQueueTimer): Removed an extraneous WTF_MAKE_NONCOPYABLE,
TimerBase has it already.
(WebCore::DocumentEventQueueTimer::create): Use our normal create() pattern.
(WebCore::DocumentEventQueue::DocumentEventQueue): Made the constructor private, accordingly.
(WebCore::DocumentEventQueue::cancelEvent): Use SuspendableTimer::cancel(), which
is a new name to disambiguate TimerBase::stop() and ActiveDOMObject::stop().
(WebCore::DocumentEventQueue::close): Ditto.

* page/DOMTimer.cpp:
(WebCore::DOMTimer::fired): Now that SuspendableTimer knows whether it's currently
suspended, assert that it's not.
(WebCore::DOMTimer::didStop): Separated ActiveDOMObject::stop() implementation from
additional cleanup, allowing for better SuspendableTimer encapsulation.

* page/DOMTimer.h: Added FINAL and OVVERIDE specifiers as appropriate.

* page/SuspendableTimer.h: Added FINAL (and OVERRIDE) qualifiers to ActiveDOMObject
methods. A derived class that wants to override current behavior is most likely not
a timer, and thus shouldn't be a derived class.
(WebCore::SuspendableTimer::isActive): SuspendableTimer with a next fire time is
active even if suspended, we shouldn't overwrite its saved data thinking that it's
inactive.
(WebCore::SuspendableTimer::isSuspended): Exposed to clients (m_suspended is no
longer debug only).

* page/SuspendableTimer.cpp:
(WebCore::SuspendableTimer::SuspendableTimer): Updated for new variable names.
(WebCore::SuspendableTimer::stop): This is ActiveDOMObject::stop(), which is called
before final destruction. We don't track this state directly, but can approximate
with setting m_suspended, so even if someone tries to start the timer afterwards,
it won't fire.
(WebCore::SuspendableTimer::suspend): Updated for new names.
(WebCore::SuspendableTimer::resume): Ditto.
(WebCore::SuspendableTimer::didStop): No-op default implementation for client hook.
(WebCore::SuspendableTimer::cancel): Equivalent of TimerBase::stop(), which also
works when suspended.
(WebCore::SuspendableTimer::startRepeating): Replacement for TimerBase function with
the same name, which works correctly when suspended. We don't want to actually start
the timer in this case.
(WebCore::SuspendableTimer::startOneShot): Ditto.
(WebCore::SuspendableTimer::repeatInterval): Ditto.
(WebCore::SuspendableTimer::augmentFireInterval): Ditto.
(WebCore::SuspendableTimer::augmentRepeatInterval): Ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153406 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HTMLParserScheduler gets into an inconsistent state when suspended for reasons
other than WillDeferLoading
https://bugs.webkit.org/show_bug.cgi?id=119172

Reviewed by Sam Weinig.

When loading is not deferred, even a suspended parser will be processing new data
from network, potentially starting its next chunk timer.

Limit suspending to when we can actually enforce it.

Here is what happens for each ReasonForSuspension:
- JavaScriptDebuggerPaused: continuing to parse is probably wrong, but in practice,
this is unlikely to happen while debugging, and wasn't properly prevented before
this patch anyway.
- WillDeferLoading: No change in behavior.
- DocumentWillBecomeInactive: This is about page cache, and documents are only allowed
to be cached when fully loaded.
- PageWillBeSuspended: This appears to be part of Frame::suspendActiveDOMObjectsAndAnimations()
implementation, I'm guessing that it is appropriate to continue loading.

* dom/Document.cpp:
(WebCore::Document::suspendScheduledTasks):
(WebCore::Document::resumeScheduledTasks):
Only suspend/resume parsing when loading is deferred. This is not expressed directly,
but it's important to do this to avoid executing JS behind alerts and other modal dialogs.

* html/parser/HTMLParserScheduler.h: Added m_suspended member variable for assertions.

* html/parser/HTMLParserScheduler.cpp:
(WebCore::HTMLParserScheduler::HTMLParserScheduler):
(WebCore::HTMLParserScheduler::continueNextChunkTimerFired):
(WebCore::HTMLParserScheduler::scheduleForResume):
(WebCore::HTMLParserScheduler::suspend):
(WebCore::HTMLParserScheduler::resume):
Update m_suspended and assert as appropriate. No behavior changes for release mode.

* page/Frame.cpp: (WebCore::Frame::suspendActiveDOMObjectsAndAnimations):
Added a FIXME.


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