I confirmed that the graphs appear incorrectly cropped with --site-per-process, but render fine without it on Mac 63.0.3239.132.

There are ~13 OOPIFs on the repro page with --site-per-process, but the problematic graphs all seem to be in OOPIFs created from the following tags:

<object data="//openbenchmarking.org/embed.php?i=1801037-PTS-KPTI475220&amp;sha=7712ada&amp;p=2" type="image/svg+xml"></object>

Perhaps using <object> (and not <iframe>) and/or SVG leads to incorrect sizing info for the frame?  Adding a few people who might have ideas.

Confirmed on Linux and ChromeOS as well.  I see it on both high DPI and non high DPI devices, so it's not that (even though it initially looks like the image is drawn at the wrong scale factor).

I agree that it sounds like an SVG and/or <object> tag bug.  wjmaclean@, can you triage and find an owner, since kenrb@ is out?

I'm *not* able to reproduce it on Linux (Version 63.0.3239.132 (Official Build) (64-bit)).

+ekaramad@ who I believe knows some of the object/iframe details in Blink and may be able to help.

To assist those of us who cannot repro this, could someone post a screen capture of a repro case? Thanks!

Hi,

i was trying to capture a screen shot of the issue but it's no more visible.
Chrome version is now 63.0.3239.132 on my PC, (was 63.0.3239.108 before). Did the changes between the two versions explain why I can't reproduce the issue anymore ?
(attached screenshot is the OK rendering case)

Deleted: Issue 798974 - OK.png 76.3 KB

	Issue 798974 - OK.png 76.3 KB View Download

Thanks for trying to get a screenshot!

I'm not sure what the difference is for those who can and cannot repro this ... I tried a (Linux64) build bisect to test out 63.0.3239.108 and could not get the reproduction there either, but perhaps others who have been able to repro can let us know if they're still seeing it.

FWIW, I also cannot repro on 63.0.3239.132 (Windows) with --site-per-process enabled via chrome://flags.

RE: #c7

It is possible that the fixes included between 63.0.3239.108 and 63.0.3239.132 have addressed this issue.  OTOH, none of the changes seems related when I look at https://chromium.googlesource.com/chromium/src/+log/63.0.3239.108..63.0.3239.132?pretty=fuller&n=10000

creis@ - I see that you were ableo to repro in #c4.  What version did the repro happen in?

Re #c9, I still find it odd I couldn't repro it in 63.0.3239.108 on Linux64 ... perhaps there's some other factor that's relevant?

Here's a screenshot from my repro in Mac Canary 65.0.3311.0, which is in the site-per-process trial.  Same thing reproed in 63.0.3239.132 as of yesterday.  The <object> was 300x150, instead of 612x240.

I'm guessing this doesn't repro anymore right now because the page already changed the HTML, from using <object> in #3, to this:

<img type="image/svg+xml" width="auto" height="auto" src="//openbenchmarking.org/embed.php?i=1801037-PTS-KPTI475220&amp;sha=83b9bc6&amp;p=2">

There's of course no more OOPIF when using <img>.  (I grabbed the screenshot on a cached copy from yesterday.) Perhaps Chrome with site isolation wasn't the only platform experiencing sizing issues?  

If we still wanted to repro, we could try changing this back to the <object> tag I mentioned in #3, and see if it made sense to match the non-site-isolation behavior in that case.

Deleted: cropped-graphs.png 168 KB

	cropped-graphs.png 168 KB View Download

Thanks Alex ... I hadn't realized the site had changed ... yes, using "object" instead of "img" causes the problem to repro.

This gives us somewhere to look ...

Some observations:

1) Without --site-per-process : img works, iframe sizes wrong, object works

2) With --site-per-process : img works, iframe sizes wrong, object sizes wrong

So *iframe* behaviour doesn't seem to change, but object does.

<object> performs "size negotiation" with SVG documents. This currently requires a LocalFrame relationship to work. (<iframe>s don't perform "size negotiation" and are thus unaffected by the embedded document.)

I am not quite sure what the right fix is but to me it looks like this might be a starting point:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/LocalFrameView.cpp?rcl=aa2fdaae0d11388c2c5115554de1d39b8469db13&l=919

were we currently return early in OOPIF process. Maybe somehow the parent process (recursively?) needs to be notified about this layout update.

I think a more practical solution for now is to disallow OOPIF for SVG documents
under <object>. Longer-term, comment 16 is a good approach.  crbug.com/442939  will
make that easier as well. fs@opera, what's the status of that bug?

Last thing I did on  issue 442939  was work on test coverage (since it dawned on me that there was virtually no, if any, coverage of the complicated cases.)

Agreed that, short-term, disallowing OOPIFs for SVG makes sense, though I'm not sure what the security implications might be. creis@, any thoughts here?

Perhaps the suggestion in comment #17 is most practical to resolve the issue temporarily. However, <svg> could apparently contain <script> so that might be against the purpose of OOPIF.

#20: how would the svg <script> work today if the svg is included via <img>, as in #12?  Would we also need to place svg's in <img> tags into OOPIFs?

I think svg inside <img> is not dynamic and no <script> is run. Inside an <iframe> or <object> could run <script>. I am reciting here but will try to find examples.
https://developer.mozilla.org/en-US/docs/Web/SVG/Element/image

So to sum up, <object type="image/svg+xml"> seems to me not much different than <object  typw="text/html">. Sample scripted SVG:

sample.svg:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="6cm" height="5cm" viewBox="0 0 600 500"
     xmlns="http://www.w3.org/2000/svg" version="1.1">

  <script type="application/ecmascript"> <![CDATA[
    function circle_click(evt) {
      window.alert('Will remove!');
      var object = window.parent.document.querySelector('object');
      object.parentNode.removeChild(object);
    }
  ]]> </script>
  <text> Click circle to remove it </text>
  <circle onclick="circle_click(evt)" cx="200" cy="200" r="200"
          fill="green"/>
</svg>

 ****

page.html:
<object data="./sample.svg" type="image/svg+xml"></object>

Thanks for the analysis.

Unfortunately, if cross-site SVGs in object tags run scripts and have access to DOM APIs as comment 23 shows, then I don't think skipping OOPIFs for them is possible.  As soon as they access any DOM APIs for site data (e.g., localStorage, cookies, passwords, anything else we've protected by Site Isolation), the browser process will kill the renderer process.  That can't be avoided without nullifying much of the security value of Site Isolation, since a renderer could pretend to have an SVG from a victim site of their choice to bypass the rules.

For example, site a.com embeds an SVG object from site b.com.  The SVG file accesses localStorage, triggering an IPC to access b.com's localStorage.  The browser process sees that request coming from a renderer process that is origin-locked to a.com, and thus it kills the process.

We may need to look into how to better support it instead, perhaps as ekaramad@ noted in comment 16.

I see, this makes sense. I didn't consider the attack vector explained in comment 24.

It seems then that we need to fix SVG inside <object> to support OOPIF. Looking into
how quickly that can happen now...

chrishtr@ - since this is dependent on layout, is this something you could take stewardship of?

Yes.

Thanks for looking after this!

