Revert the portion of r56489 that dealt with port zero as it introduced some test failures.

WebCore:

platform/KURL.cpp:

(WebCore::KURL::port): Use the "ok" argument to charactersToUIntStrict to determine whether
it was able to successfully parse the string as an unsigned integer, rather than relying on
the fact it returned zero when it failed.

Fixes the following error when committing a file with
"ChangeLog" in the name that isn't a ChangeLog (like
mergeChangeLogs.pl from r56471 and r56472):

$ git commit .
Can't open WebKitTools/Scripts/webkitperl/VCSUtils_unittest/mergeChangeLog at commit-log-editor line 132.
error: There was a problem with the editor 'commit-log-editor'.
Please supply the message using either -m or -F option.

Scripts/commit-log-editor: Added '$' to anchor "ChangeLog" to

the end of the file name when searching for ChangeLog files in a
commit.

Switch String::latin1, String::utf8, String::fromUTF8 to
use WTF's Unicode conversion methods rather than TextEncoder.
These methods only perform simple conversion, and don't need
really require TextEncoder's full capability (to look up arbitrary
encodings by name), switching to only be dependent on WTF will
make it easier if we chose to move WebCore::String to WTF.

Switch String::latin1, String::utf8, String::fromUTF8 to
use WTF's Unicode conversion methods rather than TextEncoder.
These methods only perform simple conversion, and don't need
really require TextEncoder's full capability (to look up arbitrary
encodings by name), switching to only be dependent on WTF will
make it easier if we chose to move WebCore::String to WTF.

Switch String::latin1, String::utf8, String::fromUTF8 to
use WTF's Unicode conversion methods rather than TextEncoder.
These methods only perform simple conversion, and don't need
really require TextEncoder's full capability (to look up arbitrary
encodings by name), switching to only be dependent on WTF will
make it easier if we chose to move WebCore::String to WTF.

Plugins/Hosted/NetscapePluginHostProxy.h:
(WebKit::NetscapePluginHostProxy::port): Assert that the object is still alive. This isn't
beautifully systemic, but helped catch a bug, and may help catch more.
(WebKit::NetscapePluginHostProxy::clientPort): Ditto.
(WebKit::NetscapePluginHostProxy::isProcessingRequests): Changed m_processingRequests to a
static. This doesn't change behavior much, but helps avoid writing into deallocated memory.

Plugins/Hosted/NetscapePluginHostProxy.mm:
(WebKit::NetscapePluginHostProxy::NetscapePluginHostProxy): Changed m_processingRequests
to a static.
(WebKit::NetscapePluginHostProxy::processRequests): Ditto. Changing m_processingRequests
after destroying the object in pluginHostDied() was wrong, but reasonably harmless, as there
wasn't much time for some other object to be allocated at this address.
(WKPCEvaluate): Refetch host proxy, as it may have been destroyed.
(WKPCInvoke): Ditto.
(WKPCInvokeDefault): Ditto.
(WKPCGetProperty): Ditto.
(WKPCSetProperty): Ditto.
(WKPCRemoveProperty): Ditto.
(WKPCHasProperty): Ditto.
(WKPCHasMethod): Ditto.
(WKPCEnumerate): Ditto.
(WKPCRunSyncOpenPanel): Ditto.

Plugins/Hosted/NetscapePluginInstanceProxy.mm:
(WebKit::NetscapePluginInstanceProxy::processRequestsAndWaitForReply): Bail out of the
"event loop" if host proxy went away while processing a request.

When resolve-ChangeLogs fails to merge a patch while running as
a git merge driver, it deletes the original file, which causes
an internal failure and stops git mid-merge:

fatal: Failed to execute internal merge

The fix is to use the --force switch with patch so that it will
always attempt to apply the patch. (The change in
mergeChangeLogs() for the previous commit also fixed this, but
adding --force also prevents any potential user interaction that
patch may want to display.)

Scripts/VCSUtils.pm:

(mergeChangeLogs): Added --force switch to patch command. Also
changed to use the exit status from the patch command to
determine the return value for this method.

