Timeline

Jul 14, 2019:

3:18 PM Changeset in webkit [247425] by Chris Dumez

• 5 edits in trunk/Source

Add threading assertion to WeakPtrFactory::createWeakPtr()
​https://bugs.webkit.org/show_bug.cgi?id=199639

Reviewed by Ryosuke Niwa.

Source/WebCore:

• platform/ScrollableArea.cpp:
• rendering/RenderObject.cpp:

Source/WTF:

Add threading assertion to WeakPtrFactory::createWeakPtr() to make sure it
is called on the same thread where the WeakPtrFactory wad constructed.

• wtf/WeakPtr.h:

(WTF::WeakPtrFactory::WeakPtrFactory):
(WTF::WeakPtrFactory::createWeakPtr const):

1:47 PM Changeset in webkit [247424] by bshafiei@apple.com

• 7 edits in tags/Safari-608.1.35.1/Source

Versioning.

1:35 PM Changeset in webkit [247423] by bshafiei@apple.com

• 1 copy in tags/Safari-608.1.35.1

New tag.

1:21 PM Changeset in webkit [247422] by dino@apple.com

• 5 edits
  2 adds in trunk

WebGL not supported on WKWebView on UIKit for Mac
​https://bugs.webkit.org/show_bug.cgi?id=199785
<rdar://problem/52911449>

Reviewed by Antoine Quint.

Source/WebCore:

UIKit for Mac was not creating a CGLPixelFormatObj because
it wasn't using the code hidden in PLATFORM(MAC). Instead
we should be guarding for USE(OPENGL).

There are still some inconsistencies: <rdar://53062794>

Test: webgl/smell-test.html

• platform/graphics/cocoa/GraphicsContext3DCocoa.mm:

(WebCore::GraphicsContext3D::GraphicsContext3D):
(WebCore::GraphicsContext3D::allowOfflineRenderers const): We have to return
true for this, since we don't have access to the Window Server.

Source/WTF:

MacCatalyst has Apple Graphics Control, although
this area is very messy, see <rdar://53062794>.

• wtf/Platform.h:

LayoutTests:

Even though we don't yet run tests on UIKit for Mac, we
should have the most simple "is WebGL working?" ref test.

• webgl/smell-test-expected.html: Added.
• webgl/smell-test.html: Added.

Jul 13, 2019:

8:36 PM Changeset in webkit [247421] by Wenson Hsieh

• 9 edits in trunk

[Text autosizing] [iPadOS] Further adjust our heuristics to determine text autosizing candidates
​https://bugs.webkit.org/show_bug.cgi?id=199780
<rdar://problem/52289088>

Reviewed by Simon Fraser.

Source/WebCore:

Our current idempotent text autosizing candidate heuristic makes the right judgment call most of the time, but
there is still a large batch of text autosizing bugs left unfixed by the first iteration of the heuristic added
in r246781. This patch attempts to address most of these bugs by adjusting the decision-tree-based heuristic
once again, mostly with improvements to the model generation pipeline.

During the first iteration, I placed emphasis on tuning the max tree depth and min leaf size hyperparameters
when coming up with my decision tree, and didn't consider the inclusion or exclusion of each feature as a
hyperparameters. As such, the trees generated using the pipeline tended to use too many features, and as a
result, tended to have cross-validation overall accuracy scores hovering around 73%.

In this revised model generation pipeline, I now consider the inclusion of each feature (along with max depth
and min leaf size, as before) as a hyperparameter. Since this increases the number of hyperparameters by many
orders of magnitude, a naive grid search (as described in the prior ChangeLog entry) is no longer a tractible
procedure for tuning hyperparameters to the training algorithm.

Instead, I now use a stochastic greedy algorithm to search for good sets of hyperparameters; this process begins
with seeding some number (usually 20-24) of "searchers" with completely randomized sets of hyperparameters (i.e.
random max depth, random leaf size, and random subsets of features). I then evaluate the average performance of
each set of hyperparameters by using them to generate 2000 decision trees over 90% of the training data, and
then cross-validating these trees against the remaining 10%. These cross-validation scores are aggregated into a
single confusion matrix, which is then passed into a loss function that computes a single value indicating how
well training with the set of hyperparameters generalized to cross-validation data. After experimenting with
various loss functions, I settled on the following:

k(false positive rate)^2 + (false negative rate)^2

...where a constant k is chosen to penalize false positives (i.e. broken layout) more harshly than false
negatives (small text). Additionally, squaring the false negative and false positive rates seems to help avoid
converging on solutions that heavily favor reducing only false positives or false negatives, or vice versa.

The stochastic algorithm starts by computing a loss value for the randomly generated configuration. Then, for
an indefinite number of iterations, it randomly mutates the configuration (e.g. by adding or removing features,
or changing min leaf size or max tree depth) and computes a new loss value for the mutated configuration. If the
mutated configuration performs better (i.e. achieves lower loss) than the current configuration, I set the
current configuration to be the mutated configuration. Otherwise, I keep the current (non-mutated) configuration
as-is. The stochastic algorithm then proceeds, ad-infinitum, with this current configuration.

Of course, since each mutation is small, this strategy so far is prone to leaving each searcher stuck in local
optima. To mitigate this, for each searcher, I keep track of a side-table of configurations that have already
been tested; when random mutations would normally lead to testing a configuration that has already been tested,
each searcher instead increases the chance of applying additional mutations. This has the effect of searchers
initially exhausting similar configurations, and expanding to test more and more dissimilar configurations as
the local alternatives all turn out to be worse. This allows searchers to effectively jump out of local optima
after being stuck for a long time.

So, using these strategies, I simultaneously ran a handful of searchers until they all appeared to converge
(a process that takes 8-12 hours on my current dataset). Many of the searchers achieved configurations with
cross-validation scores of 81% and above, up from the 73% of the previous attempt. These additionally have the
added bonus of reducing the number of features, often making the final trees themselves shallower and simpler to
understand than before.

This patch introduces one such decision tree generated using a set of hyperparameters acquired via this
stochasic search algorithm; it appears to simultaneously use fewer features, and achieve better cross-validation
performance.

Test: fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidates.html

• css/StyleResolver.cpp:

(WebCore::StyleResolver::adjustRenderStyleForTextAutosizing):

Adjust the early return to bail if either (1) the element is a candidate and the computed size is already equal
to the boosted size, or (2) the element is not a candidate and the computed size is already equal to the
specified size. Since the autosizing candidate heuristic depends on styles specified on the element itself (as
opposed to styles on any element in the ancestor chain), a parent may be an autosizing candidate, but a child of
it may not.

• rendering/style/RenderStyle.cpp:

(WebCore::RenderStyle::isIdempotentTextAutosizingCandidate const):

Revamp the idempotent text autosizing candidate heuristic. See the explanation above for more details.

• rendering/style/RenderStyle.h:

Remove some bits from RenderStyle's autosizeStatus, now that we care about fewer bits of information from the
inherited flags.

• rendering/style/TextSizeAdjustment.cpp:

(WebCore::AutosizeStatus::updateStatus):

• rendering/style/TextSizeAdjustment.h:

LayoutTests:

Rebaseline an existing idempotent text autosizing test, and add an additional test case.

• fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidates-expected.txt:
• fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidates.html:

3:29 PM Changeset in webkit [247420] by Simon Fraser

• 3 edits
  3 adds in trunk

Don't do async overflow scrolling for visibility:hidden scrollers
​https://bugs.webkit.org/show_bug.cgi?id=199779

Reviewed by Dean Jackson.
Source/WebCore:

An overflow:scroll with visibility:hidden is not scrollable on macOS, even if it has visible
content. So disable async overflow:scroll when the scroller has non-visible visibility (this also
takes visibility on ancestors into account).