I have some scattered pieces (from  issue 442939  and some other intrinsic sizing cleanup I've been tinkering with) that might help here. I'll see about extracting those bits and upload them.

https://chromium-review.googlesource.com/c/chromium/src/+/860140

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26

commit 3969b6ed601d2bb6b1c3a5d480cfc17eae868c26
Author: Fredrik Söderquist <fs@opera.com>
Date: Thu Jan 11 01:34:18 2018

[CI] Refactor replaced element nested intrinsic sizing info extraction

This moves the access to a nested layout contexts (either a frame
embedded via LayoutEmbeddedObject or an SVG image via LayoutImage)
LayoutReplaced (LayoutSVGRoot) from LayoutReplaced to the relevant
subclasses (LayoutEmbeddedObject or LayoutImage.) The goal with this is
to eliminate the use of EmbeddedReplacedContent in LayoutReplaced.

Rather than accessing EmbeddedReplacedContent() and calling
ComputeIntrinsicSizingInfo() on the returned LayoutReplaced, a new
method GetNestedIntrinsicSizingInfo is added instead, and implemented in
the relevant subclasses. In LayoutImage the EmbeddedReplacedContent()
method is kept around (for now), but in LayoutEmbeddedObject it's
removed, and instead rerouted via LocalFrameView.

NeedsPreferredWidthsRecalculation is moved from LayoutEmbeddedContent to
its subclass LayoutEmbeddedObject since this is the only subclass that
can modify its behavior - i.e can represent content that may can affect
the size of its embedder.

The IntrinsicSizingInfo struct is moved out from being an inner class of
LayoutReplaced.

Bug:  798974 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_layout_ng;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ia617a40d631e6b2e6bb2c9f39a1799766d7f58d6
Reviewed-on: https://chromium-review.googlesource.com/860140
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528524}
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/frame/LocalFrameView.cpp
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/frame/LocalFrameView.h
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/LayoutEmbeddedContent.cpp
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/LayoutEmbeddedContent.h
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/LayoutEmbeddedObject.cpp
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/LayoutEmbeddedObject.h
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/LayoutImage.cpp
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/LayoutImage.h
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/LayoutReplaced.cpp
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/LayoutReplaced.h
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/layout/ng/ng_layout_input_node.cc
[modify] https://crrev.com/3969b6ed601d2bb6b1c3a5d480cfc17eae868c26/third_party/WebKit/Source/core/svg/graphics/SVGImage.cpp

Tested the issue on Windows-10, Mac 10.13.1 and ubuntu 14.04 using latest chrome version #65.0.3318.0 and on the reported version 63.0.3239.108 as per comment#0
Attached a screen casts of both the behaviours of reported and latest chrome versions for reference.

Following are the steps followed to reproduce the issue.
------------
1. Launched Chrome and enabled "enable-site-per-process"
2. Navigated to https://www.phoronix.com/scan.php?page=article&item=linux-kpti-kvm&num=2

Note: Behaviours in both reported and latest chrome versions are similar. 

chrishtr@ - Could you please check the attached screen casts and please let us know the expected behaviour and please confirm the fix.

Thanks...!!

Deleted: 798974 in reported version.mp4 8.9 MB

	798974 in reported version.mp4 8.9 MB View Download

Deleted: 798974 latest. version.mp4 1.8 MB

	798974 latest. version.mp4 1.8 MB View Download

Re c#34

The original site at https://www.phoronix.com/scan.php?page=article&item=linux-kpti-kvm&num=2 is no longer valid for testing this bug, as they changed their html to use <img> instead of <object> for the SVG image.

While one can use devtools to change one of the <img> tags to <object> to see the effect, it might be better at some point to create a simpler repro case for testing.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f7325392c659433e67bbf2257788803f05a4e971

commit f7325392c659433e67bbf2257788803f05a4e971
Author: Fredrik Söderquist <fs@opera.com>
Date: Thu Jan 11 18:55:04 2018

[CI] Add intrinsic-dimensions-changed notifier to FrameOwner

This CL adds a notifier callback that is called whenever a property or
attribute that may affect the intrinsic dimensions of an <svg> is
changed - this includes 'width', 'height' and 'viewBox' as well as
'writing-mode' and font properties.
At present this callback doesn't do anything, but is expected to
eventually schedule a layout on the embedding object.

Bug:  442939 ,  798974 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I761ccaaec6b5dec20c2bfa4b5f06cf16d6c7eb24
Reviewed-on: https://chromium-review.googlesource.com/860932
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528689}
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/frame/FrameOwner.h
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/frame/RemoteFrameOwner.h
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/html/HTMLPlugInElement.h
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/layout/svg/LayoutSVGRoot.cpp
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/layout/svg/LayoutSVGRoot.h
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/svg/SVGLength.h
[modify] https://crrev.com/f7325392c659433e67bbf2257788803f05a4e971/third_party/WebKit/Source/core/svg/SVGSVGElement.cpp

Update:  Issue 442939  is almost fixed, after which I plan to implement IPCs
for the behavior in the presence of RemoteFrames.

 wjmaclean@, would you be able to provide any other site URL which uses <object> for the SVG image to verify this bug ?

So, I noticed that cross-site iframes have wrong devicePixelRatio scaling after the parent window is moved to a monitor with different DPI scale (noticeable on sites that embed Youtube videos). It is a regression with strict site isolation enabled.

