Merge r175724 - slow_path_get_direct_pname() needs to be hardened against a constant baseValue.
<https://webkit.org/b/138476>

Reviewed by Michael Saboff.

Source/JavaScriptCore:

slow_path_get_direct_pname() currently assumes that the baseValue is always a
non-constant virtual register.  However, this is not always the case like in the
following:

    function foo() {
        var o = { a:1 };
        for (var n in o)
            0[n];
    }
    foo();

This patch fixes it to also check for constant virtual register indexes.

* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):

LayoutTests:

* js/get-by-pname-expected.txt:
* js/script-tests/get-by-pname.js:
(getByPnameOnConstant):
(getByPnameOnVar):
- Added more test cases.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176176 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176076 - AX: [ATK] Accessible focus events are emitted when the selection is changed in non-focused combo boxes
https://bugs.webkit.org/show_bug.cgi?id=137866

Reviewed by Mario Sanchez Prada.

Source/WebCore:

Check that the AccessibilityMenuList is really focused before notifying
the platform that it is focused. Likewise, only notify the platform of
an AccessibilityMenuListOption focus gain if the AccessibilityMenuList
containing that option is expanded.

Test: platform/gtk/accessibility/menu-list-unfocused-notifications.html

* accessibility/atk/AXObjectCacheAtk.cpp:
(WebCore::notifyChildrenSelectionChange):
(WebCore::AXObjectCache::postPlatformNotification):

LayoutTests:

* platform/gtk/accessibility/menu-list-unfocused-notifications-expected.txt: Added.
* platform/gtk/accessibility/menu-list-unfocused-notifications.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176177 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176091 - AX: [ATK] Do not return ATK_ROLE_UNKNOWN for null or otherwise invalid accessible objects
https://bugs.webkit.org/show_bug.cgi?id=137867

Reviewed by Chris Fleizach.

Source/WebCore:

Return ATK_ROLE_INVALID for null or otherwise invalid accessible objects.

Test: platform/gtk/accessibility/detached-object-role.html

* accessibility/atk/WebKitAccessibleWrapperAtk.cpp:
(webkitAccessibleGetRole):

Tools:

Add ATK_ROLE_INVALID to roleToString. Remove the null AtkRole check in
AccessibilityUIElement::role: ATK_ROLE_INVALID = 0, and we need to be
able to test for the presence of ATK_ROLE_INVALID.

* WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:
(WTR::AccessibilityUIElement::role):

LayoutTests:

* platform/gtk/accessibility/detached-object-role-expected.txt: Added.
* platform/gtk/accessibility/detached-object-role.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176178 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176080 - Web Inspector: Replace PDF Probes icon with SVG version
https://bugs.webkit.org/show_bug.cgi?id=137296

Reviewed by Joseph Pecoraro.

* UserInterface/Images/NavigationItemProbes.pdf: Removed.
* UserInterface/Images/NavigationItemProbes.svg: Added.
* UserInterface/Views/ProbeDetailsSidebarPanel.js:
(WebInspector.ProbeDetailsSidebarPanel): Use NavigationItemProbes.svg.
* UserInterface/Images/gtk/NavigationItemProbes.svg: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176179 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r175807 - ASSERTION FAILED: !object || !object->parent()->isRuby() || is<RenderRubyRun>(*object) || (object->isInline() && (object->isBeforeContent() || object->isAfterContent())) || (object->isAnonymous() && ... ) in WebCore::isAnonymousRubyInlineBlock
https://bugs.webkit.org/show_bug.cgi?id=137958

Reviewed by Chris Dumez.

Source/WebCore:

When a ruby element, with block behavior, dynamically changes its style
from multicol to without multicol, we have to remove its special children,
RenderMultiColumnFlowThread and RenderMultiColumnSet, the normal way using
the method in RenderBlockFlow base class. This patch adds both
RenderMultiColumnFlowThread and RenderMultiColumnSet to the list of RenderRuby
children removed normally and adds a new function - isRubyChildForNormalRemove -
to test the condition and use it in the assertion in RenderRuby*::removeChild
method.

Test: fast/multicol/newmulticol/ruby-from-multicol-to-auto.html

* rendering/RenderRuby.cpp:
(WebCore::isRubyChildForNormalRemove):
(WebCore::RenderRubyAsInline::removeChild):
(WebCore::RenderRubyAsBlock::removeChild):

LayoutTests:

* fast/multicol/newmulticol/ruby-from-multicol-to-auto-expected.txt: Added.
* fast/multicol/newmulticol/ruby-from-multicol-to-auto.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176181 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r175809 - Crash in WebCore::Node::getFlag
https://bugs.webkit.org/show_bug.cgi?id=137961

