Programmatically-inserted children lack accessibility events
https://bugs.webkit.org/show_bug.cgi?id=100275

Reviewed by Chris Fleizach.

Source/WebCore:

Test: accessibility/children-changed-sends-notification.html

Emit children-changed::add and children-changed::remove whenever
an object has been added/removed to the accessibility hierarchy,
that is, when a new AtkObject is being attached/detached.

* accessibility/AXObjectCache.h:
(WebCore::AXObjectCache::detachWrapper): Added a new parameter and
updated all the prototypes in different ports.
* accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::~AXObjectCache): Call detachWrapper()
specifying that we do it because the cache is being destroyed.
(WebCore::AXObjectCache::remove): Call detachWrapper() specifying
that we do it because an accessible element is being destroyed.

* accessibility/atk/AXObjectCacheAtk.cpp:
(WebCore::AXObjectCache::detachWrapper): Emit the children-changed
signal when needed. We rely on the cached reference to the parent
AtkObject (using the implementation of atk_object_get_parent from
the AtkObject class) to find the right object to emit the signal
from here, since the accessibility hierarchy from WebCore will no
longer be accessible at this point.
(WebCore::AXObjectCache::attachWrapper): Emit the children-change
signal from here unless we are in the middle of a layout update,
trying to provide as much information (e.g. the offset) as possible.
(WebCore::AXObjectCache::postPlatformNotification): Make sure we
update (touch) the subtree under an accessibility object whenever
we receive AXChildrenChanded from WebCore, to ensure that those
objects will also be visible rightaway to ATs, and that those get
properly notified of the event at that very same moment.

* accessibility/ios/AXObjectCacheIOS.mm:
(WebCore::AXObjectCache::detachWrapper): Updated function signature.
* accessibility/mac/AXObjectCacheMac.mm:
(WebCore::AXObjectCache::detachWrapper): Ditto.
* accessibility/win/AXObjectCacheWin.cpp:
(WebCore::AXObjectCache::detachWrapper): Ditto.

* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::children): Add the option ot
request the AccessibilityChildrenVector without updating it if
needed, to avoid maybe recreating the child subtree when trying to
get the offset of a newly attached element from attachWrapper.
* accessibility/AccessibilityObject.h:

Tools:

Update DRT and WebKitTestRunner to handle the children-changed
signal properly, considering the detail and optional parameters.

* DumpRenderTree/atk/AccessibilityCallbacksAtk.cpp: Updated.
(axObjectEventListener):
* WebKitTestRunner/InjectedBundle/atk/AccessibilityNotificationHandlerAtk.cpp: Updated.

LayoutTests:

Add new test to chack that children-changed signals are properly
emitted when adding/removing elements in the accessibility hierarchy.

* accessibility/children-changed-sends-notification-expected.txt: Added.
* accessibility/children-changed-sends-notification.html: Added.

Update test to filter out unrelated non-loading events.
* accessibility/loading-iframe-sends-notification.html: Updated.

Skip the test on the Mac as it does not expose these kind of
notifications when children are being added or removed.
* platform/mac/TestExpectations: Skip newly added test.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160903 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Some unit tests using web extensions fail when run alone
https://bugs.webkit.org/show_bug.cgi?id=126002

Reviewed by Gustavo Noronha Silva.

The problem is that the page is created before the dbus connection
has been established, and we are connecting to web-page-created
signal once we have a valid dbus connection. We should connect to
the signal before connecting to dbus and queue any request to emit
a dbus signal until the connection is set. This also fixes the
WebExtensions tests when using the network process because a new
web process is launched for every test case.

* UIProcess/API/gtk/tests/WebExtensionTest.cpp:
(DelayedSignal::DelayedSignal): Helper struct to queue signal
emissions requested before the dbus connection has been
established.
(emitDocumentLoaded): Emit the dbus DocumentLoaded signal.
(documentLoadedCallback): Queue the signal emission if we still
don't have a connection or call emitDocumentLoaded otherwise.
(emitURIChanged): Emit the dbus URIChanged signal.
(uriChangedCallback): Queue the signal emission if we still don't
have a connection or call emitURIChanged otherwise.
(pageCreatedCallback): Pass the web extension as user data to
document-loaded and uri-changed callbacks.
(busAcquiredCallback): Set the connection as user data of the web
extension and process any delayed signal emission pending.
(webkit_web_extension_initialize): Connect to web-page-create
signal before connecting to dbus.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160904 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Regions] When changing flow-from/flow-into on :hover, elements overflowing the region are not correctly repainted
https://bugs.webkit.org/show_bug.cgi?id=117259

Reviewed by Antti Koivisto.

Source/WebCore:

When computing the repaint rect for a region, the existing visual overflow must be taken into consideration.
For this purpose, I overridden the visualOverflowRect method in RenderNamedFlowFragment, which ends up being
called from RenderBox::clippedOverflowRectForRepaint.

Test: fast/regions/hover-single-flow-from-none-overflow.html
      fast/regions/hover-single-flow-from-none-overflow-top.html

* rendering/RenderNamedFlowFragment.cpp:
(WebCore::RenderNamedFlowFragment::visualOverflowRect):
* rendering/RenderNamedFlowFragment.h:

LayoutTests:

Added new tests and rebased existing test.

* fast/regions/hover-single-flow-from-none-overflow-expected.html: Added.
* fast/regions/hover-single-flow-from-none-overflow.html: Added.
* fast/regions/hover-single-flow-from-none-overflow-top-expected.html: Added.
* fast/regions/hover-single-flow-from-none-overflow-top.html: Added.
* fast/regions/repaint/repaint-regions-overflow-expected.txt: Rebased.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160905 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Devirtualize RenderElement::setStyle().
<https://webkit.org/b/126065>

setStyle() was only virtual in order to let RenderSVGBlock override
the display type in some cases. Devirtualized it and moved the fixup
logic to StyleResolver::adjustRenderStyle().

This hack had an evil twin in RenderElement::initializeStyle() that
also goes away. FIXME--!

Based on a Blink change by Elliott Sprehn.

Reviewed by Antti Koivisto.


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