Does this issue cover it or should I create a new issue? It seems a bit unclear to me.

I created  Issue 803442  anyway.

@c#39, yes, that's unrelated, so thanks for filing a new issue.

Next step:

1. Plumb intrinsic sizing change from child SVG to containing RemoteFrames.
2. IPC to the browser process and back to the RemoteFrame's owner containing the
intrinsic sizing information.
3. Handle intrinsic sizing in LayoutReplaced for a remote-subframe that has intrinsic sizing info 
on it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f

commit d7ab99b0c2c29cd08bcddd328bedea2b5d69151f
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Wed Jan 24 17:51:36 2018

[OOPIF] Implement intrinsic size update for remote frames.

When IntrinsicSizingInfo of a remote frame changes in a way
that can affect remote parent frames' layout, send an IPC
from the child renderer to the browser process, and from
there to the parent renderer with the new IntrinsicSizingInfo.

Bug:  798974 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I150156708faa566c656c3f7a624ef57f1dba1235
Reviewed-on: https://chromium-review.googlesource.com/877821
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#531596}
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/browser/DEPS
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/browser/frame_host/cross_process_frame_connector.cc
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/browser/frame_host/cross_process_frame_connector.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/browser/renderer_host/frame_connector_delegate.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/browser/renderer_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/browser/renderer_host/render_widget_host_view_child_frame.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/common/DEPS
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/common/frame_messages.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/common/view_messages.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/renderer/render_frame_proxy.cc
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/renderer/render_frame_proxy.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/renderer/render_widget.cc
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/content/renderer/render_widget.h
[add] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/LayoutTests/http/tests/svg/as-object/intrinsic-size-change-embedded-object.html
[add] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/LayoutTests/http/tests/svg/as-object/resources/objectcontents.svg
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/DEPS
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/exported/WebRemoteFrameImpl.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/exported/WebRemoteFrameImpl.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/BUILD.gn
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/EmbeddedContentView.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/FrameOwner.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/FrameView.h
[add] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/IntrinsicSizingInfo.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/LocalFrame.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/LocalFrame.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/LocalFrameView.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/RemoteFrameOwner.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/RemoteFrameView.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/RemoteFrameView.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/WebFrameWidgetBase.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/WebFrameWidgetImpl.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/frame/WebFrameWidgetImpl.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/html/HTMLPlugInElement.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/input/EventHandlingUtil.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/input/ScrollManager.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/inspector/InspectorLayerTreeAgent.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/layout/LayoutEmbeddedContent.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/layout/LayoutEmbeddedContent.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/layout/LayoutEmbeddedObject.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/layout/LayoutReplaced.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/layout/LayoutReplaced.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/layout/LayoutTreeAsText.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/layout/svg/LayoutSVGRoot.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/layout/svg/LayoutSVGRoot.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/page/scrolling/ScrollingCoordinatorTest.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/paint/PaintPropertyTreePrinter.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/paint/PrePaintTreeWalk.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/Source/core/svg/SVGSVGElement.cpp
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/public/BUILD.gn
[add] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/public/platform/WebIntrinsicSizingInfo.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/public/web/WebRemoteFrame.h
[modify] https://crrev.com/d7ab99b0c2c29cd08bcddd328bedea2b5d69151f/third_party/WebKit/public/web/WebWidgetClient.h

Hi Chris. My canary is extremely janky today. Looking at an ETW trace of mousewheel scrolling up and down in a gerrit review, it sorta looks to me like a lot of time is being spent in the browser process handling FrameHostMsg_UpdateResizeParams messages. Is it possible that these are being sent more often than you planned, or incurring more overhead than anticipated?

I'm not an ETW wizard, so it's possible that I'm mis-attributing where cycles are being wasted, but I figured it was worth pinging you since the jank sorta lines up with the latest CL here.

FrameHostMsg_UpdateResizeParams is not an IPC I added. But it could be related, let me try t
reproduce.

I checked on Gerrit and was unable to trigger any condition in which the
code from this issue was present. Do you have a particular Gerrit CL?
Or is it all of them?