Build fix.

* UIProcess/API/APILoaderClient.h:
(API::LoaderClient::didDestroyNavigation):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170673 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash in WebDocumentLoader::setNavigationID
https://bugs.webkit.org/show_bug.cgi?id=134520

Reviewed by Anders Carlsson.

* WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::didReceivePolicyDecision): Null-check the policy document loader.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170674 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] Subsampled JPEG images do not draw correctly via the canvas APIs
https://bugs.webkit.org/show_bug.cgi?id=134513
<rdar://problem/12078860>
<rdar://problem/16745393>

Reviewed by Tim Horton.

Source/WebCore:
Subsampled images (e.g. JPEG) were not consistently using
their original dimensions and subsampled dimensions. This caused
things like texImage2D to pack the pixels incorrectly, or drawImage
to squish the rendering.

Renamed m_scale to m_subsamplingScale on FrameData.

Tests: fast/canvas/image-potential-subsample.html
       fast/canvas/webgl/tex-image-and-sub-image-2d-with-potentially-subsampled-image.html

* platform/graphics/BitmapImage.cpp:
(WebCore::BitmapImage::cacheFrame): Rename to m_subsamplingScale.
(WebCore::BitmapImage::frameAtIndex): Ditto.
* platform/graphics/BitmapImage.h:
(WebCore::FrameData::FrameData): Ditto.
* platform/graphics/cg/BitmapImageCG.cpp:
(WebCore::FrameData::clear): Ditto.
(WebCore::BitmapImage::BitmapImage): Ditto.
(WebCore::BitmapImage::draw): Use a scaledSrcRect that reflects the subsampled size,
rather than assuming the srcRect accurately reflects how many pixels we have
in the Bitmap.
(WebCore::BitmapImage::copyUnscaledFrameAtIndex):
* platform/graphics/cg/GraphicsContext3DCG.cpp:
(WebCore::GraphicsContext3D::ImageExtractor::extractImage): Similar fix, although this
time we just ask the image decoder to take into account the subsampled size
when it is "generating" a frame, causing it to use the bitmap data it has already
decoded.

LayoutTests:
Add Canvas2D and WebGL tests that exercise a very large JPEG image.

The WebGL test is mostly copied from the WebGL test suite, so please
excuse the coding style.

* fast/canvas/image-potential-subsample-expected.txt: Added.
* fast/canvas/image-potential-subsample.html: Added.
* fast/canvas/resources/image-8000x8000.jpg: Added.
* fast/canvas/webgl/resources/tex-image-and-sub-image-2d-with-potentially-subsampled-image.js: Added.
(.init):
(.runOneIteration):
(.runTestOnImage):
(.runTest):
(generateTest):
* fast/canvas/webgl/tex-image-and-sub-image-2d-with-potentially-subsampled-image-expected.txt: Added.
* fast/canvas/webgl/tex-image-and-sub-image-2d-with-potentially-subsampled-image.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170675 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. EFL and GTK build fix since r170654.

* UIProcess/LegacySessionStateCodingNone.cpp: Add a dummy encodeLegacySessionState(const SessionState&).
(WebKit::encodeLegacySessionState):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170676 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Debugger's breakpoint list should not be a Vector.
<https://webkit.org/b/134514>

Reviewed by Geoffrey Garen.

The debugger currently stores breakpoint data as entries in a Vector (see
BreakpointsInLine).  It also keeps a fast map look up of breakpoint IDs to
the breakpoint data (see m_breakpointIDToBreakpoint).  Because a Vector can
compact or reallocate its backing store, this can causes all sorts of havoc.
The m_breakpointIDToBreakpoint map assumes that the breakpoint data doesn't
move in memory.

The fix is to replace the BreakpointsInLine Vector with a BreakpointsList
doubly linked list.

* debugger/Breakpoint.h:
(JSC::Breakpoint::Breakpoint):
(JSC::BreakpointsList::~BreakpointsList):
* debugger/Debugger.cpp:
(JSC::Debugger::setBreakpoint):
(JSC::Debugger::removeBreakpoint):
(JSC::Debugger::hasBreakpoint):
* debugger/Debugger.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170677 268f45cc-cd09-0410-ab3c-d52691b4dbfc
AX: iOS does not expose ARIA toggle buttons at all (not even as a regular button)
https://bugs.webkit.org/show_bug.cgi?id=133875

Reviewed by Enrica Casucci.

Source/WebCore:
Support the toggle button type in iOS.