visibility:hidden overflow:scroll can be common because some JS libraries use it
(​https://github.com/wnr/element-resize-detector).

Test: compositing/scrolling/async-overflow-scrolling/visibility-hidden-scrollers.html

• rendering/RenderLayer.cpp:

(WebCore::RenderLayer::canUseCompositedScrolling const): Don't use hasVisibleContent() because
that's affected by visible children.

LayoutTests:

• compositing/scrolling/async-overflow-scrolling/visibility-hidden-scrollers-expected.txt: Added.
• compositing/scrolling/async-overflow-scrolling/visibility-hidden-scrollers.html: Added.
• platform/ios-wk2/compositing/scrolling/async-overflow-scrolling/visibility-hidden-scrollers-expected.txt: Added.

10:43 AM Changeset in webkit [247419] by rmorisset@apple.com

• 5 edits in trunk/Source/WebCore

[WHLSL] Return statements don't need to keep track of the function they're in
​https://bugs.webkit.org/show_bug.cgi?id=199763

Reviewed by Myles C. Maxfield.

Return::m_function is only used in the Checker, and it can easily enough keep track of the current function.
This means we no longer need to keep track of the current function in the NameResolver, and we can save 8 bytes per Return

Since I was touching the NameResolver I also removed a few pointless overrides of Visitor::visit().

No new tests as there is no intended functional change.

• Modules/webgpu/WHLSL/AST/WHLSLReturn.h:
• Modules/webgpu/WHLSL/WHLSLChecker.cpp:

(WebCore::WHLSL::Checker::visit):

• Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:

(WebCore::WHLSL::NameResolver::NameResolver):
(WebCore::WHLSL::resolveTypeNamesInFunctions):

• Modules/webgpu/WHLSL/WHLSLNameResolver.h:

10:28 AM Changeset in webkit [247418] by commit-queue@webkit.org

• 4 edits in trunk/Source

Add accessibility support to WKDataListSuggestionsView.
​https://bugs.webkit.org/show_bug.cgi?id=199772
<rdar://problem/47095851>

Patch by Andres Gonzalez <Andres Gonzalez> on 2019-07-13
Reviewed by Chris Fleizach.

Source/WebCore:

Localizable strings for accessibility announcements.

• en.lproj/Localizable.strings:

Source/WebKit:

Added accessibility announcement notifications to show, dismiss and selection change for the datalist suggestions view.

• UIProcess/mac/WebDataListSuggestionsDropdownMac.mm:

(-[WKDataListSuggestionsView notifyAccessibilityClients:]):
(-[WKDataListSuggestionsView moveSelectionByDirection:]):
(-[WKDataListSuggestionsView invalidate]):
(-[WKDataListSuggestionsView showSuggestionsDropdown:]):

8:28 AM Changeset in webkit [247417] by Chris Dumez

• 5 edits in trunk/Source/WebCore

Drop non thread-safe usage of WeakPtr in VideoFullscreenInterfaceAVKit
​https://bugs.webkit.org/show_bug.cgi?id=199775

Reviewed by Eric Carlson.

The VideoFullscreenInterfaceAVKit constructor was making a weakPtr on the UI Thread
of an WebThread object. The WeakPtr would then be used as a data member throughout
the class on the UIThread. This is not thread-safe.

This patch switches to using a raw pointer instead of a WeakPtr. This is a partial
rollout of r243298, which turned the raw pointer into a WeakPtr for hardening
purposes. For extra safety, this patch updates the VideoFullscreenControllerContext
so that it notifies its clients (i.e. PlaybackSessionInterfaceAVKit) that it is
getting destroyed, so that they can null-out their m_videoFullscreenModel &
m_fullscreenChangeObserver data members. This gives the sames guarantees as WeakPtr
but in a thread-safe way.

This is very similar to the fix that was done for PlaybackSessionInterfaceAVKit in
r247380.

• platform/cocoa/VideoFullscreenModel.h:

(WebCore::VideoFullscreenModelClient::modelDestroyed):

• platform/ios/VideoFullscreenInterfaceAVKit.h:
• platform/ios/VideoFullscreenInterfaceAVKit.mm:

(VideoFullscreenInterfaceAVKit::setVideoFullscreenModel):
(VideoFullscreenInterfaceAVKit::setVideoFullscreenChangeObserver):
(VideoFullscreenInterfaceAVKit::modelDestroyed):

• platform/ios/WebVideoFullscreenControllerAVKit.mm:

(VideoFullscreenControllerContext::~VideoFullscreenControllerContext):

5:59 AM Changeset in webkit [247416] by Alan Bujtas

• 28 edits
  4 adds in trunk

Cannot bring up custom media controls at all on v.youku.com
​https://bugs.webkit.org/show_bug.cgi?id=199699
<rdar://problem/51835327>

Reviewed by Simon Fraser.

Source/WebCore:

The "find the node under the finger" heuristic should only find nodes that are visible to hit-testing.

When the user taps on the screen, we run a "find the best node under the finger" heuristic and use the node's location
to dispatch the associated event (e.g. mousePressed).
Ideally the "best node under the finger" and the final target node for the associated event are the same.
However these two methods configure the hit-testing process differently which could lead to node mismatch.
The "best node" heuristic calls hit-testing with AllowChildFrameContent. This flag allows hit-testing to descend into
subframes even if the subframe is not visible to hit-testing (visibility: hidden).
While event dispatching never descends into subfames through hit-testing, but instead it forwards the dispatching to subframes that are visible to hit-testing.

This patch addresses the mismatching node issue by calling the descending version of hit-testing with a flag that enforces visiblity check before descending into a subframe.

Tests: fast/events/touch/ios/visibility-hidden-iframe-click.html

fast/events/touch/ios/visibility-hidden-nested-iframe-click.html

• page/ios/FrameIOS.mm:

(WebCore::Frame::hitTestResultAtViewportLocation):

• rendering/HitTestRequest.h:

(WebCore::HitTestRequest::skipsChildFrameContentInvisibleToHitTest const):

• rendering/RenderWidget.cpp:

(WebCore::RenderWidget::nodeAtPoint):

Source/WebKit:

• WebProcess/InjectedBundle/InjectedBundleNavigationAction.cpp:

(WebKit::InjectedBundleNavigationAction::InjectedBundleNavigationAction):

• WebProcess/WebPage/Cocoa/WebPageCocoa.mm:

(WebKit::WebPage::performDictionaryLookupAtLocation):

• WebProcess/WebPage/WebFrame.cpp:

(WebKit::WebFrame::hitTest const):

• WebProcess/WebPage/WebPage.cpp:

(WebKit::handleContextMenuEvent):
(WebKit::WebPage::characterIndexForPointAsync):

• WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::handleStylusSingleTapAtPoint):
(WebKit::textInteractionPositionInformation):

