Get rid of NetworkResourceLoader::sendAbortingOnFailure
https://bugs.webkit.org/show_bug.cgi?id=161267

Reviewed by Dan Bernstein.

NetworkResourceLoader::sendAbortingOnFailure sends an IPC message, and if IPC::Connection::send returns false,
it will abort the network resource load.

IPC::Connection::send will only return false if the connection is invalid, and when it becomes invalidated the
connection client member function "didClose" is invoked. For the network process, this will call abort on all outstanding
network loads.

Auditing all the sendAbortingOnFailure call sites, shows that none of them can be called with an invalid connection,
so replace sendAbortingOnFailure with send.

* NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::didReceiveResponse):
This is a NetworkLoadClient function which won't be called if the load has been aborted.

(WebKit::NetworkResourceLoader::didReceiveBuffer):
Ditto.

(WebKit::NetworkResourceLoader::didFinishLoading):
Ditto. Also, update a call to sendBufferMaybeAborting to sendBuffer.

(WebKit::NetworkResourceLoader::willSendRedirectedRequest):
This is another NetworkLoadClient function.

(WebKit::NetworkResourceLoader::bufferingTimerFired):
The buffering timer is stopped when abort() is called.

(WebKit::NetworkResourceLoader::sendBuffer):
Rename this from sendBufferMaybeAborting. It has three call sites:
- didReceiveBuffer and didFinishLoading are both NetworkLoadClient functions.
- didRetrieveCacheEntry is called from didFinishLoading (a NetworkLoadClient function) and from
the completion function of retrieveCacheEntry, which has an early return for when the loader has been aborted.

(WebKit::NetworkResourceLoader::didRetrieveCacheEntry):
This is called from the retrieveCacheEntry completion function, which has an early return for when the loader has been aborted.

charactersAroundPosition can be wrong because it crosses editing boundaries
https://bugs.webkit.org/show_bug.cgi?id=161215
-and corresponding-
rdar://problem/27933564

Reviewed by Ryosuke Niwa.

Source/WebCore:

charactersAroundPosition() should not cross editing boundaries. This patch fixes
that by making nextCharacterBoundaryInDirection() take an
EditingBoundaryCrossingRule parameter to pass onto VisiblePosition::next() and
VisiblePosition::previous().

This test is going back to its pre-https://trac.webkit.org/changeset/195078 state.
That change caused this test to have a different layout because it caused more
layouts to happen. Now that we don’t allow the call to charactersAroundPosition()
to cross editing boundaries, those layouts don’t happen, and we have the old
behavior back.
* platform/mac/fast/dom/focus-contenteditable-expected.txt:

* UserInterface/Views/IndexedDatabaseDetailsSidebarPanel.js: Added.
(WebInspector.IndexedDatabaseDetailsSidebarPanel):
(WebInspector.IndexedDatabaseDetailsSidebarPanel.prototype.inspect):
(WebInspector.IndexedDatabaseDetailsSidebarPanel.prototype.layout):
(WebInspector.IndexedDatabaseDetailsSidebarPanel.prototype._keyPathString):
Show the sidebar for an IndexedDatabase, ObjectStore, or Index.
Show each section if we can based on the objects we have.

Web Inspector: HeapProfiler/ScriptProfiler do not destruct safely when JSContext is destroyed
https://bugs.webkit.org/show_bug.cgi?id=161027
<rdar://problem/27871349>

Reviewed by Mark Lam.

For JSContext inspection, when a frontend connects keep the target alive.
This means ref'ing the JSGlobalObject / VM when the first frontend
connects and deref'ing when the last frontend disconnects.

* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
(Inspector::JSGlobalObjectInspectorController::disconnectAllFrontends): Deleted.
Now that frontends keep the global object alive, when the global object
is destroyed that must mean that no frontends exist. Remove the now
stale code path.

