Merge r174511 - Enable ARM64 disassembler for all platforms
https://bugs.webkit.org/show_bug.cgi?id=137560

Patch by Akos Kiss <akiss@inf.u-szeged.hu> on 2014-10-09
Reviewed by Michael Saboff.

Remove PLATFORM conditions from around WTF_USE_ARM64_DISASSEMBLER since
the ARM64 disassembler has no platform dependencies anymore.

* wtf/Platform.h:

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175882 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174540 - RenderMathMLUnderOver adds spacing to the child operator indefinitely when resizing the window.
https://bugs.webkit.org/show_bug.cgi?id=137330

Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2014-10-09
Reviewed by Darin Adler.

The layout for the <mundercover> math object happens in two separate passes. The first pass runs
the layout for the two children and then calculates the maximum child width.  It then sets the
stretch size for the math operator child.  And finally it runs the second layout pass by calling
the base class layout() function. The base class function then runs the layout for the children
rendering blocks.  In the operator child function computePreferredLogicalWidths(), the stretch
size is used to adjust the width (or the height) of the operator. Then it adds the leading and
trailing spaces and the total will be the operator child width.

When resizing or zooming the window, the render objects are just invalidated but marked as 'needs-
Layout'.  The problem is happening because the stretch size of the math operator is not reset
before running the layout.  The old logical width (or height) of the the math operator child which
is equal to the stretch size plus the leading and trailing spaces for is compared with the glyph
size if the old logical width ( or height) is larger, it is set to be the stretch size.  When it
is used again because of invalidation, new leading and trailing spaces are included in the new
logical width.  So with every zooming-in or out or window resizing, new leading and trailing
spaces are added to the logical width of the math operator child or the math <munderober> object.

Ensure the stretch size of the math operator render object is reset before running its layout.
Running the layout means either the page is just loaded or it's invalidated which means, no
layout stall data should be used.

Test: mathml/opentype/munderover-window-resize.html

* rendering/mathml/RenderMathMLOperator.cpp:
(WebCore::RenderMathMLOperator::resetStretchSize):
* rendering/mathml/RenderMathMLOperator.h:
resetStretchSize() sets the stretch size to its original value when the class is created.
* rendering/mathml/RenderMathMLUnderOver.cpp:
(WebCore::RenderMathMLUnderOver::layout):
Make sure the operator stretch size is reset before calling its layout. Also make sure the new
maximum stretch size to the operator objects that were invalid and needsLayout.

LayoutTests:
RenderMathMLUnderOver adds spacing to the child operator indefinitely when zooming or resizing the window.
https://bugs.webkit.org/show_bug.cgi?id=137330

Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2014-10-09
Reviewed by Darin Adler, Daniel Bates.

When the alignment is center, which is the common case for math, changing the size of
an object affects the position of this object also.  We need to confirm that zooming or
resizing the window should not affect the rectangle of the over/under math object operator.

* mathml/opentype/munderover-window-resize-expected.txt: Added.
* mathml/opentype/munderover-window-resize.html: Added.
New test with many under and over math objects.  After loading the page, the window is resized and
the view is zoomed in and out to make sure the layout of these under and over objects were not changed.
* platform/mac/mathml/opentype/opentype-stretchy-horizontal-expected.txt:
This test was wrong because of the spacing issue. The page has two <mover> math objects at the beginning.
Each of them has an <mspace> child. The width of the first <mspace> is 1em while the width of the second
<mspace> is 2em. The font size is 10pt. So it is expected to have the first one 10 pixels and the second
to be 20 pixels. In the test, the width of the first is 22 and the width of the second is 32.
I do expect this test to fail on other platforms since they have the same mistake which is now fixed. I am
going to submit the mac expected version only and when it fails I am going to collect the result and submit
another patch for the other platforms expected files.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175883 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174640 - Referrer Policy: Update <meta name="referrer"> values to match the spec
https://bugs.webkit.org/show_bug.cgi?id=137635

Reviewed by Jochen Eisinger.

Source/WebCore:

The Referrer Policy specification ([Working Draft][WD], [Editor's
draft[ED]) defines different keywords than we originally
implemented. We should support them in the interests of clarity and
interoperability with other browsers implementing the specification.

[WD]: http://www.w3.org/TR/referrer-policy/#referrer-policy-delivery-meta
[ED]: http://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-delivery-meta

This patch is a port of Blink's https://codereview.chromium.org/607433002/

Tests: http/tests/security/referrer-policy-conflicting-policies.html
       http/tests/security/referrer-policy-https-no-referrer-when-downgrade.html
       http/tests/security/referrer-policy-https-no-referrer.html
       http/tests/security/referrer-policy-https-unsafe-url.html
       http/tests/security/referrer-policy-no-referrer-when-downgrade.html
       http/tests/security/referrer-policy-no-referrer.html

* dom/Document.cpp:
(WebCore::Document::processReferrerPolicy):

LayoutTests:

* http/tests/security/referrer-policy-https-no-referrer-expected.txt: Added.
* http/tests/security/referrer-policy-https-no-referrer-when-downgrade-expected.txt: Added.
* http/tests/security/referrer-policy-https-no-referrer-when-downgrade.html: Added.
* http/tests/security/referrer-policy-https-no-referrer.html: Added.
* http/tests/security/referrer-policy-https-unsafe-url-expected.txt: Added.
* http/tests/security/referrer-policy-https-unsafe-url.html: Added.
* http/tests/security/referrer-policy-invalid-expected.txt: Update the error message with new keywords.
* http/tests/security/referrer-policy-no-referrer-expected.txt: Added.
* http/tests/security/referrer-policy-no-referrer-when-downgrade-expected.txt: Added.
* http/tests/security/referrer-policy-no-referrer-when-downgrade.html: Added.
* http/tests/security/referrer-policy-no-referrer.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175884 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174677 - Changes in the stretchy attribute do not update rendering
https://bugs.webkit.org/show_bug.cgi?id=136883

Reviewed by Darin Adler.

Source/WebCore:

Test: mathml/presentation/mo-stretch-update.html

We need to relayout when a change in the stretchy attribute
happens.

* mathml/MathMLTextElement.cpp:
(WebCore::MathMLTextElement::parseAttribute): Parse the
modifications of the stretchy attribute.
* mathml/MathMLTextElement.h:
* rendering/mathml/RenderMathMLOperator.cpp:
(WebCore::RenderMathMLOperator::setOperatorFlagAndScheduleLayoutIfNeeded):
Add function that receives the value instead of looking for it and
checks if the change should schedule a layout.
(WebCore::RenderMathMLOperator::setOperatorFlagFromAttribute):
(WebCore::RenderMathMLOperator::setOperatorFlagFromAttributeValue):
Add function that receives the value instead of looking for it.
* rendering/mathml/RenderMathMLOperator.h:

LayoutTests:

The test updates the stretchy value in a timeout.

* mathml/presentation/mo-stretch-update-expected.html: Added.
* mathml/presentation/mo-stretch-update.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175885 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174700 - Crash in WebCore::UserGestureIndicator::processingUserGesture with WebWorkers
https://bugs.webkit.org/show_bug.cgi?id=137676
<rdar://problem/15735049>

Reviewed by Alexey Proskuryakov.

Remove the code I added that tracks the timestamp of the most recent
user gesture from the event handling dispatch, as it was both
a silly place to do it and it originally crashed when events were fired from
Worker threads (although this was fixed in r152238).

It's now recorded by going through UserGestureIndicator, which is good because
it knows when a user has triggered an event. Its constructor now takes
a pointer to Document, and updates the timestamp there if necessary.

Not all UserGestureIndicator instances needed to reset the timestamp; Those did
not have to pass along the Document.

This is untestable due to the fix mentioned above.

* WebCore.exp.in: Change constructor signature.

* accessibility/AccessibilityNodeObject.cpp: Pass a pointer to the Document into the UserGestureIndicator.
(WebCore::AccessibilityNodeObject::increment):
(WebCore::AccessibilityNodeObject::decrement):
* accessibility/AccessibilityObject.cpp: Ditto.
(WebCore::AccessibilityObject::press):

* dom/Document.cpp:
(WebCore::Document::updateLastHandledUserGestureTimestamp): Renamed.
* dom/Document.h:

* dom/EventTarget.cpp: Remove the code to update the timestamp.
(WebCore::EventTarget::fireEventListeners):

* dom/UserGestureIndicator.cpp:
(WebCore::UserGestureIndicator::UserGestureIndicator): If there is a Document and
this is a user gesture, then reset the timestamp.
* dom/UserGestureIndicator.h:

* page/EventHandler.cpp: Pass a pointer to the Document.
(WebCore::EventHandler::handleMousePressEvent):
(WebCore::EventHandler::handleMouseDoubleClickEvent):
(WebCore::EventHandler::handleMouseReleaseEvent):
(WebCore::EventHandler::keyEvent):
(WebCore::EventHandler::handleTouchEvent):

* rendering/HitTestResult.cpp: Ditto.
(WebCore::HitTestResult::toggleMediaFullscreenState):
(WebCore::HitTestResult::enterFullscreenForVideo):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175888 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174761 - ASSERTION  FAILED in WebCore::RenderFlowThread::getRegionRangeForBox
https://bugs.webkit.org/show_bug.cgi?id=135563

Reviewed by David Hyatt.

Source/WebCore:

The new multi-column code doesn't work correctly when the document contains nested fragmentation
contexts. The problem is the current flow thread concept that can store only one RenderFlowThread
at a time and use it during layout.

The stored flow thread is always correct for regions because named flow threads are absolutley positioned
so every child renderer is contained inside them (with the expcetion of fixed positioned elements which are
treated separately).

For multi-column elements this is no longer the case. An absolutely positioned element inside a static
multi-column element will be contained by a block outside the fragmentation context. It can even be
contained by a different multi-column element in the case of nested flow threads.

The patch below explores a solution that's not based on a current flow thread stored globally. The proposed
patch makes every block to store a pointer to its fragmentation context and a flag that states if this pointer
needs to be updated or not. If the renderer is not a block it will get its flow thread from the containing
block. Once the containing flow thread is requested for the block, the pointer is computed and cached until
invalidated:
- when a subtree is removed from a flow thread
- when the position property of an element inside a flow thread changes

The process is recursive and it doesn't affect elements that are not nested inside a flow thread. If a block
changes position from relative to static, any element that was contained by it can only be contained by an
ancestor of the block. This ancestor will still be outside of any flow thread. This ensures that non-fragmentation
code is not affected from a performance perspective.

The patch affects the results of the performance tests:
- the regions layout tests have a decreased performance raging from 2% to 5-6%
- the regions selection tests have an increased performance raging from 1-2% to 10%
- the multicolumn layout tests (now pending review in b137687) have an increased performance
raging from 1.8% to 5%

Tests: fast/multicol/multicol-all-positioned-crash.html
       fast/multicol/multicol-transform-containing-block.html

* rendering/FlowThreadController.cpp:
(WebCore::FlowThreadController::FlowThreadController):
* rendering/FlowThreadController.h:
(WebCore::FlowThreadController::currentRenderFlowThread): Deleted.
(WebCore::FlowThreadController::setCurrentRenderFlowThread): Deleted.
* rendering/LayoutState.h:
(WebCore::LayoutState::currentRenderFlowThread):
(WebCore::LayoutState::setCurrentRenderFlowThread):
* rendering/RenderBlock.cpp:
(WebCore::RenderBlockRareData::RenderBlockRareData):
(WebCore::RenderBlock::styleWillChange):
(WebCore::RenderBlock::styleDidChange):
(WebCore::RenderBlock::collapseAnonymousBoxChild):
(WebCore::RenderBlock::cachedFlowThreadContainingBlock):
(WebCore::RenderBlock::cachedFlowThreadContainingBlockNeedsUpdate):
(WebCore::RenderBlock::setCachedFlowThreadContainingBlockNeedsUpdate):
(WebCore::RenderBlock::updateCachedFlowThreadContainingBlock):
(WebCore::RenderBlock::locateFlowThreadContainingBlock):
* rendering/RenderBlock.h:
* rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::styleWillChange):
* rendering/RenderBox.cpp:
(WebCore::RenderBox::borderBoxRectInRegion):
* rendering/RenderFlowThread.cpp:
(WebCore::RenderFlowThread::layout):
(WebCore::RenderFlowThread::updateAllLayerToRegionMappings):
(WebCore::RenderFlowThread::repaintRectangleInRegions):
(WebCore::CurrentRenderFlowThreadMaintainer::CurrentRenderFlowThreadMaintainer): Deleted.
(WebCore::CurrentRenderFlowThreadMaintainer::~CurrentRenderFlowThreadMaintainer): Deleted.
(WebCore::CurrentRenderFlowThreadDisabler::CurrentRenderFlowThreadDisabler): Deleted.
(WebCore::CurrentRenderFlowThreadDisabler::~CurrentRenderFlowThreadDisabler): Deleted.
* rendering/RenderFlowThread.h:
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintLayer):
(WebCore::RenderLayer::hitTestLayer):
(WebCore::RenderLayer::mapLayerClipRectsToFragmentationLayer):
(WebCore::RenderLayer::calculateClipRects):
* rendering/RenderObject.cpp:
(WebCore::RenderObject::showRegionsInformation):
(WebCore::RenderObject::insertedIntoTree):
(WebCore::RenderObject::removeFromRenderFlowThread):
(WebCore::RenderObject::removeFromRenderFlowThreadIncludingDescendants):
(WebCore::RenderObject::invalidateFlowThreadContainingBlockIncludingDescendants):
(WebCore::RenderObject::currentRenderNamedFlowFragment):
(WebCore::RenderObject::locateFlowThreadContainingBlock):
(WebCore::RenderObject::locateFlowThreadContainingBlockNoCache): Deleted.
(WebCore::RenderObject::removeFromRenderFlowThreadRecursive): Deleted.
* rendering/RenderObject.h:
(WebCore::RenderObject::flowThreadContainingBlock):
* rendering/RenderRegion.cpp:
(WebCore::RenderRegion::computeOverflowFromFlowThread):
* rendering/RenderView.cpp:
(WebCore::RenderView::pushLayoutStateForCurrentFlowThread):
(WebCore::RenderView::popLayoutStateForCurrentFlowThread):
* rendering/RenderView.h:

LayoutTests:

A test verifying that positioned elements inside multi-column containers don't
cause assertions or crashes.

* fast/multicol/multicol-all-positioned-crash-expected.txt: Added.
* fast/multicol/multicol-all-positioned-crash.html: Added.
* fast/multicol/multicol-transform-containing-block-expected.txt: Added.
* fast/multicol/multicol-transform-containing-block.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175890 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174762 - Use isnan from std namespace in ProfileGenerator.cpp
https://bugs.webkit.org/show_bug.cgi?id=137653

Patch by Adrien Destugues <pulkomandy@gmail.com> on 2014-10-16
Reviewed by Darin Adler.

The C++ isnan() function is in the std namespace. The unprefixed isnan
may be available because of C99 headers leakage in C++, but should not
be used.

No new tests: no functional change, build fix on platforms which don't
export C99 functions in C++.

* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::beginCallEntry):
(JSC::ProfileGenerator::endCallEntry):
(JSC::ProfileGenerator::didPause):
(JSC::ProfileGenerator::didContinue):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175891 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174802 - Missing RefPtr.release() calls in TextureMapper
https://bugs.webkit.org/show_bug.cgi?id=137777

Patch by Adrien Destugues <pulkomandy@gmail.com> on 2014-10-16
Reviewed by Chris Dumez.