Reviewed by Antti Koivisto.

Source/WebCore:

* editing/ApplyStyleCommand.cpp:
(WebCore::ApplyStyleCommand::applyBlockStyle): Null pointer check added.

LayoutTests:

* editing/execCommand/crash-137961-expected.txt: Added.
* editing/execCommand/crash-137961.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r175965 - [Frame Flattening] ASSERT(transaction->view == &view()) fails in RenderBlock::removeFromUpdateScrollInfoAfterLayoutTransaction()
https://bugs.webkit.org/show_bug.cgi?id=138615
<rdar://problem/18928487>

Reviewed by David Hyatt.

Source/WebCore:

Fixes an issue where we always expected that the RenderView associated with the RenderBlock called in
RenderBlock::removeFromUpdateScrollInfoAfterLayoutTransaction() is the same as the RenderView associated with
the top transaction in the UpdateScrollInfoAfterLayoutTransaction stack regardless of frame flattening. This
expectation is only true when frame flattening is disabled.

Test: fast/frames/flattening/iframe-flattening-inside-flexbox-with-delayed-scroll-update.html

* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::removeFromUpdateScrollInfoAfterLayoutTransaction):

LayoutTests:

Add a test that causes an assertion failure in affected builds.

* fast/frames/flattening/iframe-flattening-inside-flexbox-with-delayed-scroll-update-expected.txt: Added.
* fast/frames/flattening/iframe-flattening-inside-flexbox-with-delayed-scroll-update.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176183 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176071 - [SOUP] Missing ResourceRequest members encoded/decoded
https://bugs.webkit.org/show_bug.cgi?id=138694

Reviewed by Sergio Villar Senin.

At least timeoutInterval and priority should also be
encoded/decoded. This fixes all http/tests/xmlhttprequest/timeout/
tests when using the network process, since the timeout is always
0 for all requests that we send to the network process.

* Shared/soup/WebCoreArgumentCodersSoup.cpp:
(IPC::ArgumentCoder<ResourceRequest>::encodePlatformData):
(IPC::ArgumentCoder<ResourceRequest>::decodePlatformData):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176184 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176082 - REGRESSION (r172826): Password field placeholder text is missing if
placeholder attribute precedes type attribute

<https://bugs.webkit.org/show_bug.cgi?id=138682>
<rdar://problem/18574213>

Source/WebCore:

When the placeholder attribute is encountered, a shadow tree is created
to include the placeholder element. When the type attribute is
encountered, the previous shadow tree is destroyed, and a new shadow
tree is created. TextFieldInputType::createShadowSubtree() did not
handle creating the placeholder element.

This regressed in r172826 because prior to r172826, the placeholder
element would be recreated when
HTMLTextFormControlElement::updatePlaceholderVisibility() was called.
In r172826, updatePlaceholderVisibility() was changed to only show or
hide the placeholder element if it exists.

Reviewed by Benjamin Poulain.

* html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::createShadowSubtree):
Call updatePlaceholderVisibility() to insert the placeholder element
(after the inner text element has been inserted, as it appears before
it in the shadow DOM).

LayoutTests:

Reviewed by Benjamin Poulain.

* fast/forms/placeholder-attribute-ordering-expected.html: Added.
* fast/forms/placeholder-attribute-ordering.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176185 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176083 - ARMv7(s) Assembler: LDRH with immediate offset is loading from the wrong offset
https://bugs.webkit.org/show_bug.cgi?id=136914

Reviewed by Michael Saboff.

TLDR: the immediate offset of half-word load was divided by 2.

Story time: So I started getting those weird reports of :nth-child() behaving bizarrely
on ARMv7 and ARMv7s. To make things worse, the behavior changes depending on style updates.

I started looking the disassembly on the tests cases...

The first thing I noticed was that the computation of An+B looked wrong. For example,
in the case of n+6, the instruction should have been:
    subs r1, r1, #6
but was
    subs r1, r1, #2

After spending a lot of time trying to find the error in the assembler, I discovered
the problem was not real, but just a bug in the disassembler.
This is the first fix: ARMv7DOpcodeAddSubtractImmediate3's immediate3() was truncating
the value to 2 bits instead of 3 bits.

The disassembler being fixed, I still have no lead on the weird bug. Some disassembly later,
I realize the LDRH instruction is not decoded at all. The reason is that both LDRH and STRH
were under the umbrella ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord but the pattern
only matched SRTH.

I fix that next, ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord is split into
ARMv7DOpcodeStoreRegisterImmediateHalfWord and ARMv7DOpcodeLoadRegisterImmediateHalfWord,
each with their own pattern and their instruction group.

Now that I can see the LDRHs correctly, there is something fishy about them, their offset
is way too small for the data I load.