(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
Ref the target when the first frontend connects, deref when the last disconnects.

This patch adds a new Method table function toStringName. This function
is used by Object.prototype.toString to create the string tag that it
inserts. Right now it only changes the stringification of proxy objects.
In future patches I plan to make it work for other classes of objects as
well.

In r204779, MathMLAnnotationElement was made a MathMLRowElement just because the
annotation-xml element is generating a RenderMathMLRow. This later point is actually not
needed since annotation-xml is just a wrapper for foreign elements and so does not need to
handle special MathML features like operator spacing or stretching. We can thus move back
MathMLAnnotationElement to a generic MathMLPresentationElement and instead make the
annotation-xml element generate a generic RenderMathMLBlock renderer.

No new tests, semantics annotations already covered by existing tests.

* platform/efl/accessibility/math-foreign-content-expected.txt: Remove the AXGroup from the
test expectation, which that was used for annotation-xml.
* platform/gtk/accessibility/math-foreign-content-expected.txt: Ditto.
* platform/mac/accessibility/math-foreign-content-expected.txt: Ditto.

[GTK] run-gtk-tests should use the driver environment for checking the accessibility bus
https://bugs.webkit.org/show_bug.cgi?id=161149

Reviewed by Carlos Garcia Campos.

Add a new function for waiting for the accesibility bus. It sets
the test environment variables before starting the GLib mainloop.
And restores the previous environment after it has finished.
It also adds a timeout (5 seconds) to abort in case it has not
been able to detect the accesibility bus before the timeout expires.

* Scripts/run-gtk-tests:
(TestRunner):
(TestRunner._wait_for_accessibility_bus):
(TestRunner._wait_for_accessibility_bus.timeout_accessibility_bus):
(TestRunner._start_accessibility_daemons):
(TestRunner._get_tests_from_google_test_suite): Run this command also with the driver test environment.

[GTK] run-gtk-tests should use webkitpy.port.gtk and webkitpy.port.xvfbdriver
https://bugs.webkit.org/show_bug.cgi?id=160736

Reviewed by Carlos Garcia Campos.

This plugs run-gtk-tests into the webkitpy testing infrastructure.
As a benefit of this, run-gtk-tests now can be executed over any of
the existing supported gtk test display servers (xvfb, weston-over-xvfb,
or native xorg). A new command line switch --wayland is added for
run-gtk-tests.

* Scripts/run-gtk-tests:
(TestRunner.__init__): Remove the --display command line switch, its not longer useful.
Add a --wayland command line switch.
(TestRunner._start_accessibility_daemons):
(TestRunner):
(TestRunner.__init__):
(TestRunner._run_xvfb): Deleted.
(TestRunner._create_driver):
(TestRunner._setup_testing_environment): Delete the environment variable definitions that
are now done by driver._setup_environ_for_test().
(TestRunner._tear_down_testing_environment):
* Scripts/webkitpy/port/driver.py:
(Driver.__init__): Define self._server_name in the constructor of the base class.
It is used by several functions, so it makes sense to store once the value here.
(Driver._setup_environ_for_test): Factorize setting the environment for a given test.
(Driver._start): Get the environment from self._setup_environ_for_test()
* Scripts/webkitpy/port/driver_unittest.py:
(DriverTest):
(DriverTest.test_setup_environ_for_test): Add unittest for driver._setup_environ_for_test()
* Scripts/webkitpy/port/gtk.py: Move the inspection of the env var USE_NATIVE_XDISPLAY to the constructor.
(GtkPort.__init__):
(GtkPort._driver_class):
* Scripts/webkitpy/port/westondriver.py: Define and use self._setup_environ_for_test()
(WestonDriver._setup_environ_for_test):
(WestonDriver._start):
* Scripts/webkitpy/port/xorgdriver.py: Define and use self._setup_environ_for_test()
(XorgDriver._setup_environ_for_test):
(XorgDriver._start):
* Scripts/webkitpy/port/xvfbdriver.py: Define and use self._setup_environ_for_test()
(XvfbDriver._setup_environ_for_test):
(XvfbDriver._start):

EWS should indicate which bot processed the patch
https://bugs.webkit.org/show_bug.cgi?id=161222

Reviewed by Daniel Bates.

* QueueStatusServer/handlers/statusbubble.py:
(StatusBubble._build_bubble): Display the bot id in status bubble. Also removed "Started processing" message since
after bug fix of 161223, bots send the "Started processing patch" message and it would be displayed in Recent messages.
Also added "Started processing patch" message to progress_statuses.
I might consider displaying bot id in other statuses as well later on.

Add assertion to check DOMConstructorObject* passed in ExecState is not null.
Rename throwConstructorDocumentUnavailableError to throwConstructorScriptExecutionContextUnavailableError since
ScriptExecutionContext is not necessarily a Document.
Modify error message in case of argument error to be consistent with generated binding code: replace calls to
throwVMError with calls to throwConstructorScriptExecutionContextUnavailableError and throwArgumentTypeError.

No new test required. Modify tests and tests expectations to align with new error messages.

This patch introduces DFG and FTL support for ES6 generators.
ES6 generator is compiled by the BytecodeGenerator. But at the last phase, BytecodeGenerator performs "generatorification" onto the unlinked code.
In BytecodeGenerator phase, we just emit op_yield for each yield point. And we don't emit any generator related switch, save, and resume sequences
here. Those are emitted by the generatorification phase.

So the graph is super simple! Before the generatorification, the graph looks like this.

op_enter -> ...... -> op_yield -> ..... -> op_yield -> ...

Roughly speaking, in the generatorification phase, we turn out which variables should be saved and resumed at each op_yield.
This is done by liveness analysis. After that, we convert op_yield to the sequence of "op_put_to_scope", "op_ret", and "op_get_from_scope".
op_put_to_scope and op_get_from_scope sequences are corresponding to the save and resume sequences. We set up the scope for the generator frame and
perform op_put_to_scope and op_get_from_scope onto it. The live registers are saved and resumed over the generator's next() calls by using this
special generator frame scope. And we also set up the global switch for the generator.

In the generatorification phase,

1. We construct the BytecodeGraph from the unlinked instructions. This constructs the basic blocks, and it is used in the subsequent analysis.
2. We perform the analysis onto the unlinked code. We extract the live variables at each op_yield.
3. We insert the get_from_scope and put_to_scope at each op_yield. Which registers should be saved and resumed is offered by (2).
Then, clip the op_yield themselves. And we also insert the switch_imm. The jump targets of this switch are just after this op_switch_imm and each op_yield point.

One interesting point is the try-range. We split the try-range at the op_yield point in BytecodeGenerator phase.
This drops the hacky thing that is introduced in [1].
If the try-range covers the resume sequences, the exception handler's use-registers are incorrectly transferred to the entry block.
For example,

Handler's r2 use should be considered at the `r1 = get_from_scope` point.
Previously, we handle this edge case by treating op_resume specially in the liveness analysis[1].
To drop this workaround, we split the try-range not to cover this resume sequence.

The rewriting done by the BytecodeRewriter is executed in a batch manner. Since these modification changes the basic blocks and size of unlinked instructions,
BytecodeRewriter also performs the offset adjustment for UnlinkedCodeBlock. So, this rewriting is performed onto the BytecodeGraph rather than BytecodeBasicBlock.
The reason why we take this design is simple: we don't want to newly create the basic blocks and opcodes for this early phase like DFG. Instead, we perform the
modification and adjustment to the unlinked instructions and UnlinkedCodeBlock in a in-place manner.

Bytecode rewriting functionality is offered by BytecodeRewriter. BytecodeRewriter allows us to insert any bytecodes to any places
in a in-place manner. BytecodeRewriter handles the original bytecode offsets as labels. And you can insert bytecodes before and after
these labels. You can also insert any jumps to any places. When you insert jumps, you need to specify jump target with this labels.
These labels (original bytecode offsets) are automatically converted to the appropriate offsets by BytecodeRewriter.

After that phase, the data flow of the generator-saved-and-resumed-registers are explicitly represented by the get_from_scope and put_to_scope.
And the switch is inserted to represent the actual control flow for the generator. And op_yield is removed. Since we use the existing bytecodes (op_switch_imm, op_put_to_scope
op_ret, and op_get_from_scope), DFG and FTL changes are not necessary. This patch also drops data structures and implementations for the old generator,
op_resume, op_save implementations and GeneratorFrame.

Note that this patch does not leverage the recent multi entrypoints support in B3. After this patch is introduced, we will submit a new patch that leverages the multi
entrypoints for generator's resume and sees the performance gain.

The CString returned by String::utf8 was going out of scope before we were doing a string comparison on its data.
This just does the comparison of the CStrings instead to keep them in scope during the comparison.

Dragging against the end of the inline media scrubber causes the media scrubber to hide
https://bugs.webkit.org/show_bug.cgi?id=161207

Reviewed by Eric Carlson.

Source/WebCore:

Previously, we would re-enable behavior restrictions when firing an ended event. However, if the ended event is
caused by the user seeking to the end of the video, the media controls would be taken away from under the user.
To prevent this, we don't add the relevant behavior restrictions upon media ended if media was seeking before
firing the event.

Tweaks an existing WebKit API test covering this behavior change. After some discussion, rather than hide media
controls in this case, we should actually continue showing them. This is because seeking due to user gestures
similar to "scrubbing" are indistinguishable from gestures that immediately seek to the end.

REGRESSION: RELEASE_ASSERT in ResourceUsageThread::platformThreadBody when ASan is enabled
<https://webkit.org/b/161203>
<rdar://problem/28011251>

Reviewed by Joseph Pecoraro.

* page/cocoa/ResourceUsageThreadCocoa.mm:
(WebCore::ResourceUsageThread::platformThreadBody): Remove overly optimistic assertions about
"GC owned" memory never being higher than total malloc memory usage. This accounting is not
really exact and pretending otherwise will just lead to crashes.

REGRESSION (r203378): [iOS] The PDF image is rendered stretched if a sub image of it is cached first
https://bugs.webkit.org/show_bug.cgi?id=160617

Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2016-08-25
Reviewed by Tim Horton.

Source/WebCore:

When caching only a sub-image of the PDF ensure the source rectangle starts
at the top-left of the cached sub-image rectangle. When drawing the cached
sub-image to the destination context ensure the destination rectangle is the
sub-image rectangle so no stretching or shrinking happens.

Test: fast/images/cached-clipped-pdf.html

* page/Settings.cpp:
(WebCore::Settings::Settings):
(WebCore::Settings::setCachedPDFImageEnabled): Deleted.
* page/Settings.h:
(WebCore::Settings::isCachedPDFImageEnabled): Deleted.
* page/Settings.in:
Change the boolean setting CachedPDFImageEnabled to be enum property and
rename it PDFImageCachingPolicy. Allow the "PDFImageCachingBelowMemoryLimit"
option to be available on a;; platforms. The "PDFImageCachingClipBoundsOnly"
option is added for testing purpose. If forces recaching the PDF with each
draw and it sets the cached image rectangle to the clipping rectangle.

* platform/graphics/cg/PDFDocumentImage.cpp:
(WebCore::PDFDocumentImage::setPdfImageCachingPolicy): Take an enum instead of boolean.
(WebCore::cachedImageRect):
(WebCore::PDFDocumentImage::decodedSizeChanged): Enable PDFImageCachingBelowMemoryLimit
on all platforms.
(WebCore::PDFDocumentImage::updateCachedImageIfNeeded): Fix the source rectangle
when caching a sub-image of the PDF.
(WebCore::PDFDocumentImage::draw): Fix the destination rectangle when drawing
a sub-image to the destination context.
(WebCore::PDFDocumentImage::setCachedPDFImageEnabled): Deleted.
* platform/graphics/cg/PDFDocumentImage.h:

Update the Resource Timing implementation for better compatibility with the Resource Timing API spec.
Use LoadTiming for general timing information about a resources load timeline.
Mark timestamps for newly loaded resources as well as cached resources.

* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::startLoadingMainResource):
StartTime and fetchStart should be equal initially.

