s/end eventually/and eventually/g

Hmmm, it may not be because of flexbox, as I've removed it entirely and it still freezes. This might be a false alarm, sorry about that.

It seems like a CSS issue, I can not get devtools to pause on any code.

If I click the devtools pause button, it will remain frozen until after rendering finally happens, then pause on the next timeout after that. I can't get it to pause in any sort of loop, and I don't have much logic on this site, it's mostly just HTML/CSS.

Alright, I found the source of the problem (but not why):

If we remove the `<img>` tag containing the `BirdsEye.svg` file in its `src` attribute, then the problem goes away.

I've attached a new zip with this small difference.

Is it an SVG rendering problem then?

Deleted: freeze-2.zip 13.9 MB

freeze-2.zip 13.9 MB Download

Unable to reproduce the issue on chrome reported version# 69.0.3497.81 using Mac 10.12.6 and 10.13.6 with steps mentioned below:
1) Launched chrome reported version, dragged and dropped the '.html' file provided in comment# 5
2) Able to see the file loaded successfully and tab didn't get freeze 

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which in further triaging it. Try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists or test this issue on latest chrome stable# 69.0.3497.100. You can download chrome stable from URL: http://www.chromium.org/getting-involved/dev-channel.

Thanks!

Deleted: 889183.mp4 2.4 MB

	889183.mp4 2.4 MB View Download

Looks to be a SVG perf problem from your description. I have not been able to reproduce it however.

This appears to be related to the ~18M data URL in BirdsEye.svg - loading that file alone is very slow - but loading in the image context appears to be even slower.

My suspicion would be that the ~18M attribute triggers N^2 behavior in libxml after something ended up fragmenting the input buffer... (18M split in 4k blocks yields ~ 4600 blocks - each block yielding a longer string to scan [from the end])

Suspicion from c#10 has been confirmed. (Noticed some reasonbly low-hanging fruit in URL handling that I'll try to land optimizations for.)

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

commit b7581ca4baf904b7fdddd28d95c8e1238f0f2271
Author: Fredrik Söderquist <fs@opera.com>
Date: Wed Oct 03 13:16:34 2018

Use StringUTF8Adaptor in KURL::operator GURL

This can save a conversion to UTF-8 (and copy to CString) for ASCII-only
URLs.

Bug: 889183
Change-Id: Ie5edad4a95da70bac0acd27b01d6e03cd1315bbd
Reviewed-on: https://chromium-review.googlesource.com/c/1257926
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596192}
[modify] https://crrev.com/b7581ca4baf904b7fdddd28d95c8e1238f0f2271/third_party/blink/renderer/platform/weborigin/kurl.cc

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

commit 16dc8abf50286bc3d04f1e272ddea0faa8434602
Author: Fredrik Söderquist <fs@opera.com>
Date: Thu Oct 04 09:37:51 2018

Avoid UTF-8->UTF-16 conversion in HashAndUTF8CharactersTranslator

The Translate() function can use the same check as Equal() to determine
if the string is ASCII-only. Saving a conversion from UTF-8 to UTF-16.

Bug: 889183
Change-Id: Ieffab05f34a1e4a2ef725e298e7f15e7ff14a3f8
Reviewed-on: https://chromium-review.googlesource.com/c/1257928
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Reviewed-by: Yuta Kitamura <yutak@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596556}
[modify] https://crrev.com/16dc8abf50286bc3d04f1e272ddea0faa8434602/third_party/blink/renderer/platform/wtf/text/atomic_string_table.cc

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

commit 367ecfa989d3dd43cf7412b517c22a17f2343b04
Author: Fredrik Söderquist <fs@opera.com>
Date: Thu Oct 04 14:44:41 2018

Replace WebStringToGURL with KURL::operator GURL in NetworkUtils

This allows reusing the data from the KURL - i.e does not require
performing canonicalization again.

Bug: 889183
Change-Id: I10e5f9b3725a0fb25594bc6dbe61791bb3826fe9
Reviewed-on: https://chromium-review.googlesource.com/c/1257927
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#596663}
[modify] https://crrev.com/367ecfa989d3dd43cf7412b517c22a17f2343b04/third_party/blink/renderer/platform/network/network_utils.cc

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

commit 3c675fda76ff2e451be14b535f675284eee08366
Author: Fredrik Söderquist <fs@opera.com>
Date: Fri Oct 05 11:42:56 2018

Avoid resolving the URL twice when initiating image loads

Rather than resolving the URL again during Task::Create, pass the KURL
resolved by ImageLoader::UpdateFromElement through.
Also move the resolution before the |loading_image_document_| special-
case.

Bug: 889183
Change-Id: I52ea65d1af96a5919e128f0623fa6bd9026850f7
Reviewed-on: https://chromium-review.googlesource.com/c/1254266
Reviewed-by: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#597071}
[modify] https://crrev.com/3c675fda76ff2e451be14b535f675284eee08366/third_party/blink/renderer/core/loader/image_loader.cc
[modify] https://crrev.com/3c675fda76ff2e451be14b535f675284eee08366/third_party/blink/renderer/core/loader/image_loader.h