This time, looking at the binary, the generated code is indeed incorrect. It turns out that
the ARMv7 assembler shifted the offset of half-word load as if they were byte load: divided by 4.
As a result, all the load of half-words with more than zero offset were loading
values with a smaller offset than what they should have.

That being fixed, I dump the assembly: still wrong. I am ready to throw my keyboard through
my screen at that point.

Looking at the disassembler, there is yet again a bug. The computation of the scale() adjustment
of the offset was incorrect for anything but word loads.
I replaced it by a switch-case to make it explicit.

STRH is likely incorrect too. I'll fix that in a follow up, I want to survey all the 16 bits cases
that are not directly used by the CSS JIT.

* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::ldrh):
Fix the immediate scaling. Add an assertion to make sure the alignment of the input is correct.

* disassembler/ARMv7/ARMv7DOpcode.cpp:
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale):
Fix the scaling code. Just hardcode instruction-to-scale table.

* disassembler/ARMv7/ARMv7DOpcode.h:
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3):
The mask for a 3 bits immediate is not 3 :)

(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale): Deleted.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176151 - STRH can store values with the wrong offset
https://bugs.webkit.org/show_bug.cgi?id=138723

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-11-14
Reviewed by Michael Saboff.

This is the counterpart of r176083 for the str instruction.

I believe this code is currently unreachable because there is only one client of strh()
in the MacroAssembler and it always setup the scale explicitely.

* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::strh):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176187 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176096 - Policy client not called for navigations through the page cache
https://bugs.webkit.org/show_bug.cgi?id=138703

Reviewed by Alexey Proskuryakov.

Source/WebCore:

Test added to TestWebKitAPI/Tests/WebKit2Cocoa/Navigation.mm.

* loader/FrameLoader.cpp:
(WebCore::FrameLoader::loadDifferentDocumentItem): When using a cached page, which already
has a document loader, set the document loader’s triggering action (so that the policy
client sees that this is a back/forward navigation) and clear its last checked request (so
that the policy client gets called).

Tools:

* TestWebKitAPI/Tests/WebKit2Cocoa/Navigation.mm:
(-[DecidePolicyForPageCacheNavigationDelegate webView:didFinishNavigation:]):
(-[DecidePolicyForPageCacheNavigationDelegate webView:decidePolicyForNavigationAction:decisionHandler:]):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176188 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176119 - [SOUP] Encode/Decode allowCookies in ResourceRequest
https://bugs.webkit.org/show_bug.cgi?id=138730

Reviewed by Sergio Villar Senin.

We are not sending this information to the network process, making
cookies always available. Fixes
http/tests/xmlhttprequest/cross-origin-no-authorization.html when
network process is enabled.

* Shared/soup/WebCoreArgumentCodersSoup.cpp:
(IPC::ArgumentCoder<ResourceRequest>::encodePlatformData):
(IPC::ArgumentCoder<ResourceRequest>::decodePlatformData):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176189 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176120 - [SOUP] Use GMainLoopSource for request timeout in ResourceHandle
https://bugs.webkit.org/show_bug.cgi?id=138695

Reviewed by Sergio Villar Senin.

We are currently using soup_timeout_add() that simply creates a
GSource and attaches it to the given context. Using
GMainLoopSource we simplify the code and fix any potential problem
of converting the double value into milliseconds.

* platform/network/ResourceHandleInternal.h:
* platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::cleanupSoupRequestOperation):
(WebCore::ResourceHandle::sendPendingRequest):
(WebCore::ResourceHandle::platformSetDefersLoading):
(WebCore::requestTimeoutCallback): Deleted.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176190 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176124 - Table rows repaint entire table when their background color changes.
https://bugs.webkit.org/show_bug.cgi?id=26662

Reviewed by Simon Fraser.

Added fast/repaint/table-row-repaint.html

Source/WebCore:

* rendering/RenderTableCell.h:
* rendering/RenderTableRow.cpp:
(WebCore::RenderTableRow::clippedOverflowRectForRepaint):
Improve table row's function to unite with the cell rects that can possibly
have the the row's background color painted behind them.

LayoutTests:

* fast/repaint/table-row-repaint-expected.txt: Added.
* fast/repaint/table-row-repaint.html: Added.
* platform/mac/accessibility/table-detection-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176191 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176154 - Network process crash when running http/tests/appcache/fallback.html
https://bugs.webkit.org/show_bug.cgi?id=138740

Reviewed by Alexey Proskuryakov.

