Before chrome update it was fine for base64 images that has sizes of 200kb-300kb.

Now it freezes.

I just tested an base64 image that has a file size of 85kb, it works fine.

I am not able to reproduce this issue in 71.0.3577.0 canary or in 	69.0.3497.100 on windows. Please verifiy my reproducing method in screen recordings and check if I am missing something. 

Deleted: 2018-10-12_11-25-43.mp4 6.0 MB

	2018-10-12_11-25-43.mp4 6.0 MB View Download

Deleted: 2018-10-12_11-24-25.mp4 8.9 MB

	2018-10-12_11-24-25.mp4 8.9 MB View Download

The image file used above was below 10kb. Here is the same demo with a larger image file (~500kb). Although pasting the base64 takes a little longer, nothing hangs and the background updates.

Deleted: 2018-10-12_11-30-28.mp4 8.5 MB

	2018-10-12_11-30-28.mp4 8.5 MB View Download

Hello,

Thanks for looking at this. I am not too sure what changed too, i was able to do so (with the same machine) with the previous version of chrome (pre 69).

Also can you try replacing using the Elements Inspector instead of the Source Tab?

I just tried pasting the long string in the Sources tab, it worked. Pasting the long base64 string in the Elements tab still hangs.

Regards,
Carlos

Sorry I wasn't unable to reproduce this issue by pasting the base64 string in either the Console panel or in the Element panel (in its source code box or in the "Styles" box). If you may, could you please upload a screen recording? Thanks!

Hello,

attached recording. ill try to do another recording for an older version of chrome where it was working

Regards,
Carlos

Deleted: vid.mp4 1.9 MB

	vid.mp4 1.9 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on reported chrome #69.0.3497.100, but the issue is not seen on latest stable #70.0.3538.77 using Windows 10 by following below steps.

