Move Node::isMouseFocusable() to Element.
<http://webkit.org/b/116762>

Reviewed by Anders Carlsson.

Source/WebCore:

Node::isMouseFocusable() would just return isFocusable(), which is never true for a non-Element
since Node::supportsFocus() always returns false. So move it to Element!

* dom/Node.h:
* dom/Node.cpp:
* dom/Element.h:
* dom/Element.cpp:
(WebCore::Element::isMouseFocusable):

    Moved here from Node.

* editing/FrameSelection.cpp:
(WebCore::FrameSelection::setFocusedNodeIfNeeded):
* page/EventHandler.cpp:
(WebCore::EventHandler::dispatchMouseEvent):

    Walk up the parent chain with parentOrShadowHostElement() instead of parentOrShadowHostNode().
    Removed a misleading no-op hunk about mouse-focusable ShadowRoots, since ShadowRoots are not
    Elements and thus cannot be mouse-focusable.

* page/TouchAdjustment.cpp:
(WebCore::TouchAdjustment::nodeRespondsToTapGesture):

    Check that the Node is an Element before asking if it's mouse-focusable.

* html/HTMLAnchorElement.h:
* html/HTMLAreaElement.h:
* html/HTMLFormControlElement.h:
* html/HTMLInputElement.h:
* html/HTMLMediaElement.h:
* html/HTMLSelectElement.h:
* html/HTMLTextAreaElement.h:
* html/shadow/ClearButtonElement.h:
* html/shadow/TextControlInnerElements.h:
* svg/SVGAElement.h:
* svg/SVGStyledElement.h:

    Sprinkle OVERRIDE.

Source/WebKit2:

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::highlightPotentialActivation):

    Check that the potentially activated Node is an Element before asking if it's mouse-focusable.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150692 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Updated expected results after r150688.

Reviewed by Andreas Kling.

* http/tests/globalhistory/history-delegate-basic-refresh-redirect-expected.txt: Now shows
the URL that performed the client redirect, as expected.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150693 268f45cc-cd09-0410-ab3c-d52691b4dbfc
We broke (-2^31/-1)|0 in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116767

Source/JavaScriptCore: 

Reviewed by Andreas Kling.
        
The bug is that we were assuming that in the -2^31 case, we already had -2^31
in the result register. This was a wrong assumption.

* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86):

LayoutTests: 

Reviewed by Andreas Kling.

* fast/js/dfg-div-by-neg1-and-then-or-zero-interesting-reg-alloc-expected.txt: Added.
* fast/js/dfg-div-by-neg1-and-then-or-zero-interesting-reg-alloc.html: Added.
* fast/js/dfg-div-by-zero-and-then-or-zero-interesting-reg-alloc-expected.txt: Added.
* fast/js/dfg-div-by-zero-and-then-or-zero-interesting-reg-alloc.html: Added.
* fast/js/dfg-div-neg2tothe31-by-one-and-then-or-zero-with-interesting-reg-alloc-expected.txt: Added.
* fast/js/dfg-div-neg2tothe31-by-one-and-then-or-zero-with-interesting-reg-alloc.html: Added.
* fast/js/jsc-test-list:
* fast/js/script-tests/dfg-div-by-neg1-and-then-or-zero-interesting-reg-alloc.js: Added.
(foo):
* fast/js/script-tests/dfg-div-by-zero-and-then-or-zero-interesting-reg-alloc.js: Added.
(foo):
* fast/js/script-tests/dfg-div-neg2tothe31-by-one-and-then-or-zero-with-interesting-reg-alloc.js: Added.
(foo):



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