[BlackBerry] Detach overlays from page when compositor is detached
https://bugs.webkit.org/show_bug.cgi?id=112424

Reviewed by Rob Buis.

PR 309160

Source/WebCore:

Expose a method to retrieve a compositing thread layer's client.

No change in behavior, no new tests.

* platform/graphics/blackberry/LayerCompositingThread.h:
(WebCore::LayerCompositingThread::client):

Source/WebKit/blackberry:

If not detached properly, the overlays would have a dangling pointer to
the page.

* Api/WebOverlay.cpp:
(BlackBerry::WebKit::WebOverlayLayerCompositingThreadClient::WebOverlayLayerCompositingThreadClient):
(BlackBerry::WebKit::WebOverlayLayerCompositingThreadClient::uploadTexturesIfNeeded):
(BlackBerry::WebKit::WebOverlayPrivateCompositingThread::WebOverlayPrivateCompositingThread):
(BlackBerry::WebKit::WebOverlayPrivateCompositingThread::~WebOverlayPrivateCompositingThread):
* Api/WebOverlay_p.h:
(BlackBerry::WebKit::WebOverlayPrivate::setClient):
(WebOverlayLayerCompositingThreadClient):
(BlackBerry::WebKit::WebOverlayLayerCompositingThreadClient::overlay):
(BlackBerry::WebKit::WebOverlayLayerCompositingThreadClient::overlayDestroyed):
(WebOverlayPrivateCompositingThread):
* Api/WebPageCompositor.cpp:
(BlackBerry::WebKit::WebPageCompositorPrivate::detach):
(BlackBerry::WebKit::WebPageCompositorPrivate::setPage):
(WebKit):
(BlackBerry::WebKit::WebPageCompositorPrivate::attachOverlays):
* Api/WebPageCompositor_p.h:
(BlackBerry::WebKit::WebPageCompositorPrivate::attachOverlays):
(BlackBerry::WebKit::WebPageCompositorPrivate::detachOverlays):
(WebPageCompositorPrivate):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146058 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Exports leveldb symbols
https://bugs.webkit.org/show_bug.cgi?id=112526

Reviewed by Carlos Garcia Campos.

* Source/autotools/symbols.filter: make leveldb symbols local.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146059 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] EditorClientBlackBerry: fix access to WebPage attribute
https://bugs.webkit.org/show_bug.cgi?id=112556

Patch by Alberto Garcia <agarcia@igalia.com> on 2013-03-18
Reviewed by Rob Buis.

This changed in r145849 and broke the BlackBerry build.

* WebCoreSupport/EditorClientBlackBerry.cpp:
(WebCore::EditorClientBlackBerry::smartInsertDeleteEnabled):
(WebCore::EditorClientBlackBerry::isSelectTrailingWhitespaceEnabled):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146061 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: TabbedEditorContainer does not restore last shown file on reload sometimes.
https://bugs.webkit.org/show_bug.cgi?id=112561

Reviewed by Alexander Pavlov.

* inspector/front-end/TabbedEditorContainer.js:
(WebInspector.TabbedEditorContainer.prototype.addUISourceCode):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146062 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add USE(PLATFORM_STRATEGIES) ifdefs to StorageNamespace.cpp
https://bugs.webkit.org/show_bug.cgi?id=112004

Patch by Carlos Garcia Campos <cgarcia@igalia.com> on 2013-03-18
Reviewed by Rob Buis.

Check if platform strategies is enabled before using it, falling
back to StorageNamespaceImpl if it isn't.

* storage/StorageNamespace.cpp:
(WebCore::StorageNamespace::localStorageNamespace):
(WebCore::StorageNamespace::sessionStorageNamespace):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146065 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: [Settings] Register "?" shortcut.
https://bugs.webkit.org/show_bug.cgi?id=112545

Reviewed by Vsevolod Vlasov.

F1 and "?" (show shortcuts page) are not mentioned on shortcuts page.

* English.lproj/localizedStrings.js: Added string.
* inspector/front-end/inspector.js: Registered F1 / "?" shortcut.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146066 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] plugins/plugin-clip-subframe.html is failing
https://bugs.webkit.org/show_bug.cgi?id=112570