It happens because ResourceHandle::continueWillSendRequest() is
called with a null request. We could handle that case in the
ResourceHandle, but the thing is tha the behaviour is
not the same for async loads, or when loading in the web
process. In WebResourceLoader::willSendRequest(),
ResourceRequest::willSendRequest() is called, and cancels the load
if the client returns a null request. In this case, the
ResourceLoader is detached and WebResourceLoader::willSendRequest()
returns early without sending the ContinueWillSendRequest message
to the network process. However, for synchronous loads,
NetworkResourceLoader::continueWillSendRequest() is always called.

Fixes http/tests/appcache/fallback.html for GTK port when using
the network process.

* NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::continueWillSendRequest): Do not
call ResourceHandle::continueWillSendRequest() if the client
request is null, since the load is going to be cancelled.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176192 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176163 - AX: [ATK] REGRESSION(r166288): Accessible values are no longer accessible via AT-SPI2
https://bugs.webkit.org/show_bug.cgi?id=138776

Reviewed by Chris Fleizach.

r166288 used #if...#else instead of #if...#endif, thus disabling the old
AtkValue support. Unfortunately AT-SPI2 doesn't yet have support for the
new AtkValue API. Thus r166288 broke access to value-holding elements for
AT-SPI2 assistive technologies. Replacing #else with #endif fixes things.

No new tests because catching this regression would require AT-SPI2.

* accessibility/atk/WebKitAccessibleInterfaceValue.cpp:
(webkitAccessibleValueGetMinimumIncrement):
(webkitAccessibleValueInterfaceInit):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176193 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176169 - Attribute text in HTMLAnchorElement should behave as per specification.
https://bugs.webkit.org/show_bug.cgi?id=138557

Patch by Shivakumar JM <shiva.jm@samsung.com> on 2014-11-16
Reviewed by Darin Adler.

Source/WebCore:

attribute text in HTMLAnchorElement should not be readonly as per specification
http://www.w3.org/TR/html/text-level-semantics.html#dom-a-text. It should behave as textContent attribute.
Also This matches the behavior of Chrome 38 and FireFox.

Test: fast/dom/HTMLAnchorElement/anchor-text-attribute.html

* html/HTMLAnchorElement.cpp:
(WebCore::HTMLAnchorElement::text):
(WebCore::HTMLAnchorElement::setText):
* html/HTMLAnchorElement.h:
* html/HTMLAnchorElement.idl:

LayoutTests:

* fast/dom/HTMLAnchorElement/anchor-text-attribute-expected.txt: Added.
* fast/dom/HTMLAnchorElement/anchor-text-attribute.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176194 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176170 - Assertion hit when setting a very large value to 'border-width' / 'font-size' CSS properties
https://bugs.webkit.org/show_bug.cgi?id=138770

Reviewed by Darin Adler.

Source/WebCore:

When setting a very large value to a CSS property, it is represented internally as
infinity. r166114 already tried to deal with this by adding an std::isinf() check
in CSSValuePool::createValue() and returning an identifier CSSPrimitiveValue with
CSSValueInvalid value in such case. The issue is that doing leads to the
StyleBuilder getting a CSSValueInvalid CSSPrimitive value as input, which is not
handled and leads to assertions.

This patch updates the CSSParser to detect cases where the double value is
infinity earlier (in CSSParser::validUnit() and parseSimpleLengthValue()), so
that we mark the value as invalid and actually drop it. As a result,
CSSPrimitiveValues with CSSValueInvalid value no longer make their way to the
StyleBuilder.

Test: fast/css/style-builder-infinite-value.html
      fast/css/infinite-floating-value.html

* css/CSSParser.cpp:
(WebCore::parseSimpleLengthValue):
(WebCore::CSSParser::validUnit):
* css/CSSValuePool.cpp:
(WebCore::CSSValuePool::createValue):

LayoutTests:

Add a layout test setting very large values to 'border-width' and
'font-size' CSS properties.

* fast/css/style-builder-infinite-value-expected.txt: Added.
* fast/css/style-builder-infinite-value.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.6@176195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r176252 - [SOUP] [GnuTLS] Don't use a SSL3.0 record version in client hello.
https://bugs.webkit.org/show_bug.cgi?id=138794

Reviewed by Sergio Villar Senin.

It seems that following POODLE many sites incorrectly banned SSL 3.0
record packet versions. Since GnuTLS uses a SSL 3.0 record to
advertise TLS 1.2, they are effectively banning it even if it doesn't
advertise SSL 3.0. That is a server issue, but it can be worked around
by using the modifier %LATEST_RECORD_VERSION.

With this modifier, GnuTLS will use the latest TLS version record
in client hello instead of using the default SSL 3.0.

* NetworkProcess/EntryPoint/unix/NetworkProcessMain.cpp:
(main):
* WebProcess/EntryPoint/unix/WebProcessMain.cpp:
(main):

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