Steps:
=====
1.Launched chrome.
2.Navigated to "https://www.base64-image.de/".
3.Clicked on "copy CSS" button.
4.Navigated to jsfiddle.net and ran a piece of code ( taken reference from screencast provided in comment#8).
5.Pasted the URL in background attribute.
6.Observed that the background image got changed and Chrome Dev tool does not hang.

Attached screencast for reference.
@reporter: Could you please retry the issue on latest stable and let us know if the issue still persists. You can download the latest chrome from "https://www.chromium.org/getting-involved/dev-channel".
Thanks.!

Deleted: 893967.mp4 5.9 MB

	893967.mp4 5.9 MB View Download

thank you for looking at this. i'll try on chrome 70

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

ieaiaio@ A Gentle ping..

Request you to please check the issue on the latest Stable 70.0.3538.77 and update the thread with the behavior, which will help in further triaging.

Thanks..

Hi, i am using 70.0.3538.77 now and the problem is still there :(

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

i just tested again. it hanged for around 3 minutes, the chrome inspector became plain white. then after 4 minutes (7 mins total), the base64 string background was applied.

Jeez... three weeks and still unconfirmed?
Able to repro and bisect easily.

https://chromium.googlesource.com/chromium/src/+log/5e1d85fb..5e7123e8?pretty=fuller
Suspecting r563323 = d4b4b6db9850f945d12f4378f18c5e3ebd41e8ea = https://crrev.com/c/1076787 by kojii@chromium.org
"Store safe-to-break flag in HarfBuzzRunGlyphData"

Landed in 69.0.3447.0
Still present in 70-72.

The reason to suspect that CL is the stacktrace taken while the devtools UI is frozen:
 	chrome_child.dll!apply_forward
 	chrome_child.dll!hb_ot_map_t::apply<GPOSProxy>
 	chrome_child.dll!hb_ot_map_t::position
 	chrome_child.dll!_hb_ot_shape
 	chrome_child.dll!hb_shape_plan_execute
 	chrome_child.dll!hb_shape_full
 	chrome_child.dll!hb_shape
 	chrome_child.dll!blink::HarfBuzzShaper::ShapeSegment
 	chrome_child.dll!blink::HarfBuzzShaper::Shape
 	chrome_child.dll!blink::HarfBuzzShaper::Shape
 	chrome_child.dll!blink::CachingWordShapeIterator::ShapeWordWithoutSpacing
 	chrome_child.dll!blink::CachingWordShapeIterator::ShapeWord
 	chrome_child.dll!blink::CachingWordShapeIterator::ShapeToEndIndex
 	chrome_child.dll!blink::CachingWordShapeIterator::NextForAllowTabs
 	chrome_child.dll!blink::CachingWordShaper::Width
 	chrome_child.dll!blink::Font::Width
 	chrome_child.dll!blink::BreakingContext::CalculateWordWidth
 	chrome_child.dll!blink::BreakingContext::HandleText
 	chrome_child.dll!blink::LineBreaker::NextLineBreak
 	chrome_child.dll!blink::LayoutBlockFlow::LayoutRunsAndFloatsInRange
 	chrome_child.dll!blink::LayoutBlockFlow::LayoutRunsAndFloats
 	chrome_child.dll!blink::LayoutBlockFlow::LayoutInlineChildren
 	chrome_child.dll!blink::LayoutBlockFlow::LayoutChildren
 	chrome_child.dll!blink::LayoutBlockFlow::UpdateBlockLayout
 	chrome_child.dll!blink::LayoutBlock::UpdateLayout
	.........................

just like my job status, unconfirmed xD

Sorry for the delay, I appreciate the screencasts and stacktrace.

I'm not able to reproduce a hang anywhere close to 3 minutes, but I'm produce hangs around 3 - 7 seconds on a Linux desktop and Macbook pro.  Assuming that the gap in duration is due to a difference in hardware, we can work on a DT performance fix that will hopefully improve both.

With respect to the CL in c#17, I get hangs before: 4s, after: 7s.
cc'ing the author in case they have seen similar reports.

Pasting takes ONE SECOND before r563323, and multiple minutes after that.
4-core i7 4.4GHz CPU, 32MB RAM, no background processes or antivirus, Windows 7.

Before r563323, we used to ignore all characters that are longer than 64k without spaces for rendering. r563323 "fixed" that, so if you're dealing with a string longer than 64k without spaces, it's possible that we're slower.

If DT can make Elements tab the same as Source tab and achieve good enough perf, that's great. If you see perf hit with some CSS properties you can't change, I can try to help. Great if you can give me plain html/css that DT requires but is slow.

Note, this maybe platform or machine specific. The system fallback on Windows is very slow when the string is long because it involves IPC only on Windows due to sandbox differences. Not sure this symptom is hitting the case or not though.

hmmmm so short answer is 'wont fix'?

#22: absolutely not. r563323 was the right fix, but we should fix without causing this much perf regression.

#19 said he's going to work on a DevTools performance fix. Since Source pane is working fine, I think it's great if DevTools can fix Elements pane in the same way.

If the fix in DevTools is hard, or the problem is more general, I'll consider fix in the layout/fonts engine side. We're probably measuring the string multiple times only in Elements pane, and since the string is huge, there might be O(n!) or O(n^2) problem.

If that fix is hard, another possibility is simply to truncate rendering of such a long string. IIRC I heard Firefox does the similar -- does not render too long string at some hard limit. Rendering all glyphs is probably not necessary because before r563323, we were not rendering string >64k glyph in a run but nobody complained. r563323 was done for some other purpose and the fix was a side effect. We can intentionally trim glyphs >64k this time if it's needed.

Like c#23 says, we need to fix this.

I'm not able to repro a hang more than 5s anymore, on Win, Mac, Linux, so I need help with verifying any fix.

I have some reduced cases where copying the text, deleting it, and pasting it again should trigger a hang:

A) Estimated DevTools repro: http://jsfiddle.net/0omd6s3n/1/
B) Possible fix [nowrap, maxwidth]: http://jsfiddle.net/0omd6s3n/2/
C) Possible fix [css-contain]: http://jsfiddle.net/0omd6s3n/3/