Test: platform/ios-sim/accessibility/toggle-button.html

* accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:
(-[WebAccessibilityObjectWrapper accessibilityCanFuzzyHitTest]):
(-[WebAccessibilityObjectWrapper accessibilityTraits]):
(-[WebAccessibilityObjectWrapper determineIsAccessibilityElement]):

LayoutTests:
* platform/ios-sim/accessibility/toggle-button-expected.txt: Added.
* platform/ios-sim/accessibility/toggle-button.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170678 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WKPageRestoreFromSessionState should use the new session state restore code path
https://bugs.webkit.org/show_bug.cgi?id=134526

Reviewed by Tim Horton.

* UIProcess/API/C/WKPage.cpp:
(WKPageRestoreFromSessionState):
Use the new code path.

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::restoreFromState):
Only restore the back-forward state if we have a back-forward list.

* UIProcess/mac/LegacySessionStateCoding.cpp:
(WebKit::encodeSessionHistory):
Save the original URL string as well.

(WebKit::decodeV1SessionHistory):
If we don't have a current index, set it to Nullopt instead of 0.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170679 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: Hexadecimal color values in all CSS editors are purple when they should be blue
https://bugs.webkit.org/show_bug.cgi?id=133997

Reviewed by Joseph Pecoraro.

CodeMirror 4 removed the style for hex colors from the CSS tokenizer.
Feature has been added to CodeMirrorAdditions.js.

* UserInterface/Views/CodeMirrorAdditions.js: Added hex-color to style for a valid hexadecimal color.
* UserInterface/Views/SyntaxHighlightingDefaultTheme.css: Added selector for hexadecimal color.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170681 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WebGL] Fix PVRTC extension.
https://bugs.webkit.org/show_bug.cgi?id=134525

Patch by Alex Christensen <achristensen@webkit.org> on 2014-07-01
Reviewed by Dean Jackson.

* html/canvas/WebGLRenderingContext.cpp:
(WebCore::WebGLRenderingContext::validateCompressedTexDimensions):
Remove the return false which I mistakenly committed in r170128
and make the gl error match the S3TC error and the khronos test.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170682 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add ABI hacks to allow WKPageRef to use WKSessionStateRef
https://bugs.webkit.org/show_bug.cgi?id=134529

Reviewed by Sam Weinig.

* UIProcess/API/APISessionState.h:
Add a sessionState() getter.

* UIProcess/API/C/WKPage.cpp:
(WKPageCopySessionState):
Add a hack where we return a WKSessionStateRef if the least significant bit of the context pointer
is 1, and a WKDataRef otherwise.

(WKPageRestoreFromSessionState):
Handle both WKDataRef and WKSessionStateref.

* UIProcess/API/C/WKPage.h:
Use WKTypeRefs for state saving and restoration.

* UIProcess/API/C/WKSessionStateRef.cpp:
(WKSessionStateCopyData):
Add helper function.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS][WK2] Fix a race between the short tap and long tap highlight
https://bugs.webkit.org/show_bug.cgi?id=134530

Reviewed by Enrica Casucci.

There was a potential race of event that can theoretically cause WKContentViewInteraction
to call [WKContentView _showTapHighlight] after all interactions have been cancelled.

The race would be like this:
1) On a short tap, _singleTapRecognized: is called, a tap highlight ID is defined and
   _potentialTapInProgress is set to YES.
2) For some reason, the gesture is cancelled. The method _singleTapDidReset is called, 
   setting _potentialTapInProgress but leaving the tap highlight ID as valid.
3) The UIProcess receives the tap highlight information from the WebProcess, _didGetTapHighlightForRequest:
   has a valid ID, _potentialTapInProgress is false -> the highlight is shown right away as if a long tap
   was in progress.

The missing piece that causes this is _singleTapDidReset: must also invalidate the tap highlight ID. This is done
in the new static function cancelPotentialTapIfNecessary().

Just invalidating the ID would create another race:
1) Short tap gesture recognizer starts.
2) The long press recognizer starts before (1) is commited.
3) The long press recognizers sets up its own tap highlight ID.
4) The short tap gesture recognizer resets, erasing the tap highlight ID defined in (3).

To avoid this, the long press gesture recognizers immediately cancels any potential tap in progress.
If _singleTapDidReset: is called before (3), this does nothing. If the reset is called after (3),
_singleTapDidReset does nothing.

* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _highlightLongPressRecognized:]):
(cancelPotentialTapIfNecessary):
(-[WKContentView _singleTapDidReset:]):


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