LayoutTests:
authordarin <darin@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 5 Dec 2006 01:29:07 +0000 (01:29 +0000)
committerdarin <darin@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 5 Dec 2006 01:29:07 +0000 (01:29 +0000)
commit0e6dfe5f96188528e1145641fe746e232b7f526b
tree8506c9b742401c62a701670dc06bc74cf80208cc
parent6059f50d131d35d9bf949db8c6aede6799ff2c4b
LayoutTests:

        Reviewed by Adele.

        - test the part of http://bugs.webkit.org/show_bug.cgi?id=11628
          REGRESSION (r17597): Command-return in text fields doesn't open a new tab or window
          that can easily be tested from the DOM -- this only checks that
          simulated mouse events from clicking on a link have the key state
          from the Enter key keyboard event, which is one part of the fix
          for the bug above

        * fast/events/simulated-key-state-expected.txt: Added.
        * fast/events/simulated-key-state.html: Added.

WebCore:

        Reviewed by Adele.

        - fix another part of http://bugs.webkit.org/show_bug.cgi?id=11628
          REGRESSION (r17597): Command-return in text fields doesn't open a new tab or window

        This fixes command-return when the focus is on a link.
        Despite the title of the bug, Mitz wanted me to fix both, and I will not
        say no to him!

        Test: fast/events/simulated-key-state.html

        * dom/EventTargetNode.cpp:
        (WebCore::EventTargetNode::dispatchSimulatedMouseEvent): Instead of always passing
        false for all the key state in simulated mouse events, pass the state from the
        first underlying event in the chain that has key state; in the case in the bug,
        the keyboard event will be the underlying event itself and we'll propagate the
        alt key modifier to the mouse event, resulting in the effect we want. It's nice
        that JavaScript also gets to see the proper modifiers in the mouse event.

        * html/HTMLAnchorElement.cpp: (WebCore::HTMLAnchorElement::defaultEventHandler):
        Added code to pass in an underlying event to dispatchSimulatedClick. After looking
        at all the other callers, this seems to be the only one that needs to pass an
        event that is currently passing 0. Also removed the code that only simulated a
        click when the event has a PlatformKeyboardEvent -- no reason for that and it
        prevented me from writing a layout test for the fix.

        * dom/UIEventWithKeyState.h: Added findEventWithKeyState function that walks the
        underlyingEvent chain to find the first event that has key state. This already
        existed in WebKit, but I wanted to use it in dispatchSimulatedMouseEvent.
        * dom/UIEventWithKeyState.cpp: Added.

        * CMakeLists.txt: Added UIEventWithKeyState.cpp.
        * WebCore.vcproj/WebCore/WebCore.vcproj: Added UIEventWithKeyState.cpp.
        * WebCore.xcodeproj/project.pbxproj: Added UIEventWithKeyState.cpp.
        * WebCoreSources.bkl: Added UIEventWithKeyState.cpp.

        * WebCore.exp: Added findEventWithKeyState, used by WebKit.

WebKit:

        Reviewed by Adele.

        * WebCoreSupport/WebFrameLoaderClient.mm:
        (WebFrameLoaderClient::actionDictionary): Changed to use the new
        findEventWithKeyState function in WebCore instead of a local function
        in this file.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@18012 268f45cc-cd09-0410-ab3c-d52691b4dbfc
15 files changed:
LayoutTests/ChangeLog
LayoutTests/fast/events/simulated-key-state-expected.txt [new file with mode: 0644]
LayoutTests/fast/events/simulated-key-state.html [new file with mode: 0644]
WebCore/CMakeLists.txt
WebCore/ChangeLog
WebCore/WebCore.exp
WebCore/WebCore.vcproj/WebCore/WebCore.vcproj
WebCore/WebCore.xcodeproj/project.pbxproj
WebCore/WebCoreSources.bkl
WebCore/dom/EventTargetNode.cpp
WebCore/dom/UIEventWithKeyState.cpp [new file with mode: 0644]
WebCore/dom/UIEventWithKeyState.h
WebCore/html/HTMLAnchorElement.cpp
WebKit/ChangeLog
WebKit/WebCoreSupport/WebFrameLoaderClient.mm