No new tests: no functional change, cleanup/optimization.

Avoids useless ref/deref cycle when returning from functions.

* platform/graphics/texmap/TextureMapper.cpp:
(WebCore::TextureMapper::acquireTextureFromPool):
* platform/graphics/texmap/TextureMapperLayer.cpp:
(WebCore::TextureMapperLayer::paintIntoSurface):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175892 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174855 - Calling glReadPixels with BGRA format on an NVIDIA machine with an opaque context returns the wrong alpha values.
https://bugs.webkit.org/show_bug.cgi?id=137793.
<rdar://problem/15408133>

Reviewed by Dean Jackson.

This fixes conformance test context/context-attribute-preserve-drawing-buffer.html.

* platform/graphics/opengl/GraphicsContext3DOpenGL.cpp:
(WebCore::GraphicsContext3D::readPixelsAndConvertToBGRAIfNecessary):
On an NVIDIA machine, when the context has alpha turned off, call glReadPixels with RGBA format and then convert to RGBA.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175893 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174883 - [cmake] Remove duplicated source files
https://bugs.webkit.org/show_bug.cgi?id=137875

Reviewed by Gyuyoung Kim.

* CMakeLists.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175894 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174916 - Use glFinish instead of glFlush when drawing WebGL output to screen.
https://bugs.webkit.org/show_bug.cgi?id=137897.
<rdar://problem/15846550>

Reviewed by Brent Fulgham.

Passes all conformance tests.
Performance tested by http://threejs.org/examples/#webgl_performance and Unity WebGL performance tests.

* platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp:
(WebCore::GraphicsContext3D::prepareTexture):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175895 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174920 - Tighten XMLHttpRequest setRequestHeader value check
https://bugs.webkit.org/show_bug.cgi?id=128593

Patch by Youenn Fablet <youenn.fablet@crf.canon.fr> on 2014-10-20
Reviewed by Darin Adler.

Source/WebCore:

Test: http/tests/xmlhttprequest/set-bad-headervalue.html

* platform/network/HTTPParsers.cpp:
(WebCore::isValidHTTPHeaderValue): Updated header values check according RFC 7230.
(WebCore::isValidHTTPToken): Renamed variable name and updated RFC related comment.

LayoutTests:

Added a test originating from w3c-test.org to test header values checking.
Testing headers with non ASCII characters and various control characters.

* http/tests/xmlhttprequest/set-bad-headervalue-expected.txt: Added.
* http/tests/xmlhttprequest/set-bad-headervalue.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175896 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174922 - Ensure attached frame count doesn't exceed the maximum allowed frames
https://bugs.webkit.org/show_bug.cgi?id=136457

Reviewed by Alexey Proskuryakov.

Source/WebCore:

Test: fast/frames/exponential-frames.html

* html/HTMLFrameElementBase.cpp:
(WebCore::HTMLFrameElementBase::isURLAllowed):

LayoutTests:

* fast/frames/exponential-frames-expected.txt: Added.
* fast/frames/exponential-frames.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175897 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174986 - REGRESSION: Google Search (mobile) video thumbnails are too large.
https://bugs.webkit.org/show_bug.cgi?id=137895

Reviewed by Simon Fraser.

This patch fixes layer clipping when an ancestor layer has border-radius clipping.

In cases, where the current layer has non-radius cliprect, while an ancestor layer
has border-radius clipping, we only use the border-radius rect to clip.

Source/WebCore:

Test: fast/clip/overflow-hidden-with-border-radius-overflow-clipping-parent.html

* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::clipToRect):
(WebCore::RenderLayer::restoreClip):
(WebCore::RenderLayer::collectFragments):
(WebCore::RenderLayer::calculateClipRects):
* rendering/RenderLayer.h:
(WebCore::ClipRect::ClipRect):
(WebCore::ClipRect::effectedByRadius):
(WebCore::ClipRect::setEffectedByRadius):
(WebCore::ClipRect::operator==):
(WebCore::ClipRect::operator!=):
(WebCore::ClipRect::intersect):
(WebCore::ClipRect::hasRadius): Deleted.
(WebCore::ClipRect::setHasRadius): Deleted.

LayoutTests:

* fast/clip/overflow-hidden-with-border-radius-overflow-clipping-parent-expected.html: Added.
* fast/clip/overflow-hidden-with-border-radius-overflow-clipping-parent.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175898 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r174992 - AX: [ATK] CSS-generated text content not exposed to assistive technologies
https://bugs.webkit.org/show_bug.cgi?id=137669

Reviewed by Chris Fleizach.

Source/WebCore:

Do not use a text iterator to get the text for elements which include
pseudo elements.

Test: accessibility/css-content-attribute.html

* accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::textUnderElement):

LayoutTests:

Moved the Mac platform test and modified it to dump the accessible tree
and string values rather than a platform-specific hierarchy so that it
could be shared across platforms.

* accessibility/css-content-attribute.html: Added.
* platform/gtk/accessibility/css-content-attribute-expected.txt: Added.
* platform/mac/accessibility/css-content-attribute-expected.txt: Modified to reflect new output.
* platform/mac/accessibility/css-content-attribute.html: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175899 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r175005 - Remove erroneous canUseJIT() in the intrinsics version of JITThunks::hostFunctionStub().
<https://webkit.org/b/137937>

Reviewed by Michael Saboff.

This version of JITThunks::hostFunctionStub() can only be called from the intrinsics
version of VM::getHostFunction() which asserts canUseJIT().  Hence, we can eliminate
the canUseJIT() check in JITThunks::hostFunctionStub().  We don't handle the
!canUseJIT() case properly there anyway.

* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175900 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r175043 - Match spec for font-weight: bolder|lighter
https://bugs.webkit.org/show_bug.cgi?id=137919

Patch by Tibor Meszaros <tmeszaros.u-szeged@partner.samsung.com> on 2014-10-22
Reviewed by Andreas Kling.