Reviewed by Martin Robinson.

Tools: 

* GNUmakefile.am: Add the LogNPPSetWindow.cpp file to the build.

LayoutTests: 

* platform/gtk-wk2/plugins/plugin-clip-subframe-expected.txt: Added the required baseline.
* platform/gtk/TestExpectations: Removing the failure expectation.
* platform/gtk/plugins/plugin-clip-subframe-expected.txt: Added the required baseline.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146067 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Unreviewed gardening.

* platform/efl/TestExpectations: Remove
editing/pasteboard/paste-4035648-fix.html from the skipped list after
r144999.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146068 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Need to use const String in HTMLVideoElement::posterImageURL
https://bugs.webkit.org/show_bug.cgi?id=112317

Patch by Tao Bai <michaelbai@chromium.org> on 2013-03-18
Reviewed by Andreas Kling.

No behavioral changes.

This is the followup of https://bugs.webkit.org/show_bug.cgi?id=110263
Need to use String instead of const AtomicString& which means we will do an extra hash lookup

* html/HTMLVideoElement.cpp:
(WebCore::HTMLVideoElement::posterImageURL): Change to use String for url

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146069 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Access settings.defaultVideoPosterURL
https://bugs.webkit.org/show_bug.cgi?id=112378

Patch by Tao Bai <michaelbai@chromium.org> on 2013-03-18
Reviewed by Dimitri Glazkov.

The defaultVideoPosterURL setting has been added in
https://bugs.webkit.org/show_bug.cgi?id=110263,
this added methods to access it in Chromium.
The settings will be used by Android WebView API
WebChromeClient.getDefaultVideoPoster()

* public/WebSettings.h: add setDefaultVideoPosterURL
* src/WebSettingsImpl.cpp:
(WebKit::WebSettingsImpl::setDefaultVideoPosterURL): set defaultVideoPosterURL
* src/WebSettingsImpl.h: add setDefaultVideoPosterURL

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146070 268f45cc-cd09-0410-ab3c-d52691b4dbfc
ObjectPrototype properties should be eagerly created rather than lazily via static tables
https://bugs.webkit.org/show_bug.cgi?id=112539

Reviewed by Oliver Hunt.
        
This is the first part of https://bugs.webkit.org/show_bug.cgi?id=112233. Rolling this
in first since it's the less-likely-to-be-broken part.

* CMakeLists.txt:
* DerivedSources.make:
* DerivedSources.pri:
* GNUmakefile.list.am:
* interpreter/CallFrame.h:
(JSC::ExecState::objectConstructorTable):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalData.cpp:
(JSC):
(JSC::JSGlobalData::JSGlobalData):
(JSC::JSGlobalData::~JSGlobalData):
* runtime/JSGlobalData.h:
(JSGlobalData):
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectNativeFunction):
(JSC):
* runtime/JSObject.h:
(JSObject):
(JSC):
* runtime/Lookup.cpp:
(JSC::setUpStaticFunctionSlot):
* runtime/ObjectPrototype.cpp:
(JSC):
(JSC::ObjectPrototype::finishCreation):
(JSC::ObjectPrototype::create):
* runtime/ObjectPrototype.h:
(ObjectPrototype):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146071 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Change RenderTableCell to use pixelSnappedSize when painting
https://bugs.webkit.org/show_bug.cgi?id=112562

Reviewed by Eric Seidel.

Source/WebCore:

Change the paining code in RenderTableCell to use the pixel snapped size
to ensure consistent rounding given that the location was rounded during
layout.

It is currently constructing a paint rect by taking the rounded location
and the precise size and then pixel snapping it. This causes the size to
be rounded incorrectly. By instead using the pixel snapped size the
rounding problem can be avoided.

Test: fast/sub-pixel/table-cell-background.html

* rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::paintCollapsedBorders):
(WebCore::RenderTableCell::paintBackgroundsBehindCell):
(WebCore::RenderTableCell::paintBoxDecorations):
(WebCore::RenderTableCell::paintMask):

LayoutTests:

Add test for painting of cell backgrounds on a sub-pixel boundary.

* fast/sub-pixel/table-cell-background-expected.html: Added.
* fast/sub-pixel/table-cell-background.html: Added.
* platform/chromium-linux/tables/mozilla/bugs/bug73321-expected.png:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146072 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Exclusions] Specifying polygonal -webkit-shape-inside value can crash browser (debug mode)
https://bugs.webkit.org/show_bug.cgi?id=112157

Reviewed by David Hyatt.

Source/WebCore:

Corrected the code which maps exclusion segments to pairs of InlineIterators. We now handle the
cases where the end of the line occurs within an exclusion segment or when it occurs before
the last exclusion segment has been reached. This can occur when a non-convex polygonal shape-inside
breaks a line up into two segments, but the shape-inside element's content only fills (or partially
fills) the first exclusion shape segment.

Tests: fast/exclusions/shape-inside/shape-inside-partial-fill-001.html
       fast/exclusions/shape-inside/shape-inside-partial-fill-002.html

* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlock::LineBreaker::nextLineBreak):

LayoutTests:

Added tests with a polygonal shape-inside exclusion shape, where multiple shape
segments exist on one line, but the line's text either partially or completely
fills only the first exclusion shape segment.

* fast/exclusions/shape-inside/shape-inside-partial-fill-001-expected.html: Added.
* fast/exclusions/shape-inside/shape-inside-partial-fill-001.html: Added.
* fast/exclusions/shape-inside/shape-inside-partial-fill-002-expected.html: Added.
* fast/exclusions/shape-inside/shape-inside-partial-fill-002.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146073 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] Crash when accessing onclick attribute of document from XMLHttpRequest
https://bugs.webkit.org/show_bug.cgi?id=112585

Reviewed by Eric Seidel.

Source/WebCore:

This ASSERT was bogus. The frame can be 0 for frameless documents, like
those created by XMLHttpRequest. When there is no frame, we act as if
JavaScript was disabled, which it is.

Test: fast/events/xhr-onclick-crash.html

* bindings/v8/V8LazyEventListener.cpp:
(WebCore::V8LazyEventListener::prepareListenerObject):

LayoutTests:

* fast/events/resources/onclick.html: Added.
* fast/events/xhr-onclick-crash-expected.txt: Added.
* fast/events/xhr-onclick-crash.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146074 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2][EFL] Fix code wrapping WKPageGroupRef
https://bugs.webkit.org/show_bug.cgi?id=112364

Reviewed by Alexey Proskuryakov.

The patch fixes following problems in EWK2 WKPageGroupRef wrapping
code: firstly it makes sure that there is only one EwkPageGroup
instance per WKPageGroup instance, secondly it allows web page to
to use the default page group (which is implicitly created inside
web context).

* UIProcess/API/C/efl/WKView.cpp:
(createWKView):

    Now may pass '0' page group as a WebView creation argument so
    that the default page group is used.

* UIProcess/API/efl/EwkView.cpp:
(EwkView::EwkView):
(EwkView::createEvasObject):
* UIProcess/API/efl/EwkView.h:
(EwkView):

    Web view should be created before page group, so they are rearranged
    inside class declaration.

* UIProcess/API/efl/ewk_page_group.cpp:
(pageGroupMap):

    A map to track corresponding EwkPageGroup and WKPageGroup
    instances.

(EwkPageGroup::findOrCreateWrapper):

    Returns the same EwkPageGroup instance for the same WKPageGroup
    instance.

(EwkPageGroup::create):
(EwkPageGroup::EwkPageGroup):

    Now there is only one constructor accepting WKPageGroupRef.

