Timeline
Nov 25, 2016:
- 4:17 PM Changeset in webkit [208978] by
-
- 2 edits in trunk/Tools
Fix compile warnings after r208415
https://bugs.webkit.org/show_bug.cgi?id=165061
Reviewed by Andy Estes.
- TestWebKitAPI/Tests/WTF/Time.cpp:
(TestWebKitAPI::TEST):
- 10:38 AM Changeset in webkit [208977] by
-
- 4 edits in trunk/Source/WebKit2
[GTK] Follow-up fixes to r208974
https://bugs.webkit.org/show_bug.cgi?id=164771
Unreviewed, implement Carlos's review feedback.
- UIProcess/API/gtk/WebKitNotification.cpp:
(webkit_notification_get_tag):
- UIProcess/API/gtk/WebKitNotificationProvider.cpp:
(WebKitNotificationProvider::withdrawAnyPreviousNotificationMatchingTag):
(WebKitNotificationProvider::show):
- UIProcess/API/gtk/WebKitNotificationProvider.h:
- 9:35 AM Changeset in webkit [208976] by
-
- 3 edits4 adds in trunk
[CSS Font Loading] FontFace.load() promises don't always fire
https://bugs.webkit.org/show_bug.cgi?id=165037
Reviewed by Simon Fraser.
Source/WebCore:
We currently handle web fonts in two phases. The first phase is building up
StyleRuleFontFace objects which reflect the style on the page. The second is creating
CSSFontFace objects from those StyleRuleFontFace objects. When script modifies the
style on the page, we can often update the CSSFontFace objects, but there are some
modifications which we don't know how to model. For these operations, we destroy the
CSSFontFace objects and rebuild them from the newly modified StyleRuleFontFace objects.
Normally, this is fine. However, with the CSS font loading API, the CSSFontFaces back
Javascript objects which will persist across the rebuilding step mentioned above. This
means that the FontFace objects need to adopt the new CSSFontFace objects and forget
the old CSSFontFace objects.
This gets a little tricky because the operation which caused the rebuild may actually
be a modification to the specific @font-face block which backs a Javascript FontFace
object. Because the CSSOM can be used to change the src: attribute of the FontFace
object, I decided in r201971 to clear the FontFace's promise in case an old load would
cause the promise to resolve. However, this would never happen because the old
CSSFontFace is unparented during the FontFace::adopt()ion of the new CSSFontFace.
Therefore, old loads may still complete, but the signal would never make it to the
FontFace and therefore would not cause the promise to resolve. In addition, clearing
the promise during a rebuild is problematic because that rebuild may be caused by
operations which have nothing to do with the specific FontFace object in question (so
the FontFace object should be observably uneffected.)
Because of the above reasons, this patch simply stops clearing the promise during the
rebuild phase.
Tests: fast/text/fontface-rebuild-during-loading.html
fast/text/fontface-rebuild-during-loading-2.html
- css/FontFace.cpp:
(WebCore::FontFace::adopt):
LayoutTests:
- fast/text/fontfaceset-rebuild-during-loading-2-expected.txt: Added.
- fast/text/fontfaceset-rebuild-during-loading-2.html: Added.
- 7:18 AM WebKitGTK/2.14.x edited by
- More patches to merge into 2.14.3 (diff)
- 6:59 AM Changeset in webkit [208975] by
-
- 2 edits in trunk/Source/WebCore
MemoryPressureHandler should only trigger synchronous GC on iOS
<https://webkit.org/b/165043>
<rdar://problem/29312684>
Reviewed by Sam Weinig.
On iOS we know that there is really only one web process in play at a time,
so it's okay to do a synchronous GC immediately in response to high memory pressure.
On other platforms, we may have tens or hundreds of web processes, and if they
all start doing full GCs at the same time, it can easily bring a system to its knees
if it's already under pressure.
Fix this by using garbageCollectSoon() on non-iOS platforms.
- page/MemoryRelease.cpp:
(WebCore::releaseCriticalMemory):
Nov 24, 2016:
- 12:10 PM Changeset in webkit [208974] by
-
- 8 edits in trunk
[GTK] Notifications API does not expose or respect the "tag" attribute
https://bugs.webkit.org/show_bug.cgi?id=164771
Reviewed by Gustavo Noronha Silva.
Source/WebKit2:
Expose a tag property on WebKitNotification. Ensure that any previous notification with the
same tag is closed when showing a new notification with that tag.
- UIProcess/API/gtk/WebKitNotification.cpp:
(webkit_notification_class_init):
(webkitNotificationCreate):
(webkit_notification_get_tag):
- UIProcess/API/gtk/WebKitNotification.h:
- UIProcess/API/gtk/WebKitNotificationProvider.cpp:
(WebKitNotificationProvider::withdrawAnyPreviousNotificationMatchingTag):
(WebKitNotificationProvider::show):
- UIProcess/API/gtk/WebKitNotificationProvider.h:
- UIProcess/API/gtk/docs/webkit2gtk-4.0-sections.txt:
Tools:
Verify that showing a notification with the same tag as another notification closes the
previous notification before the new notification is shown.
- TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitWebView.cpp:
(testWebViewNotification):
- 7:08 AM Changeset in webkit [208973] by
-
- 3 edits in trunk/Source/WebCore
[css-grid] Convert grid representation into a class
https://bugs.webkit.org/show_bug.cgi?id=165042
Reviewed by Manuel Rego Casasnovas.
So far grids are represented as Vectors of Vectors. There are a couple of issues associated
to that decision. First or all, the source code in RenderGrid assumes the existence of that
data structure, meaning that we cannot eventually change it without changing a lot of
code. Apart from the coupling there is another issue, RenderGrid is full of methods to
access and manipulate that data structure.
Instead, it'd be much better to have a Grid class encapsulating both the data structures and
the methods required to access/manipulate it. Note that follow-up patches will move even
more data and procedures into this new class from the RenderGrid code.
No new tests required as this is a refactoring.
- rendering/RenderGrid.cpp:
(WebCore::RenderGrid::Grid::ensureGridSize): Moved from RenderGrid.
(WebCore::RenderGrid::Grid::insert): Ditto.
(WebCore::RenderGrid::Grid::clear): Ditto.
(WebCore::RenderGrid::GridIterator::GridIterator):
(WebCore::RenderGrid::gridColumnCount): Use Grid's methods.
(WebCore::RenderGrid::gridRowCount): Ditto.
(WebCore::RenderGrid::placeItemsOnGrid): Use Grid's methods to insert children.
(WebCore::RenderGrid::populateExplicitGridAndOrderIterator): Ditto.
(WebCore::RenderGrid::placeSpecifiedMajorAxisItemsOnGrid): Ditto.
(WebCore::RenderGrid::placeAutoMajorAxisItemOnGrid): Ditto.
(WebCore::RenderGrid::numTracks): Use Grid's methods.
(WebCore::RenderGrid::ensureGridSize): Deleted. Moved to Grid class.
(WebCore::RenderGrid::insertItemIntoGrid): Deleted. Moved to Grid class.
- rendering/RenderGrid.h:
- 5:35 AM Changeset in webkit [208972] by
-
- 2 edits in trunk/Tools
Unreviewed. Fix GTK+ test /webkit2/WebKitWebContext/get-plugins after r208429.
Test plugin library was renamed as libTestNetscapePlugIn.so in r208429.
- TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitWebContext.cpp:
(testWebContextGetPlugins): Update the library name.
- 4:54 AM Changeset in webkit [208971] by
-
- 12 edits in trunk/Source/WebCore
Remove unused bool return from Element::willRecalcStyle
https://bugs.webkit.org/show_bug.cgi?id=165059
Reviewed by Andreas Kling.
It is always true.
- dom/Element.cpp:
(WebCore::Element::willRecalcStyle):
- dom/Element.h:
- html/HTMLFrameSetElement.cpp:
(WebCore::HTMLFrameSetElement::willRecalcStyle):
- html/HTMLFrameSetElement.h:
- html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::willRecalcStyle):
- html/HTMLPlugInImageElement.h:
- style/StyleTreeResolver.cpp:
(WebCore::Style::TreeResolver::resolveComposedTree):
- svg/SVGElement.cpp:
(WebCore::SVGElement::willRecalcStyle):
- svg/SVGElement.h:
- svg/SVGUseElement.cpp:
(WebCore::SVGUseElement::willRecalcStyle):
- svg/SVGUseElement.h:
