mpath elements do not clear resource lists before destruction
https://bugs.webkit.org/show_bug.cgi?id=101505

Reviewed by Abhishek Arya.

Source/WebCore:

The destructor for SVGMPathElement should clear its resources before
deletion, so as not to leave hanging pointers in resource lists.

Test: svg/animations/mpath-remove-from-dependents-on-delete-crash.html

* svg/SVGMPathElement.cpp:
(WebCore::SVGMPathElement::~SVGMPathElement): Add destructor that calls clearResourceReferences.
(WebCore):
* svg/SVGMPathElement.h:
(SVGMPathElement): Add destructor.

LayoutTests:

Test that causes a mpath element to be deleted before the path that it
references.

* svg/animations/mpath-remove-from-dependents-on-delete-crash-expected.html: Added.
* svg/animations/mpath-remove-from-dependents-on-delete-crash.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@134851 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Ignore autocomplete=off for chrome generated passwords.
https://bugs.webkit.org/show_bug.cgi?id=102426

Patch by Yue Zhang <zysxqn@google.com> on 2012-11-15
Reviewed by Adam Barth.

Record the autocomplete attribute in the web password form data,
so that we can handle autocomplete in chromium code. The
motivation/background is: we should ignore autocomplete=off field
for password forms with chrome generated passwords (has passed
security review). By handling autocomplete in chromium code we can
distinguish password forms with chrome generated passwords and
those normal password forms. Note that we haven't turned off
checking autocomplete=off in the Webkit code for now so there is
no behavior change after this CL, and we will turn off after we
make the chromium side change to be safe.

* public/WebPasswordFormData.h:
(WebPasswordFormData):
* src/WebPasswordFormData.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@134852 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Don't assert when notifyAuthReceived is called with a different auth type
https://bugs.webkit.org/show_bug.cgi?id=102436

Patch by Joe Mason <jmason@rim.com> on 2012-11-15
Reviewed by Rob Buis.

The server type could change if we contact a site taking HTTP auth, through an HTTP proxy
taking auth of its own. First we get a 407 from the proxy, and then when get past the
proxy, we get a 401 from the end site - so notifyAuthReceived gets called again with auth
type Proxy instead of HTTP.

The correct thing to do when that happens is skip the "update the auth type in the
credentials" step, since these are actually new credentials and not just credentials being
reused for a different auth type on the same server.

PR 241637

* platform/network/blackberry/NetworkJob.cpp:
(WebCore::NetworkJob::notifyAuthReceived):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@134853 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB setVersion-removal batch 7
https://bugs.webkit.org/show_bug.cgi?id=102415

Reviewed by Tony Chang.

* storage/indexeddb/mozilla/object-store-remove-values-expected.txt:
* storage/indexeddb/mozilla/readyState-expected.txt:
* storage/indexeddb/mozilla/resources/object-store-remove-values.js:
* storage/indexeddb/mozilla/resources/readyState.js:
  Moved one check into shared.js, a few others around, and the check
  for setVersion's request.readyState==pending is deleted.

* storage/indexeddb/mozilla/resources/versionchange-abort.js:
  First test I've converted that makes the initial open fail, but
  request.onsuccess is unhooked to not cause the whole test to fail.

(prepareDatabase):
(postAbort):
* storage/indexeddb/mozilla/versionchange-abort-expected.txt:
* storage/indexeddb/objectstore-basics-expected.txt:
* storage/indexeddb/objectstore-basics-workers-expected.txt:
* storage/indexeddb/odd-strings-expected.txt:
* storage/indexeddb/readonly-expected.txt:
* storage/indexeddb/resources/objectstore-basics.js:
* storage/indexeddb/resources/odd-strings.js:
* storage/indexeddb/resources/readonly.js:
  Moved the checks at the beginning to the end of the test, but
  everything was preserved.

* storage/indexeddb/resources/shared.js:
  Moved a check from readyState to here as the readyState layout test
  doesn't have access to the open request before any events are fired.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@134854 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Win] key event's location does not work on Windows platform.
https://bugs.webkit.org/show_bug.cgi?id=89742

Patch by Takashi Sakamoto <tasak@google.com> on 2012-11-15
Reviewed by Brent Fulgham.

As WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, and WM_SYSKEYUP doesn't
directly provide a virtual keycode which distinguish between left-hand
and right-hand keys. To obtain a virtual keycode, we have to look at
lparam, i.e. scancode and extended key bit. So if the given virtual
keycode is control, shift, or menu, use MapVirtualKey with scancode and
extended key bit and recreate a virtual keycode which distinguishes
between left-hand and right-hand.

No new tests, because left-hand keys, right-hand keys layout tests
have been already added.

* platform/win/KeyEventWin.cpp:
(WebCore::windowsKeycodeWithLocation):
Use wparam and lparam to recreate a virtual keycode which distinguishes
between left-hand and right-hand if the given wparam (=virtual keycode)
is control, shift, or menu.
(WebCore):
(WebCore::PlatformKeyboardEvent::PlatformKeyboardEvent):
Use the newly added function to obtain windows virtual keycode.


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