Remove String::operator+=() from plugin code
https://bugs.webkit.org/show_bug.cgi?id=95896

Reviewed by Adam Barth.

Use operator+() to concatenate strings instead of operator+=().

* plugins/PluginView.cpp:
(WebCore::parseRFC822HeaderFields):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127708 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Unreviewed gardening. Skip the failing tests.

* platform/qt/Skipped:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127709 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Three XSLTProcessor functions don't need to be [Custom]
https://bugs.webkit.org/show_bug.cgi?id=95899

Patch by Adam Barth <abarth@chromium.org> on 2012-09-06
Reviewed by Kentaro Hara.

Source/WebCore:

These functions are marked [Custom] because they predate our
improvements to [Optional]. Now that we have
[Optional=DefaultIsUndefined], we can autogenerate these functions.

There is a (slight!) difference in behavior. Now, in the case of a type
error, we return null instead of undefined. This change is unlikely to
cause compatibility problems because the vast majority of folks will
pass the correct arguments, and, in the few cases where folks pass the
wrong argument types, null and undefined will likely work similarly
(e.g., they're both falsy and throw when you try to access properties).

* bindings/js/JSXSLTProcessorCustom.cpp:
* bindings/v8/custom/V8XSLTProcessorCustom.cpp:
* xml/XSLTProcessor.cpp:
(WebCore::XSLTProcessor::transformToDocument):
(WebCore::XSLTProcessor::transformToFragment):
* xml/XSLTProcessor.h:
(WebCore::XSLTProcessor::importStylesheet):
* xml/XSLTProcessor.idl:

LayoutTests:

Update results to show that we return null rather than undefined on a
type error.

* fast/xsl/transform-xhr-doc-expected.txt:
* fast/xsl/xslt-processor-expected.txt:
* platform/chromium/fast/xsl/transform-xhr-doc-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127710 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Added modifiers to distinguish between left/right Shift/Ctrl/Alt in WebInputEvents
https://bugs.webkit.org/show_bug.cgi?id=94142

Patch by Raymes Khoury <raymes@chromium.org> on 2012-09-06
Reviewed by Tony Chang.

Previously we distinguished between left/right Shift/Ctrl/Alt in
WebInputEvents by using the location-specific virtual keycodes (e.g.
VK_LSHIFT instead of VK_SHIFT. However, the Windows API for key events
always returns the non-locational version (e.g. VK_SHIFT).
Furthermore, KeyboardEvent also returns
non-locational keycodes and separates the location information which
matches the behavior described in the DOM3
spec http://www.w3.org/TR/DOM-Level-3-Events/#events-keyboardevents. We
should be consistent with this in our representation of key events.
This patch changes WebInputEvents so they always store the
non-locational keycode and location information is stored in
modifiers. Since this only changes internal representation, no new
tests are added.

This patch also ensures that when KeyboardEvents are converted back to
WebInputEvents location information is preserved (which was not
happening before). This is important so that key location information
is passed on to plugins. A unittest is added for this.

* WebKit.gypi:
* public/WebInputEvent.h:
(WebKeyboardEvent):
* src/WebInputEvent.cpp:
(WebKit):
(WebKit::WebKeyboardEvent::windowsKeyCodeWithoutLocation):
(WebKit::WebKeyboardEvent::locationModifiersFromWindowsKeyCode):
* src/WebInputEventConversion.cpp:
(WebKit::PlatformKeyboardEventBuilder::PlatformKeyboardEventBuilder):
(WebKit::WebKeyboardEventBuilder::WebKeyboardEventBuilder):
* src/android/WebInputEventFactory.cpp:
(WebKit::WebInputEventFactory::keyboardEvent):
* src/gtk/WebInputEventFactory.cpp:
(WebKit::WebInputEventFactory::keyboardEvent):
* src/mac/WebInputEventFactory.mm:
(WebKit::WebInputEventFactory::keyboardEvent):
* src/win/WebInputEventFactory.cpp:
(WebKit::getLocationModifier):
(WebKit::WebInputEventFactory::keyboardEvent):
* tests/WebInputEventConversionTest.cpp: Added.

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