[IFC][Float] Incorrectly placed float boxes may generate series of empty lines
    https://bugs.webkit.org/show_bug.cgi?id=257261
    <rdar://108742128>

    Reviewed by Antti Koivisto.

    When intrusive floats prevent us from placing any content at the current vertical position,
    the candidate position for the next line is computed by looking at such intrusive floats.
    e.g.

      Two float boxes with the inline content of "foobar".

      _______    _______
     |       |  |       |
     | left  |  | right |
     |_______|  |       |
                |_______|

     1. "foobar" does not fit at y: 0 (overlaps "left").
     2. we find 2 intrusive floats at y: 0
     3. vertical position for next line is at the bottom of "left1"

    This is rather simple, but if float placement bugs produce some vertical gaps between floats
    e.g.

      _______    _______
     |       |  |       |
     | left1 |  | right |
     |_______|  |       |
                |_______|

      _______
     |       |
     | left2 |
     |_______|

     (note that left2 is supposed to be vertically adjacent to left1)

     Now if we run line layout:

     1. "foobar" does not fit at y: 0 -> vertical position for next line is at the bottom of "left1"
     2. "foobar" still does not fit (assume it overlaps "right") -> position for next line is at the bottom of "right"
     3. now assume that "foobar" is tall and it does not fit between the bottom of the "right" and the top of this incorrectly placed "left2"

      _______    _______
     |       |  |       |
     | left1 |  | right |
     |_______|  |       |
                |_______|
        ____
       |
       |___
      _|_____
     | |     |
     | |     |
     |_______|

     running "let's find the position for next line by avoiding intrusive floats" logic in InlineFormattingGeometry::logicalTopForNextLine()
     finds no intrusive float at the bottom of the "right" float (that's what #2 computed as candidate position).
     This is an unexpected state (we assert) and in order not to get stuck on the same vertical position we advance by 1px for the next line hoping we would be able to place "foobar" there.
     While it helps to avoid forever looping, if the gap between the bottom of the "right" and the top of the "left2" is
     wide we may end up producing thousands of empty lines until we reach the top of the "left2" float box and finally get out of this unexpected state.

    In this patch, instead of advancing by 1px, we jump right to the bottom of the "left2" float box (bottom of all the floats in this floating context) and continue from there.

    * Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp:
    (WebCore::Layout::InlineFormattingGeometry::logicalTopForNextLine const): move float handling to a helper (intrusiveFloatBottom) and return
    the max of floatingContext.bottom() and lineLogicalRect.bottom().

    Canonical link: https://commits.webkit.org/264579@main

Canonical link: https://commits.webkit.org/259548.800@safari-7615-branch

https://bugs.webkit.org/show_bug.cgi?id=261741
<rdar://112494003>

Reviewed by Antti Koivisto.

1. we do _not_ construct renderers for “display: none” iframes
2. we do construct render tree for the “display: none” iframe’s content

we do #2 because JS may ask for geometry information on content inside a “display: none” iframe.

e.g.
<div><iframe srcdoc=“text” style="display: none;" id=iframe></iframe></div>

where:
iframe.contentDocument.body.offsetHeight should return the value of “18px”

the markup above triggers the following 2 render trees:

Main document:
  RenderView
    HTML RenderBlock
      BODY RenderBody
        DIV RenderBlock

(^^ no renderer here for the “display: none” iframe)

iframe document:
  RenderView
    HTML RenderBlock
      BODY RenderBody
        #text RenderText

(^^ this is the content _inside_ the "display: none" iframe)

We not only construct a render tree for the invisible iframe content, but also (as part of the tree construction) we schedule an async layout on them
This patch drops such async layout requests on the floor and keep the renderers dirty until after either
1. sync layout is triggered (JS -> DOM API)
2. iframe becomes visible (display != none)

* LayoutTests/fast/dynamic/display-none-iframe-async-layout-expected.html: Added.
* LayoutTests/fast/dynamic/display-none-iframe-async-layout.html: Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::shouldScheduleLayout const):

Canonical link: https://commits.webkit.org/268148@main

    Office.com is slow to respond
    https://bugs.webkit.org/show_bug.cgi?id=261741
    <rdar://112494003>

    Reviewed by Antti Koivisto.

    1. we do _not_ construct renderers for “display: none” iframes
    2. we do construct render tree for the “display: none” iframe’s content

    we do #2 because JS may ask for geometry information on content inside a “display: none” iframe.

    e.g.
    <div><iframe srcdoc=“text” style="display: none;" id=iframe></iframe></div>

    where:
    iframe.contentDocument.body.offsetHeight should return the value of “18px”

    the markup above triggers the following 2 render trees:

    Main document:
      RenderView
        HTML RenderBlock
          BODY RenderBody
            DIV RenderBlock

    (^^ no renderer here for the “display: none” iframe)

    iframe document:
      RenderView
        HTML RenderBlock
          BODY RenderBody
            #text RenderText

    (^^ this is the content _inside_ the "display: none" iframe)

    We not only construct a render tree for the invisible iframe content, but also (as part of the tree construction) we schedule an async layout on them
    This patch drops such async layout requests on the floor and keep the renderers dirty until after either
    1. sync layout is triggered (JS -> DOM API)
    2. iframe becomes visible (display != none)

    * LayoutTests/fast/dynamic/display-none-iframe-async-layout-expected.html: Added.
    * LayoutTests/fast/dynamic/display-none-iframe-async-layout.html: Added.
    * Source/WebCore/dom/Document.cpp:
    (WebCore::Document::shouldScheduleLayout const):

    Canonical link: https://commits.webkit.org/268148@main
Identifier: 265423.1037@safari-7616-branch

    [IFC][Float] Incorrectly placed float boxes may generate series of empty lines
    https://bugs.webkit.org/show_bug.cgi?id=257261
    <rdar://108742128>

    Reviewed by Antti Koivisto.

    When intrusive floats prevent us from placing any content at the current vertical position,
    the candidate position for the next line is computed by looking at such intrusive floats.
    e.g.

      Two float boxes with the inline content of "foobar".

      _______    _______
     |       |  |       |
     | left  |  | right |
     |_______|  |       |
                |_______|

     1. "foobar" does not fit at y: 0 (overlaps "left").
     2. we find 2 intrusive floats at y: 0
     3. vertical position for next line is at the bottom of "left1"

    This is rather simple, but if float placement bugs produce some vertical gaps between floats
    e.g.

      _______    _______
     |       |  |       |
     | left1 |  | right |
     |_______|  |       |
                |_______|

      _______
     |       |
     | left2 |
     |_______|

     (note that left2 is supposed to be vertically adjacent to left1)

     Now if we run line layout:

     1. "foobar" does not fit at y: 0 -> vertical position for next line is at the bottom of "left1"
     2. "foobar" still does not fit (assume it overlaps "right") -> position for next line is at the bottom of "right"
     3. now assume that "foobar" is tall and it does not fit between the bottom of the "right" and the top of this incorrectly placed "left2"

      _______    _______
     |       |  |       |
     | left1 |  | right |
     |_______|  |       |
                |_______|
        ____
       |
       |___
      _|_____
     | |     |
     | |     |
     |_______|

     running "let's find the position for next line by avoiding intrusive floats" logic in InlineFormattingGeometry::logicalTopForNextLine()
     finds no intrusive float at the bottom of the "right" float (that's what #2 computed as candidate position).
     This is an unexpected state (we assert) and in order not to get stuck on the same vertical position we advance by 1px for the next line hoping we would be able to place "foobar" there.
     While it helps to avoid forever looping, if the gap between the bottom of the "right" and the top of the "left2" is
     wide we may end up producing thousands of empty lines until we reach the top of the "left2" float box and finally get out of this unexpected state.

    In this patch, instead of advancing by 1px, we jump right to the bottom of the "left2" float box (bottom of all the floats in this floating context) and continue from there.

    * Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp:
    (WebCore::Layout::InlineFormattingGeometry::logicalTopForNextLine const): move float handling to a helper (intrusiveFloatBottom) and return
    the max of floatingContext.bottom() and lineLogicalRect.bottom().

    Canonical link: https://commits.webkit.org/264579@main

Canonical link: https://commits.webkit.org/259548.800@safari-7615-branch
Identifier: [email protected]

    (REGRESSION 262148@main) No repaint when deleting text, possibly only when the deleted text spans more than one line
    https://bugs.webkit.org/show_bug.cgi?id=257043
    <rdar://109538333>

    Reviewed by Antti Koivisto.

    Normally while editing inline content in a content-editable container e.g

      "This is some long
       long long long
       long text content"

      and select/delete "long long text" (spanning over line#2 and #3)

    What happens is RenderText receives a content mutation event pointing to the _beginning_ of "long long text".
    As a result we damage line #2 and run a partial layout staring from line#2 until after we see no layout change anymore or we hit content end.

    However some JS based editors call innerHTML instead to mimic editing steps turning the above example to a "range replace"
    type of mutation where the entire text content is getting replaced with the "new", shortened content.

    In such cases, instead of receiving the position of the actual damage, we end up with the offset value of 0
    since the entire content is being replaced (even though it's just a slight change in the text content)
    Now we damage line#0 and start running layout from the very first line until we see no layout change...which is the second line
    since the actual damage is on the third line.

    Since IFC does not support such mutations yet, in this patch we disable range based bailout which means while
    we still run partial inline layout, we always go all the way to the bottom of the content.

    /fast/inline/range-replace-partial-layout-invalidation-expected.html: Added.
    * LayoutTests/fast/inline/range-replace-partial-layout-invalidation.html: Added.
    * Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp:
    (WebCore::Layout::InlineInvalidation::textWillBeRemoved):

    Canonical link: https://commits.webkit.org/264274@main

Identifier: [email protected]

    (REGRESSION 262148@main) No repaint when deleting text, possibly only when the deleted text spans more than one line
    https://bugs.webkit.org/show_bug.cgi?id=257043
    <rdar://109538333>

    Reviewed by Antti Koivisto.

    Normally while editing inline content in a content-editable container e.g

      "This is some long
       long long long
       long text content"

      and select/delete "long long text" (spanning over line#2 and #3)

    What happens is RenderText receives a content mutation event pointing to the _beginning_ of "long long text".
    As a result we damage line #2 and run a partial layout staring from line#2 until after we see no layout change anymore or we hit content end.

    However some JS based editors call innerHTML instead to mimic editing steps turning the above example to a "range replace"
    type of mutation where the entire text content is getting replaced with the "new", shortened content.

    In such cases, instead of receiving the position of the actual damage, we end up with the offset value of 0
    since the entire content is being replaced (even though it's just a slight change in the text content)
    Now we damage line#0 and start running layout from the very first line until we see no layout change...which is the second line
    since the actual damage is on the third line.

    Since IFC does not support such mutations yet, in this patch we disable range based bailout which means while
    we still run partial inline layout, we always go all the way to the bottom of the content.

    /fast/inline/range-replace-partial-layout-invalidation-expected.html: Added.
    * LayoutTests/fast/inline/range-replace-partial-layout-invalidation.html: Added.
    * Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp:
    (WebCore::Layout::InlineInvalidation::textWillBeRemoved):

    Canonical link: https://commits.webkit.org/264274@main

Identifier: [email protected]

…s for the processed blocks

https://bugs.webkit.org/show_bug.cgi?id=270450
rdar://118832222

Reviewed by NOBODY (OOPS!).

Eliminate common subexpressions in B3 is used to remove redundant Load and Store nodes.
Current algorithm removes block reads info after processing each block. This is wrong
since some Store nodes may be deleted erroneously due to the missing reads info from
the processed blocks. Consider this B3 graph:

    BB#0:
        ...
    Successors: WebKit#1

    BB#1:
    Predecessors: #0, WebKit#2
        ...
        @A = Load(addr, Reads:Top)
        ...
    Successors: WebKit#2

    BB#2:
    Predecessors: WebKit#1
        ...
        @b = Store(..., addr, Writes:Top)
        ...
        ...= <Node>(..., Reads:Top)
        ...
        @c = Store(..., addr, Writes:Top)
        ...
    Successors: Then:WebKit#1, Else:WebKit#3

    BB#3:
    Predecessors: WebKit#2
        ...
        @d = Store(..., addr, Writes:Top)
        ...

Before processing ECS, these blocks should have reads, writes, and storesAtHead status:

    #0: {reads = , writes = , storesAtHead = {}, ...}
    WebKit#1: {reads = Top, writes = , storesAtHead = {}, ...}
    WebKit#2: {reads = Top, writes = Top, storesAtHead = {addr=>@b}, ...}
    WebKit#3: {reads = , writes = Top, storesAtHead = {addr=>@d}, ...}

When processing @c at WebKit#2, the reads info of WebKit#1 is deleted since it's processed before.
In the next findStoreAfterClobber(@c), it will traverse all paths after @c to find
matching candidate nodes to prove that the node is redundant. A Store node should not
be deleted if any path may interfere with the data stored at the Store node's target
address (any read or write heap range overlaps the range where the data is stored).

In this case, two candidates @d and @b are found for paths WebKit#2 -> WebKit#3 and WebKit#2 -> WebKit#1 -> WebKit#2
respectively for @c, where @b is not correct since the stored data of @c may dependent
on @A. And the root cause is that the reads info were for WebKit#1 was deleted after processing.
To fix this issue, we should update block reads info after processing each nodes.

* JSTests/stress/ecs-store-with-loop.js: Added.
(foo):
(main):
* Source/JavaScriptCore/b3/B3EliminateCommonSubexpressions.cpp:
* Source/JavaScriptCore/b3/testb3.h:
* Source/JavaScriptCore/b3/testb3_3.cpp:
(testCSEStoreWithLoop):
(addShrTests):

https://bugs.webkit.org/show_bug.cgi?id=270565
rdar://problem/124126629

Reviewed by Antti Koivisto

Contains upstream commits:
git log --oneline acba61cb3e27f15b56ca781813efa357b9ca0f1f..b2773c110f641869afbb1e3b2ae4651dcfd1b1b2 --pretty=%h %s
b2773c110f Vulkan: Bug fix in immutable sampler pipeline layout recreation
3c08d69612 CL: Add DEVICE_NOT_FOUND case for context creation
f044aaf821 Vulkan: Create instance/device without access to Display
47cd0529f1 Fix assert invoking #line during macro invocation
27423bffff Metal: Generate names for rewritten inputs
2ad7b23b13 Add a missing #include.
545e3f6e11 Vulkan: Decouple RendererVk from egl::BlobCache
95294b2468 Android: Add Galaxy S22 support (Xclipse)
5678ad09aa Roll Chromium from 43d81add625d to 632158ced47e (570 revisions)
0ad73958dc Deduplicate and fix ConstStrLen implementations
258b751f57 OpenCL/Vulkan: Fix processedOptions whitespace
b978974d98 Update frontend support for QCOM foveated extensions
3fa8d578ad Make appendDecimal use the last char of the buffer
39040b0b89 Vulkan: Decouple RendererVk from EGL attributes
4e6fe5e0db Vulkan: Cache ImageLoadContext in context
871a309c72 Fix layout(index=) parse assert on es 100 shaders
ec6d628863 egl: Add logic to select preferred display
799997d427 Roll Chromium from 40412b90c691 to 43d81add625d (324 revisions)
fc440afa62 Vulkan: Move DS builder class to Vk utils
f85b6970a9 OpenCL/Vulkan: Implement program get[Build]Info
0ed0de4f0b OpenCL/Vulkan: Add initial program build support
1c2d2417c9 Bugfix in CreateWithEGLConfig1010102Support test
f26c8d0874 Roll VK-GL-CTS from d023c17ac299 to 1918ab4d4806 (13 revisions)
21381f5e1c Roll Chromium from 6b34297e693d to 40412b90c691 (533 revisions)
2ee295b475 Vulkan: Add per-level image update tracker
1ceddbf697 OpenCL/Vulkan: Add createProgram routines
f7cd1c5606 Tests: Add Toca Life World trace
56a291e819 Rework external image capture
8142dde7f4 Tests: Add Pokemon Masters Ex trace
b45b350ade Add skip for Pokemon Masters Ex validation warning
69f5e9ca60 Roll vulkan-deps from f43c5512f6d7 to 12f9cddb3ff7 (6 revisions)
19e725e49c Roll Chromium from 579e74402476 to 6b34297e693d (578 revisions)
4d36224267 Vulkan: Remove call to angle::GetSystemInfo()
cdf6220c28 Reland "Vulkan: Feature addition for QCOM foveated rendering extensions"
a971e5b42e Account for zero vector axes in Mat4::Rotate(...)
434a5b0170 Fix WebKit#2 upload_results_to_perf_dashboard usage
057db6ef57 Add ANGLE experimental S22 build and test
f8dac42e95 Fix upload_results_to_perf_dashboard usage
dbbcf33eeb Roll vulkan-deps from 28960bf4a098 to f43c5512f6d7 (13 revisions)
d334a6f265 Roll Chromium from cc3c5664ec19 to 579e74402476 (619 revisions)
a627dd8976 Revert "Vulkan: Feature addition for QCOM foveated rendering extensions"
6eaaad7c60 Create ImageHelper.
75c8ef1c63 Update cached component type masks on attachment redefinitions
6f2daf0588 Context: Limit max vtx uniform vectors to 256 during capture
2fb425d284 Roll vulkan-deps from dd6c2371c85d to 28960bf4a098 (10 revisions)
b0215166ed Roll SwiftShader from 0f69b790c7a4 to bbe6452b420c (1 revision)
9100f2ec79 Roll Chromium from 16b5225bad88 to cc3c5664ec19 (580 revisions)
f0af4730d9 Vulkan: Catch misuse of AddToPNextChain
72cf9915f5 Vulkan: Feature addition for QCOM foveated rendering extensions
0afcac60ed Handle count = 0 in DrawElementsIndirect
3c517e457a Vulkan: Process ClearEmulatedChannels update first
38cc4cf099 Vulkan: Update flushStagedUpdate to use switchcase
58c20052bb Fix build error when git history not fully available
d354c4dca1 Roll VK-GL-CTS from d15e5faec700 to d023c17ac299 (1 revision)
425be99db6 Roll vulkan-deps from 602ab4120d74 to dd6c2371c85d (8 revisions)
1fe63fecab Roll SwiftShader from eb75201a4e03 to 0f69b790c7a4 (1 revision)
834ca37fa6 Roll Chromium from b54ff9b1d5ed to 16b5225bad88 (644 revisions)

Canonical link: https://commits.webkit.org/275754@main