For those who can repro a significant hang, could you please let us know if you can repro a hang in A), B), or C) ?  Also, could you please let us know if pasting long text in the Sources panel / in Console also produces a similarly long hang?

re #24, 
1) that string is too simple (a single letter repeated) and doesn't cause the bug neither in jsfiddle A nor in devtools.
2) jsfiddle A hangs for a minute when I follow the StR and paste a 300kB image encoded on https://www.base64-image.de/
   so I guess it's a good approximation

3) jsfiddle B opens instantaneously, pasting the encoded image is instantaneous (less than a second)
4) jsfiddle C opens with 1 second delay, pasting of the encoded image takes ~15 seconds

So jsfiddle B solves the issue.

#1 & #3 gets page unresponsive prompt
#2 loads and works ok

got a 150kb image base64 encoded from https://www.base64-image.de/
console tab: pasted fine
sources tab: pasted fine
elements tab: hang

here are my hardware specs btw

Intel(R) Core(TM) i7-8650 CPU @ 1.90GHz 2.11GHz
16.0 GB Ram
64-bit OS Windows 10

I need some more help.  I thought adding no-wrap to the prompt would be viable, but it would regress [1].

Sources/Console's text editors are different in that they do not change width on each keypress, and Elements' prompt needs to support flowing onto a newline when its contents are too large.  I'm not sure how layout works exactly, but I'm guessing that the reason it's slow is that Blink is doing a >O(1) check to see if the prompt should flow onto a new line, and performing this check O(n) times, due to word-break.

I have a couple more ideas to verify.  Could we get confirmations whether these jsfiddles repro?
A) [just max-width] http://jsfiddle.net/0omd6s3n/4/
B) [max-width, word-break:break-all] http://jsfiddle.net/0omd6s3n/5/


If these CSS fixes don't work, truncating glyphs sounds like a better option.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=778465

re 28,

A) fail: ~1 minute to paste a real base64-encoded data image URL
   however the initial string is shown instantaneously

B) partial success: ~1 second or less to paste the real data URL 
   however it takes 2 seconds to show the initial string

re #28

both results page unresponsive prompt for me 

Thanks for the feedback.
Based on comments #29, #30, could you please take a look into truncating glyphs, kojii@?

luoe@, thank you for making a minimized case and investigations. I can reproduce minutes with your case A.

One question. The sample renders without wrapping. Is this the intended rendering? From  issue 778465 , it looks like we want to wrap long strings.

When I changed "word-wrap: break-word" to "word-break: break-word", it seems to allow wrapping in the example and also renders much faster. The two properties are similar, only differ by the former extends the container when there's a long unbreakable word and forces breaking only when it can't extend the container, while the latter forces to break without trying to extend the container.

I'm interested in investigating why only the former is slow, but the latter seems to fit better for the DT purpose?

c#32, yes, we would like to wrap text, based on that crbug.

> When I changed "word-wrap: break-word" to "word-break: break-word", it seems to allow wrapping in the example and also renders much faster.
This sounds like the jsfiddle in comment #28, case B), which seems to still have the issue, according to comment #30.

Did we figure out what needs to be done here?

I had a reproducing environment, but it looks like I lost it now. Not sure if recent other work has fixed this problem or something in my environment changed and I just lost reproducing environment.

Could anyone check if one of the URLs can reproduce the hang?
http://jsfiddle.net/0omd6s3n/1/
http://jsfiddle.net/0omd6s3n/2/
http://jsfiddle.net/0omd6s3n/3/
http://jsfiddle.net/0omd6s3n/4/
http://jsfiddle.net/0omd6s3n/5/

re 35:
  1, 3, 4 - hanging
  2 - half a second
  5 - one second

I've pasted a CSS data URL for a real 210k image on a 4GHz i7 PC

(tested in Chrome 71 stable 32-bit and Chrome 73 canary 64-bit, Win7x64)