(EwkPageGroup::~EwkPageGroup):
* UIProcess/API/efl/ewk_page_group_private.h:
(EwkPageGroup):
* UIProcess/efl/WebInspectorProxyEfl.cpp:
(WebKit::WebInspectorProxy::platformCreateInspectorPage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146075 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Update test expectations.

Unreviewed gardening.

* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146077 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Remove WebGraphicsContext3DInProcessImpl support from DRT.
https://bugs.webkit.org/show_bug.cgi?id=112392

Reviewed by James Robinson.

Removes the command line flag option from DRT.

* DumpRenderTree/chromium/DumpRenderTree.cpp:
(main):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146078 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: move _timelineGrid && _timelineOverviewWindow from TimelineOverviewPane into a new class OverviewGrid.
https://bugs.webkit.org/show_bug.cgi?id=112584

Reviewed by Pavel Feldman.

It is the first path in the set.
The end goal is to extract OverviewGrid with window selectors
into a separate class in separate file and reuse it in CPU FlameChart.

* inspector/front-end/TimelineOverviewPane.js:
(WebInspector.TimelineOverviewPane):
(WebInspector.OverviewGrid):
(WebInspector.OverviewGrid.prototype.get grid):
(WebInspector.OverviewGrid.prototype.get clientWidth):
(WebInspector.OverviewGrid.prototype.showItemsGraphsElement):
(WebInspector.OverviewGrid.prototype.hideItemsGraphsElement):
(WebInspector.OverviewGrid.prototype.updateDividers):
(WebInspector.OverviewGrid.prototype.addEventDividers):
(WebInspector.OverviewGrid.prototype.removeEventDividers):
(WebInspector.OverviewGrid.prototype.setWindowPosition):
(WebInspector.OverviewGrid.prototype.reset):
(WebInspector.OverviewGrid.prototype.get windowLeft):
(WebInspector.OverviewGrid.prototype.get windowRight):
(WebInspector.OverviewGrid.prototype.setWindow):
(WebInspector.OverviewGrid.prototype.addEventListener):
(WebInspector.TimelineOverviewPane.prototype.setMode):
(WebInspector.TimelineOverviewPane.prototype._setFrameMode):
(WebInspector.TimelineOverviewPane.prototype._update):
(WebInspector.TimelineOverviewPane.prototype.sidebarResized):
(WebInspector.TimelineOverviewPane.prototype.zoomToFrame):
(WebInspector.TimelineOverviewPane.prototype._reset):
(WebInspector.TimelineOverviewPane.prototype.windowLeft):
(WebInspector.TimelineOverviewPane.prototype.windowRight):
(WebInspector.TimelineOverviewPane.prototype._updateWindow):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146079 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Added new test expectations after r146072.
https://bugs.webkit.org/show_bug.cgi?id=112562

* platform/chromium-mac-lion/tables/mozilla/bugs/bug73321-expected.png:
* platform/chromium-mac-snowleopard/tables/mozilla/bugs/bug73321-expected.png:
* platform/chromium-mac/tables/mozilla/bugs/bug73321-expected.png:
* platform/chromium-win/tables/mozilla/bugs/bug73321-expected.png:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146080 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Disable accessibility notifications after each test
https://bugs.webkit.org/show_bug.cgi?id=112579

Reviewed by Tim Horton.

In WebKitTestRunner, if any tests triggered accessibility notifications,
the global notification handler would thereafter be active, and fire
notifications for all subsequent tests.

Fix by implementing AccessibilityController::resetToConsistentState() for
Mac, and using it to clear the global notification handler.

* WebKitTestRunner/InjectedBundle/AccessibilityController.cpp:
* WebKitTestRunner/InjectedBundle/mac/AccessibilityControllerMac.mm:
(WTR::AccessibilityController::addNotificationListener): Remove stupid comment.
(WTR::AccessibilityController::removeNotificationListener): Explicitly call
-stopObserving so that unregistering the observer doesn't rely on object lifetimes
(e.g. because of -autorelease).
(WTR::AccessibilityController::logAccessibilityEvents): Stub.
(WTR::AccessibilityController::resetToConsistentState): Remove the notification listener
if there is one.
* WebKitTestRunner/InjectedBundle/mac/AccessibilityNotificationHandler.h:
Add -stopObserving
* WebKitTestRunner/InjectedBundle/mac/AccessibilityNotificationHandler.mm:
(-[AccessibilityNotificationHandler dealloc]): Call -stopObserving
(-[AccessibilityNotificationHandler stopObserving]): Unregister from the notification
center.


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