* loader/ResourceTimingInformation.cpp:
(WebCore::ResourceTimingInformation::addResourceTiming):
* loader/ResourceTimingInformation.h:
Only pass in the URL from the ResourceRequest.
Pass LoadTiming instead of timestamps.

(WebCore::SubresourceLoader::didFinishLoading):
Mark the responseEnd timestamp.
Add the ResourceEntry to the timeline before notifyDone is called.

* loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestResource):
(WebCore::CachedResourceLoader::revalidateResource):
(WebCore::CachedResourceLoader::loadDone):
Mark timestamps for cached resources and use them instead of a cached LoadTiming.

* resources/testharnessreport.js:
(self.testRunner.add_completion_callback):
Updated completion callback to wait for any other completion callbacks
before finishing, so the Resource Timing tests can cleanup first.
Enabled the ResourceTiming runtime flag.

[GTK][Threaded Compositor] Several flaky tests due to differences in scrollbars
https://bugs.webkit.org/show_bug.cgi?id=160450

Reviewed by Michael Catanzaro.

The issue is that ThreadedCompositor::didChangeVisibleRect() dispatches the setVisibleContentsRect() call that
ends up in CompositingCoordinator. Since we're compositing the scrollbars as well, this visible contents rect
needs to encompass the complete width of the view, but that's not happening.
In case of non-overlay scrollbars, the scrollbars are clipped from this rect, but that doesn't prevent the
scrollbar overlay layers to be flushed and rendered. What does happen is that during tile creation in the
backing store the tiles that would normally intersect the visible rect of the view (if it were spanning over the
whole actual visible area) are sorted by distance to the visible rect.
The top of the two tiles used for the scrollbar is closer to the visible rect, so that gets created and filled
in first. The second tile is stored as pending for creation, and does get rendered at the point of the next
layer flush.

* WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp:
(WebKit::ThreadedCoordinatedLayerTreeHost::setVisibleContentsRect): Update the visible rect taking into account
the non-overlay scrollbars before passing it to the compositor.

In this patch we are changing the current mechanism used to represent
RegExp in NewRegexp nodes. We are changing the use of a index
pointing to RegExp in
CodeBlock->m_unlinkedCodeBlock->m_rareData->m_regexps as the operand of
NewRegexp node to RegExp address as the operand. To make sure that RegExp* is
pointing to a valid object, we are using m_graph.freezeStrong
mechanism.

The number of times the move constructor is called is different on Windows in this test. This seems
to be caused by differences in MSVC's implementation of lambdas or std functions like std::make_tuple.

Storing layout parameters on the RenderMathMLRoot class is not really needed since reading
the parameters from the MATH table is not too expensive and updateStyle() is currently always
called in layoutBlock() and computePreferredLogicalWidths(). Most of these parameters are
actually only used in layoutBlock(). We separate horizontal and vertical parameters since
the latter are not needed for preferred width calculations. This removes the need for calling
an updateStyle functions and may also fix update issues when zooming in or out.

No new tests, already covered by existing tests.

* rendering/mathml/MathMLStyle.cpp:
(WebCore::MathMLStyle::updateStyleIfNeeded): No need to update layout parameters for the
RenderMathMLRoot class.
* rendering/mathml/RenderMathMLRoot.cpp:
(WebCore::RenderMathMLRoot::styleDidChange): No need to update layout parameters.
(WebCore::RenderMathMLRoot::horizontalParameters): Move code from updateStyle to retrieve the
horizontal parameters.
(WebCore::RenderMathMLRoot::verticalParameters): Ditto for vertical parameters.
(WebCore::RenderMathMLRoot::computePreferredLogicalWidths): Call horizontalParameters() to
get the kernings of the index instead of calling updateStyle().
(WebCore::RenderMathMLRoot::layoutBlock): Call horizontalParameters() and
verticalParameters() to get the layout parameters instead of calling updateStyle().
(WebCore::RenderMathMLRoot::paint): Call horizontalParameters() and verticalParameters()
to get the layout parameters.
(WebCore::RenderMathMLRoot::updateFromElement): Deleted. No need to call updateStyle().
(WebCore::RenderMathMLRoot::updateStyle): Deleted.
* rendering/mathml/RenderMathMLRoot.h: Do not override updateFromElement(). Replace some
layout parameters stored on the class with struct and helper functions to manipulate them.

* workers/WorkerLocation.h:
(WebCore::WorkerLocation::toString): Deleted.
* workers/WorkerLocation.idl:
Also use USVString string type instead of DOMString to match the
specification. There is no behavior change because those attributes
are readonly.

Location.toString() should be enumerable
https://bugs.webkit.org/show_bug.cgi?id=161179

Reviewed by Geoffrey Garen.

Source/WebCore:

Location.toString() should be enumerable as per:
- https://html.spec.whatwg.org/#location
- http://heycam.github.io/webidl/#es-stringifier

This patch stops hard-coding the toString() operation on the Location
interface and makes the 'href' attribute a stringifier attribute instead,
as per the specification. The generated toString() has the same behavior
as it used to but it is now enumerable, as it should.

* css/CSSOMUtils.cpp:
(WebCore::serializeIdentifier):
Update serialization to match the latest version of the spec:
<https://drafts.csswg.org/cssom/#serialize-an-identifier>
New handling for 0x0, 0x7f, just "-", and "--" is now allowed.