Thank you for the prompt feedback.

I get ~10 secs to paste 465kb image converted to 620kb CSS at https://www.base64-image.de on Win10 x64, Canary and locally built 64-bit. It looks like my environment changed something. I'll try to investigate more, but if you see any possible cause to reproduce, it's appreciated.

Succeeded to reproduce with http://jsfiddle.net/0omd6s3n/1/ , though I don't think I have changed anything. Something makes the difference, haven't figured out what it is yet.

I disabled the change in r563323 locally but it didn't improve. I was thinking, as the last resort option if all efforts fail, about to discard glyphs when too long as we did before r563323. It looks like reverting to before r563323 doesn't seem to help this case.

I've got the profiling result of Blink when it reproduces:

HarfBuzzShaper::Shape          96.31%
  RunSegmenter::Consume          20.30%
  HarfBuzzShaper::ShapeSegment   74.86%
    hb_shape                       57.47%
    ExtractShapeResults            12.01%
    CaseMappingHarfBuzzFilter      5.36%

Adding our font experts in cc.

Ahem, turns out the length of the text isn't the only/primary factor. I can repro the bug by **pasting in devtools style editor** using the attached text which is only 288k long, but not with another one that's 600k long.

BTW, apparently all slow jsfiddles are also slow before r563323 so they don't approximate the reported STR.

Deleted: buggy.txt 281 KB

buggy.txt 281 KB View Download

#40/#41: both information are very helpful, thank you, some of functions you listed are being worked on to improve, but this seems to contain multiple problems as you pointed out. I'll post updates if any too.

Shaping that text with HarfBuzz takes ~50ms.  So, there's some O(N^2) behavior happening somewhere higher up.

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

commit 8bdb03f38dc9a05959906ccbfed9e748e2609410
Author: Koji Ishii <kojii@chromium.org>
Date: Tue Jan 08 04:34:35 2019

Change ShapeResult::LimitNumGlyphs to use binary-search

CL:1370147 discusses the possibility of the pre-shape limit.
Pre-shape limit is faster because it has character array and
that the limit is index-based operations.

Dominik pointed out that the post-shape limit is still needed
even if we have the pre-shape limit because HarfBuzz cluster
is different from the Unicode grapheme cluster, and also the
pre-shape limit may be incorrect for the same reason.

This patch changes ShapeResult::LimitNumGlyphs to use binary
search algorithm to speed it up when the pre-shape limit was
different from HarfBuzz cluster, or when we may not have the
pre-shape limit.

This change improves long-line-nowrap by 17%.
https://pinpoint-dot-chromeperf.appspot.com/job/1492a623140000

This patch has no behavior changes. Tests for this change is
covered by:
  HarfBuzzShaperTest/ShapeParameterTest.MaxGlyphs
      {Simple,ClusterLatin,ClusterLatin2,ClusterDevanagari}
      /{0,1} (0 and 1 are for LTR and RTL)

Bug: 636993, 893967
Change-Id: Ifdf2d094e72cdfc6259d72d4e27511679b095ab2
Reviewed-on: https://chromium-review.googlesource.com/c/1388356
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620620}
[modify] https://crrev.com/8bdb03f38dc9a05959906ccbfed9e748e2609410/third_party/blink/renderer/platform/fonts/shaping/shape_result.cc

The patch in #44 should improve, but how much is unknown until we test. Unfortunately, I can reproduce in my Canary, but not in any local builds, so hard to know what's really happening.

I have another patch at https://chromium-review.googlesource.com/c/chromium/src/+/1370147 , but there's opinions against it. How much we'd like to pursue that depends on how much it can improve after #44.

#43:
> there's some O(N^2) behavior happening somewhere higher up.

Legacy has O(n!) for the number of lines due to its design, so it's quite possible. NG should improve, but NG in editing is still a bit far. The biggest question is that it happens only in some environments, and not reproducible with debuggable builds. Still trying to understand why, but not making great progress yet.