This patch is a merge of Blink's
Source/WebCore:

https://chromiumcodereview.appspot.com/15994009

Currently, bolder and lighter change font-weight in a non-compliant way.
The spec (http://www.w3.org/TR/css3-fonts/#bolderlighter) defines
exactly what the computed values should be given the inherited weight values,
so we should match those.

The removed FIXME's for selecting the next lightest/heaviest weight from
the used font family seems to refer to behaviour from
CSS1 (http://www.w3.org/TR/CSS1/#font-weight), while this is replaced
with a simpler procedure for resolving bolder and lighter in font weights
in CSS2 (http://www.w3.org/TR/CSS2/fonts.html#propdef-font-weight) and CSS3 (link above).

and https://codereview.chromium.org/137813004

According to http://dev.w3.org/csswg/css-fonts/#font-weight-prop, the computed
weight of 'lighter' and 'bolder' are based on the inherited 'font-weight', so set
that inherited weight before calculating 'lighter' and 'bolder'.

Tests: css3/font-weight-multiple-selectors.html
       css3/font-weight.html

* css/DeprecatedStyleBuilder.cpp:
(WebCore::ApplyPropertyFontWeight::applyValue):
* platform/graphics/FontDescription.cpp:
(WebCore::FontDescription::lighterWeight):
(WebCore::FontDescription::bolderWeight):

LayoutTests:

https://chromiumcodereview.appspot.com/15994009 and
https://codereview.chromium.org/137813004

* css3/font-weight-expected.txt: Added.
* css3/font-weight-multiple-selectors-expected.txt: Added.
* css3/font-weight-multiple-selectors.html: Added.
* css3/font-weight.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175901 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r175053 - XMLHttpRequest should support attribute responseURL as per latest XHR spec.
https://bugs.webkit.org/show_bug.cgi?id=136938

Patch by Shivakumar JM <shiva.jm@samsung.com> on 2014-10-22
Reviewed by Alexey Proskuryakov.

Source/WebCore:

Tests: http/tests/xmlhttprequest/basic-auth-responseURL.html
       http/tests/xmlhttprequest/cross-origin-redirect-responseURL.html
       http/tests/xmlhttprequest/redirect-credentials-responseURL.html
       http/tests/xmlhttprequest/xmlhttprequest-responseURL.html

XMLHttpRequest should support attribute responseURL

* xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::responseURL):
* xml/XMLHttpRequest.h:
* xml/XMLHttpRequest.idl:

LayoutTests:

Added test to check responseURL attribute in XMLHttpRequest.

* http/tests/xmlhttprequest/basic-auth-responseURL-expected.txt: Added.
* http/tests/xmlhttprequest/basic-auth-responseURL.html: Added.
* http/tests/xmlhttprequest/cross-origin-redirect-responseURL-expected.txt: Added.
* http/tests/xmlhttprequest/cross-origin-redirect-responseURL.html: Added.
* http/tests/xmlhttprequest/redirect-credentials-responseURL-expected.txt: Added.
* http/tests/xmlhttprequest/redirect-credentials-responseURL.html: Added.
* http/tests/xmlhttprequest/xmlhttprequest-responseURL-expected.txt: Added.
* http/tests/xmlhttprequest/xmlhttprequest-responseURL.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175902 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r175074 - SVG loaded through html <img> can't request to load any external resources.
https://bugs.webkit.org/show_bug.cgi?id=137762.

Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2014-10-22
Reviewed by Daniel Bates.

Source/WebCore:

SVG images have unique security rules that prevent them from loading any external
resources. This patch enforces these rules in CachedResourceLoader::canRequest for
all non-data-uri resources.

The fix and the tests are ported but modified a little from the chromium fix:
http://src.chromium.org/viewvc/blink?view=rev&rev=176084

Test: http/tests/security/svg-image-with-cached-remote-image.html
      http/tests/security/svg-image-with-css-cross-domain.html

For the SVG image, prevent loading any external sub-resource except for data urls.
* loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::canRequest):

LayoutTests:

Ensure that SVG images, which are loaded through the <img> tag or through the
CSS background image, cannot load any external sub-resource except for data-
URL resources (though this doesn't work at the time of writing, see bug #137941).
Also ensure the same rule is enforced on cached resources.

The tests are ported but modified a little from the chromium fix:
http://src.chromium.org/viewvc/blink?view=rev&rev=176084

Set the circle background to orange
* http/tests/security/resources/image-with-css-cross-domain-circle.css: Added.
(circle):

Set the circle stroke-width = 2 and the circle stroke = red
* http/tests/security/resources/image-with-css-cross-domain-circle2.css: Added.
(circle):

This svg references the two css files: one is relative path and the other is absolute path
* http/tests/security/resources/image-with-css-cross-domain.svg: Added.

This svg references an external image.
* http/tests/security/resources/image-with-remote-image.svg: Added.

A helper css which sets the formatting style for some html tags
* http/tests/security/svg-image-with-css-cross-domain.css: Added.
(span):
(span.circle-css-cross-domain):
(embed):
(iframe):

Test the svg which is referenced as a cached image by an <object> tag, does not load
external sub-resource.
* http/tests/security/svg-image-with-cached-remote-image-expected.html: Added.
* http/tests/security/svg-image-with-cached-remote-image.html: Added.

Test loading sub-resources for an svg which is included in the html by different ways
and which references external css files.
Ensure the image object does not load any external sub-resources.
* http/tests/security/svg-image-with-css-cross-domain-expected.html: Added.
* http/tests/security/svg-image-with-css-cross-domain.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175903 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong in CET
https://bugs.webkit.org/show_bug.cgi?id=130967

Patch by Byungseon Shin <sun.shin@lge.com> on 2014-10-22
Reviewed by Mark Lam.

Source/JavaScriptCore:

By definition of calculateLocalTimeOffset, input time should be UTC time.
But there are many cases when input time is based on local time.
So, it gives erroneous results while calculating offset of DST boundary time.
By adding a argument to distinguish UTC and local time, we can get the correct offset.

* JavaScriptCore.order:
* runtime/DateConstructor.cpp:
(JSC::constructDate):
(JSC::callDate):
(JSC::dateUTC):
* runtime/DateInstance.cpp:
(JSC::DateInstance::calculateGregorianDateTime):
(JSC::DateInstance::calculateGregorianDateTimeUTC):
* runtime/DatePrototype.cpp:
(JSC::setNewValueFromTimeArgs):
(JSC::setNewValueFromDateArgs):
(JSC::dateProtoFuncSetMilliSeconds):
(JSC::dateProtoFuncSetUTCMilliseconds):
(JSC::dateProtoFuncSetSeconds):
(JSC::dateProtoFuncSetUTCSeconds):
(JSC::dateProtoFuncSetMinutes):
(JSC::dateProtoFuncSetUTCMinutes):
(JSC::dateProtoFuncSetHours):
(JSC::dateProtoFuncSetUTCHours):
(JSC::dateProtoFuncSetDate):
(JSC::dateProtoFuncSetUTCDate):
(JSC::dateProtoFuncSetMonth):
(JSC::dateProtoFuncSetUTCMonth):
(JSC::dateProtoFuncSetFullYear):
(JSC::dateProtoFuncSetUTCFullYear):
(JSC::dateProtoFuncSetYear):
* runtime/JSDateMath.cpp:
(JSC::localTimeOffset):
(JSC::gregorianDateTimeToMS):
(JSC::msToGregorianDateTime):
(JSC::parseDateFromNullTerminatedCharacters):
* runtime/JSDateMath.h:
* runtime/VM.h:
(JSC::LocalTimeOffsetCache::LocalTimeOffsetCache):
(JSC::LocalTimeOffsetCache::reset):
Passing TimeType argument to distingush UTC time and local time.

Source/WTF:

By definition of calculateLocalTimeOffset, input time should be UTC time.
But there are many cases when input time is based on local time.
So, it gives erroneous results while calculating offset of DST boundary time.
By adding a argument to distinguish UTC and local time, we can get the correct offset.

* wtf/DateMath.cpp:
(WTF::calculateLocalTimeOffset):
(WTF::parseDateFromNullTerminatedCharacters):
Compensate time offset depends on UTC time or local time.
* wtf/DateMath.h:
Add argument to differenciate UTC or local time.

LayoutTests:

Set latest DST timezone boundary values on
<http://www.timeanddate.com/time/zone/usa/los-angeles>

* js/dom/script-tests/date-DST-time-cusps.js:

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@175904 268f45cc-cd09-0410-ab3c-d52691b4dbfc