• WebProcess/WebPage/mac/WebPageMac.mm:

(WebKit::WebPage::shouldDelayWindowOrderingEvent):
(WebKit::WebPage::acceptsFirstMouse):
(WebKit::WebPage::performImmediateActionHitTestAtLocation):

Source/WebKitLegacy/mac:

• WebCoreSupport/WebFrameLoaderClient.mm:

(WebFrameLoaderClient::actionDictionary const):

• WebView/WebFrame.mm:

(-[WebFrame elementAtPoint:]):

• WebView/WebHTMLView.mm:

(-[WebHTMLView elementAtPoint:allowShadowContent:]):

• WebView/WebImmediateActionController.mm:

(-[WebImmediateActionController performHitTestAtPoint:]):

Source/WebKitLegacy/win:

• WebActionPropertyBag.cpp:

(WebActionPropertyBag::Read):

• WebView.cpp:

(WebView::handleContextMenuEvent):
(WebView::elementAtPoint):

LayoutTests:

• fast/events/touch/ios/visibility-hidden-iframe-click-expected.txt: Added.
• fast/events/touch/ios/visibility-hidden-iframe-click.html: Added.
• fast/events/touch/ios/visibility-hidden-nested-iframe-click-expected.txt: Added.
• fast/events/touch/ios/visibility-hidden-nested-iframe-click.html: Added.

4:07 AM Changeset in webkit [247415] by Chris Dumez

• 3 edits in trunk/Source/WebCore

Fix non thread-safe usage of makeWeakPtr() in MediaPlayerPrivateAVFoundation
​https://bugs.webkit.org/show_bug.cgi?id=199777

Reviewed by Eric Carlson.

The code was calling makeWeakPtr() on a main-thread object, from a background thread.
This is not thread safe. To address the issue, this patches creates the WeakPtr ahead
of time, on the main thread.

• platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:

(WebCore::MediaPlayerPrivateAVFoundation::MediaPlayerPrivateAVFoundation):
(WebCore::MediaPlayerPrivateAVFoundation::scheduleMainThreadNotification):
(WebCore::MediaPlayerPrivateAVFoundation::dispatchNotification):

• platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h: