Bug 208084 - [iPadOS] REGRESSION(r247667): Autosizing style changes don't invalidate RenderText's preferred logical widths
Summary: [iPadOS] REGRESSION(r247667): Autosizing style changes don't invalidate Rende...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Myles C. Maxfield
URL:
Keywords: InRadar
: 208231 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-02-21 17:29 PST by Myles C. Maxfield
Modified: 2020-03-10 12:10 PDT (History)
15 users (show)

See Also:


Attachments
Needs test (6.94 KB, patch)
2020-02-21 17:29 PST, Myles C. Maxfield
no flags Details | Formatted Diff | Diff
Patch (10.66 KB, patch)
2020-02-21 19:04 PST, Myles C. Maxfield
no flags Details | Formatted Diff | Diff
Patch (10.72 KB, patch)
2020-02-21 19:06 PST, Myles C. Maxfield
darin: review+
Details | Formatted Diff | Diff
Patch for rolling back in (15.49 KB, patch)
2020-02-26 12:54 PST, Myles C. Maxfield
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Myles C. Maxfield 2020-02-21 17:29:11 PST
[iOS] [iPadOS] REGRESSION(r247667): Autosizing style changes don't invalidate RenderText's preferred logical widths
Comment 1 Myles C. Maxfield 2020-02-21 17:29:34 PST
Created attachment 391436 [details]
Needs test
Comment 2 Myles C. Maxfield 2020-02-21 19:04:43 PST
Created attachment 391444 [details]
Patch
Comment 3 Myles C. Maxfield 2020-02-21 19:06:15 PST
Created attachment 391445 [details]
Patch
Comment 4 Myles C. Maxfield 2020-02-21 19:06:45 PST
<rdar://problem/59463898>
Comment 5 Darin Adler 2020-02-23 14:49:50 PST
Comment on attachment 391445 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391445&action=review

This looks like a good solution

> Source/WebCore/style/StyleAdjuster.h:55
> +        operator bool() const { return newFontSize || newLineHeight; }

Maybe "explicit operator bool" is better here? I think that’s usually what we use when we can check something as a bool, but wouldn’t want to convert it into a bool.
Comment 6 Simon Fraser (smfr) 2020-02-24 10:54:37 PST
Comment on attachment 391445 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391445&action=review

> Source/WebCore/page/Page.cpp:2990
> +                        renderer.setStyle(WTFMove(newStyle), StyleDifference::Equal);

Isn't StyleDifference::Equal a lie here? Don't you need the right diff to trigger layout?
Comment 7 Myles C. Maxfield 2020-02-24 11:26:11 PST
Comment on attachment 391445 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391445&action=review

>> Source/WebCore/page/Page.cpp:2990
>> +                        renderer.setStyle(WTFMove(newStyle), StyleDifference::Equal);
> 
> Isn't StyleDifference::Equal a lie here? Don't you need the right diff to trigger layout?

It isn't a lie, because it's being passed as "minimumStyleDifference" and RenderElement::setStyle computes the style diff itself, and computes "diff = std::max(diff, minimalStyleDifference);". So StyleDifference::Equal here acts as a noop.
Comment 8 Simon Fraser (smfr) 2020-02-24 11:38:05 PST
OK
Comment 9 zalan 2020-02-24 11:40:49 PST
(In reply to Myles C. Maxfield from comment #7)
> Comment on attachment 391445 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=391445&action=review
> 
> >> Source/WebCore/page/Page.cpp:2990
> >> +                        renderer.setStyle(WTFMove(newStyle), StyleDifference::Equal);
> > 
> > Isn't StyleDifference::Equal a lie here? Don't you need the right diff to trigger layout?
> 
> It isn't a lie, because it's being passed as "minimumStyleDifference" and
> RenderElement::setStyle computes the style diff itself, and computes "diff =
> std::max(diff, minimalStyleDifference);". So StyleDifference::Equal here
> acts as a noop.
I'd just rely on the default value then.
Comment 10 Myles C. Maxfield 2020-02-25 13:27:03 PST
> I'd just rely on the default value then.

Default value!!!! 😮
Comment 11 Myles C. Maxfield 2020-02-25 13:51:21 PST
Committed r257373: <https://trac.webkit.org/changeset/257373>
Comment 12 Myles C. Maxfield 2020-02-25 19:38:13 PST
https://bugs.webkit.org/show_bug.cgi?id=208231 fixes the test failure
Comment 13 Darin Adler 2020-02-26 08:48:01 PST
Comment on attachment 391445 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391445&action=review

> Source/WebCore/style/StyleAdjuster.cpp:637
> +bool Adjuster::adjustForTextAutosizing(RenderStyle& style, const Element& element, AdjustmentForTextAutosizing adjustment)
> +{
> +    AutosizeStatus::updateStatus(style);
> +    if (auto newFontSize = adjustment.newFontSize) {
> +        auto fontDescription = style.fontDescription();
> +        fontDescription.setComputedSize(*newFontSize);
> +        style.setFontDescription(WTFMove(fontDescription));
> +        style.fontCascade().update(&element.document().fontSelector());
> +    }
> +    if (auto newLineHeight = adjustment.newLineHeight)
> +        style.setLineHeight({ *newLineHeight, Fixed });
> +    return adjustment.newFontSize || adjustment.newLineHeight;
> +}

Should we also check if the size and height just *happen* to match what’s already in the style, and return bool if they aren’t changing?
Comment 14 Ryan Haddad 2020-02-26 10:26:33 PST
The test added with this change is a flaky failure on iOS. See https://bugs.webkit.org/show_bug.cgi?id=208245
Comment 15 Ryan Haddad 2020-02-26 10:34:17 PST
Since this broke an existing test (which EWS caught) and the newly added test is frequently failing, I think we should roll this out.
Comment 16 Jacob Uphoff 2020-02-26 10:45:23 PST
Reverted r257373 for reason:

This commit introduced one test that is a flaky failure on ios bots and broke another test

Committed r257481: <https://trac.webkit.org/changeset/257481>
Comment 17 Myles C. Maxfield 2020-02-26 11:47:44 PST
I fixed it already in https://bugs.webkit.org/show_bug.cgi?id=208231 but didn't land in time :(
Comment 18 Myles C. Maxfield 2020-02-26 12:54:01 PST
Created attachment 391770 [details]
Patch for rolling back in
Comment 19 Myles C. Maxfield 2020-02-26 12:55:39 PST
*** Bug 208231 has been marked as a duplicate of this bug. ***
Comment 20 Jacob Uphoff 2020-02-26 13:23:43 PST
(In reply to Myles C. Maxfield from comment #17)
> I fixed it already in https://bugs.webkit.org/show_bug.cgi?id=208231 but
> didn't land in time :(

The fix you have in https://bugs.webkit.org/show_bug.cgi?id=208231 was for the test that broke with the commit that rolled out but there was no mention of fixing the test that was introduced that was flaky failing. Are you saying that was resolved in in 208231?
Comment 21 Myles C. Maxfield 2020-02-26 18:35:03 PST
The latest patch should deal with the flakes, and EWS is all green. I'm going to cq+ and watch the bots.
Comment 22 WebKit Commit Bot 2020-02-26 19:18:43 PST
Comment on attachment 391770 [details]
Patch for rolling back in

Clearing flags on attachment: 391770

Committed r257550: <https://trac.webkit.org/changeset/257550>
Comment 23 Ryan Haddad 2020-02-27 12:04:54 PST
(In reply to Myles C. Maxfield from comment #21)
> The latest patch should deal with the flakes, and EWS is all green. I'm
> going to cq+ and watch the bots.
fast/text-autosizing/ios/idempotentmode/viewport-change-relayout.html is failing on iOS bots again after re-landing the change:
https://build.webkit.org/results/Apple%20iOS%2013%20Simulator%20Release%20WK2%20(Tests)/r257568%20(2790)/fast/text-autosizing/ios/idempotentmode/viewport-change-relayout-diffs.html

I re-opened https://bugs.webkit.org/show_bug.cgi?id=208245
Comment 24 Myles C. Maxfield 2020-03-10 12:10:30 PDT
Fixed in r257651.