(mergeChangeLogs): Copied from mergeChanges() in
resolve-ChangeLogs and renamed. Added method documentation.
Fixed bug found by new tests where the original file to be
patched was deleted when cleaning up after a traditinal rejected
patch failed to apply.

Scripts/resolve-ChangeLogs: Switched to using

mergeChangeLogs().
(mergeChanges): Moved to VCSUtils.pm and renamed to
mergeChangeLogs().

Recent r56445 added CustomEvent and a test but it didn't work on Chromium bots.
Test crashed due to infinte recursion because the compiler did not have the right definition of toV8(CustomEvent*)
and was substituting toV8(Event*).

No new tests, but this shows up in tests of Database accesses from the
Worker thread that I'll be checking in soon. The symptom is that
DOMCoreException.toString() returns [object DOMException] instead of
something more helpful.

fast/workers/worker-context-multi-port-expected.txt: Adjusted expectation that was depending on the broken behavior.

No new tests, but this shows up in tests of Database accesses from the
Worker thread that I'll be checking in soon. The symptom is that
DOMCoreException.toString() returns [object DOMException] instead of
something more helpful.

Despite WebKit (and Skia, to an extent) supporting non-integral
glyph widths, the font code path we hit in Skia only supports
integral glyph positions. This means that we would accumulate
offsets when drawing a sequence up non-integer-width glyphs
which would cause gaps when snapped to the pixel grid when drawing.

<rdar://problem/7785305>
Fix regression caused by r55576. It turned out that ensuring
CoreAnimation always gets a correct fill parameter caused flashing
as non-filled animations ended (CA briefly showed the initial animation
value before the style system set the final value).

Prepartory changes to allow for an OffscreenCanvas which may be used in a worker
or outside of the DOM.

No change in functionality, so new tests.

dom/CanvasSurface.cpp: Moved functionality that CanvasRenderingContext2D depends on

into this class (and removed dependencies on document/html element).
(WebCore::CanvasSurface::CanvasSurface):
(WebCore::CanvasSurface::~CanvasSurface): Put the desctructor in the cpp file
to avoid needing access to ~ImageBuffer in the header file.
(WebCore::CanvasSurface::setSurfaceSize): Does basic items needed
when the size changes. It is protected to force outside callers to go
through HTMLCanvasElement::setSize.
(WebCore::CanvasSurface::toDataURL): Just moved from HTMLCanvasElement and
made a note about a method to fix for worker usage.
(WebCore::CanvasSurface::willDraw): Made this virtual to allow an overide
which uses the renderbox and tracks a dirtyRect.
(WebCore::CanvasSurface::convertLogicalToDevice): Moved and changed to
rely on a member variable for page scale (to avoid using the document).
(WebCore::CanvasSurface::createImageBuffer):
(WebCore::CanvasSurface::drawingContext): Simple move from HTMLCanvasElement.
(WebCore::CanvasSurface::buffer): Ditto.
(WebCore::CanvasSurface::baseTransform): Ditto.

(WebCore::HTMLCanvasElement::HTMLCanvasElement): Pass in the scale factor to CanvasSurface
so it doesn't need the document.
(WebCore::HTMLCanvasElement::willDraw): Moved the relevant portion to CanvasSurface.
(WebCore::HTMLCanvasElement::reset): Small changes due to refactoring.
(WebCore::HTMLCanvasElement::paint): Ditto.

html/HTMLCanvasElement.h:

(WebCore::HTMLCanvasElement::setSize): Ditto.

platform/MIMETypeRegistry.cpp:

(WebCore::MIMETypeRegistry::isSupportedImageMIMETypeForEncoding): Added assert
to verify that this is only called on the main thread.

Since [ ​http://trac.webkit.org/changeset/35917 ], calling
JSGlobalContextRelease always triggers a GC heap collection
(if not a full destroy). As per 35917's changelog "This is
only really necessary when the (JSGlobalObject's) last
reference is released, but there is no way to determine that,
and no harm in collecting slightly more often."

Well, we now know of cases of API clients who are harmed by
the performance penalty of collecting too often, so it's time
to add a way to determine whether a call to JSGlobalContextRelease
is removing the last protect from it's global object. If further
protects are retaining the global object (likely from other
JSGlobalContextRefs), then don't trigger a GC collection.

API/JSContextRef.cpp:

runtime/Collector.cpp:

(JSC::Heap::unprotect): return a boolean indicating that the value is now unprotected.

runtime/Collector.h:

wtf/HashCountedSet.h:

(WTF::::remove): return a boolean indicating whether the value was removed from the set.

Since [ ​http://trac.webkit.org/changeset/35917 ], calling
JSGlobalContextRelease always triggers a GC heap collection
(if not a full destroy). As per 35917's changelog "This is
only really necessary when the (JSGlobalObject's) last
reference is released, but there is no way to determine that,
and no harm in collecting slightly more often."

Well, we now know of cases of API clients who are harmed by
the performance penalty of collecting too often, so it's time
to add a way to determine whether a call to JSGlobalContextRelease
is removing the last protect from it's global object. If further
protects are retaining the global object (likely from other
JSGlobalContextRefs), then don't trigger a GC collection.

API/JSContextRef.cpp:

runtime/Collector.cpp:

(JSC::Heap::unprotect): return a boolean indicating that the value is now unprotected.

runtime/Collector.h:

wtf/HashCountedSet.h:

(WTF::::remove): return a boolean indicating whether the value was removed from the set.

Since [ ​http://trac.webkit.org/changeset/35917 ], calling
JSGlobalContextRelease always triggers a GC heap collection
(if not a full destroy). As per 35917's changelog "This is
only really necessary when the (JSGlobalObject's) last
reference is released, but there is no way to determine that,
and no harm in collecting slightly more often."

Well, we now know of cases of API clients who are harmed by
the performance penalty of collecting too often, so it's time
to add a way to determine whether a call to JSGlobalContextRelease
is removing the last protect from it's global object. If further
protects are retaining the global object (likely from other
JSGlobalContextRefs), then don't trigger a GC collection.

API/JSContextRef.cpp:

runtime/Collector.cpp:

(JSC::Heap::unprotect): return a boolean indicating that the value is now unprotected.

runtime/Collector.h:

wtf/HashCountedSet.h:

(WTF::::remove): return a boolean indicating whether the value was removed from the set.

(WebCore::WidgetPrivate::WidgetPrivate): Added previousVisibleRect.
(WebCore::Widget::setFrameRect): If the visible rect changed but the
frame rect did not, send a -visibleRectDidChange message to the view,
if it responds to it.
(WebCore::Widget::releasePlatformWidget): Reset previousVisibleRect.

rendering/RenderWidget.cpp:

(WebCore::RenderWidget::setWidgetGeometry): Track changes to the clip rect
imposed by the enclosing layer. Call Widget::setFrameRect when it changes,
even if the frame rect did not.

Fix another cause of assertions related to the clip rects root. Embeds
with zero size caused the overlap testing to fail, yet we require them to work
for correct compositing, so when the composited bounds is empty, use a 1x1 rect
for overlap testing.

runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSplice): We were incorrectly computing
the start offset, and iterated over (almost) all integers. Note that this can be fixed
without using doubles, but the code would be much more complicated, and there is no important
reason to stick to integers here.

(WebCore::isDocumentType): Unrelated style fix: fixed the casing of the method.
(WebCore::V8XMLHttpRequest::sendCallback): Added check for null/undefined to do the send.
This mirrors what is done in the JSC bindings. Previously, sending 'null' worked because
the last case, which did "toWebCoreStringWithNullCheck", resulted in sending an empty
request body.

LayoutTests:

Added a test to verify that sending either undefined and null both result in an empty request body.

LayoutTests: Add test for crash due to calling into libxml in invalid state. Note
that it is unlikely that this will actually crash for you in the test
environment because it is highly intermittent. However, adding test in
order to exercise the code path and prevent related regression.
See ​https://bugs.webkit.org/show_bug.cgi?id=36000

Changes needed to implement Show/Hide Controls command for <video> in
chrome: (1) added Controls action in WebMediaPlayerAction that toggles
controls for media player, (2) added MediaHasVideo in
WebContextMenuData so that controls can be made toggleable only for
video player but not for audio.​https://bugs.webkit.org/show_bug.cgi?id=36460

Import the GNU readline interface to modify the behavior
of raw_input so as to provide line editing support. In
particular this will prevent "delete" characters from
appearing in the returned value for function raw_input.

dom/DOMImplementation.cpp: Removed unneeded createDocument and
createHTMLDocument functions. These should be done directly instead
of involving the DOMImplementation class.

dom/DOMImplementation.h: Ditto.

dom/DocumentType.cpp: Removed unneeded include of DOMImplementation.h.

html/HTMLViewSourceDocument.cpp:
(WebCore::HTMLViewSourceDocument::createTokenizer): Don't allocate a
DOMImplementation object just to use a class member function.

loader/CachedFont.cpp: Removed unneeded include of DOMImplementation.h.

xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::responseXML): Use Document::create to create a
new document instead of involving DOMImplementation.

xml/XSLTProcessor.cpp:
(WebCore::XSLTProcessor::createDocumentFromSource): Ditto. And in the case
where we do need to call DOMImplementation to interpret the MIME type,
don't allocate a DOMImplementation object just to use a class member
function.

Change notification sent to inspector frontend on workers creation / destruction
to be posted asynchronously to avoid JS reenterability problems. Also, renamed
willDestroyWorker to didDestroyWorker to reflect that it gets called later and got
rid of explicit IDs for workers (use addresses instead).​https://bugs.webkit.org/show_bug.cgi?id=36213

(JSC::Interpreter::privateExecute): Only take the fast negate path if
a bit other than bit 31 is set. If none of bits 0-30 are set, then the
value we're negating can only be 0 or -2147483648, and neither can be
negated in int space.

(WebCore::XMLHttpRequest::XMLHttpRequest): Created the throttle.
(WebCore::XMLHttpRequest::callReadyStateChangeListener): The 'readyState' event are
dispatched using the XMLHttpRequestProgressEventThrottle now. For the DONE state, we
need to flush any pending progress event as we do not want it to be dispatched after
the DONE readyState event.
(WebCore::XMLHttpRequest::createRequest): Made this event use the
XMLHttpRequestProgressEventThrottle for event dispatching.
(WebCore::XMLHttpRequest::abort): Ditto.
(WebCore::XMLHttpRequest::networkError): Ditto.
(WebCore::XMLHttpRequest::abortError): Ditto.
(WebCore::XMLHttpRequest::didReceiveData): Ditto. Also fixed a potential warning.
(WebCore::XMLHttpRequest::suspend):
(WebCore::XMLHttpRequest::resume): Implemented the logic for suspend / resume.

xml/XMLHttpRequest.h:

xml/XMLHttpRequestProgressEventThrottle.cpp: Added.

(WebCore::XMLHttpRequestProgressEventThrottle::XMLHttpRequestProgressEventThrottle):
(WebCore::XMLHttpRequestProgressEventThrottle::~XMLHttpRequestProgressEventThrottle):
(WebCore::XMLHttpRequestProgressEventThrottle::dispatchProgressEvent): Implemented the bulk
of the event throttling here: we use a timer to do so, as long as the timer is active it means
that events are coming faster than the throttling time and we coalesce them.
(WebCore::XMLHttpRequestProgressEventThrottle::dispatchEvent): Generic method to dispatch an event.
(WebCore::XMLHttpRequestProgressEventThrottle::flushProgressEvent): Called when we want to dispatch
any pending events and stopping any further dispatching.
(WebCore::XMLHttpRequestProgressEventThrottle::dispatchPausedEvent): Used to dispatch the event
that was queued due to the object being suspended.
(WebCore::XMLHttpRequestProgressEventThrottle::fired): Used to dispatch any coalesced event.
(WebCore::XMLHttpRequestProgressEventThrottle::hasEventToDispatch): Used to check if we have
an event to dispatch.
(WebCore::XMLHttpRequestProgressEventThrottle::suspend): Marked the object as suspended.
(WebCore::XMLHttpRequestProgressEventThrottle::resume): Dispatched the event that was queued.

Introduce HTMLFormControlElement::m_willValidate and
m_isValid. They are the caches of willValidate() and
isValidFormControlElement(). setNeedsWillValidateCheck() updates
m_willValidate and setNeedsValidityCheck() updates m_isValid.

willValidate() and isValidFormControlElement() have assertions to
check m_willvalidate or m_isValid has the correct state. If
setNeedsWillValidateCheck() or setNeedsValidityCheck() is needed
to be called and is not called, these assertions fail.

This change adds a sourceLine field into the CSSStyleRule that is populated
from within the parser. CSSParser is now keeping track of the line numbers
and last selector line number that is being used while creating CSSStyleRules.

Added WebGraphicsContext3D to the WebKit API and refactored Chromium's
GraphicsContext3D implementation to use it. All of the OpenGL calls have
been moved out of WebKit/chromium/src/GraphicsContext3D.cpp and into the
WebGraphicsContext3D implementation. GraphicsContext3D is still
responsible for the transfer of rendered output from the
WebGraphicsContext3D to the HTMLCanvasElement.

The GraphicsContext3DInternal class, which is a data member of
GraphicsContext3D for the Chromium port, remains. It is possible to
eliminate this class and thereby one level of delegation, but this is
being deferred.

The needed entry point for a Chrome implementation of
WebGraphicsContext3D has been added to WebKitClient, but it is not being
called yet by GraphicsContext3D. It will be once this patch lands and
Chromium is rolled forward to support this entry point.

This is a large patch, but the transformation is almost entirely
mechanical and there is no change in functionality. Nearly all of
GraphicsContext3D and GraphicsContext3DInternal has been moved to
WebGraphicsContext3DDefaultImpl. The only area where the splitting of
logic is less than mechanical is GraphicsContext3D::beginPaint() and its
callees.

Ran all WebGL layout tests and demos from Khronos site in Chromium
on Mac and Windows.

Change baseline_path() to point to the upstream locations for the
Chromium ports. Also change the reabselining scripts to use the
correct functions to get the baseline directories, and fix the
script's sys.path to pull in simplejson correctly.

No tests, because crashing on build bots isn't good, even if it's only helper processes
that crash.

Plugins/Hosted/NetscapePluginInstanceProxy.h:
(WebKit::NetscapePluginInstanceProxy::waitForReply): Protect "this", because this function
needs it after waiting for reply. Some callers used to do this, but not all, and we really
shouldn't depend on callers here.

Plugins/Hosted/NetscapePluginInstanceProxy.mm:
(WebKit::NetscapePluginInstanceProxy::wheelEvent): Don't protect the plug-in instance proxy,
because this function doesn't use it after waiting for reply.
(WebKit::NetscapePluginInstanceProxy::createBindingsInstance): Ditto.

(JSC::MacroAssemblerX86Common::branchNeg32): Added a branching version
of the negate operator.

jit/JITArithmetic.cpp:

(JSC::JIT::emit_op_negate): Use the branching version of the negate
operator to check for overflow.

(JSC::JIT::emitSlow_op_negate): Link the check for overflow to a slow case.
(We could emit inline code for this, since we know what the result would
be, but that's probably just a waste of generated code.)

New class was created; the QScriptSyntaxCheckResult which main
responsibility is to provide results of the ECMA Script code
syntax check. The class is not fully functional as the JSC C API
doesn't expose an error column number, but it is a good start point
for a future development.

This function allows us to get the module-specific logger for
a module without having to hard-code the fully-qualified name
of the module in the module itself. The code can be the same
in every case: "_log = logutils.get_logger(file)".

Scripts/webkitpy/init/logutils.py: Added.

Added a module with a get_logger() function to return
a module-specific logger based on the module's file
variable.

The case where the list of source and target transform operations are
not the same but have the same size needs to be special-cased in
GraphicsLayerQt, as well as the case where the source or target
operation list is empty. The URLs listed here render correctly after
applying the patch.