Correction:
Step 2- Select flight details and click on 'continue' button from R.H.S till it reaches checkout section,enter email id and click on 'create an account' button. 


This is a regression issue broken in 'M51' and below is manual regression range:
Good Build: 51.0.2702.0
Bad Build:  51.0.2703.0

Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/3960b8b282030a4f91059cf25d6b01c8beab57b8..05fcaf5a1fb2771ae1dca9f1bbdd6d08b74dace4?pretty=fuller&n=30

Suspecting: 385694 ?
@keishi: Kindly help to re-assign, if your changes are not cause for this issue.

Deleted: ActualResult.mp4 543 KB

ActualResult.mp4 543 KB Download

Deleted: ExpectedResult.mp4 534 KB

ExpectedResult.mp4 534 KB Download

My CL is a simple refactor of testing code.

r385693 in the bisect range mentions performance. +kojii could your CL be related?

Yes, this is mine, thank you. Probably the same issue as comment #87 in  issue 593679 .

r385693 gives the more correct and faster measuring, in the cost of one case being slower than before: a very long "word" (without break opportunities) with "word-wrap: break-word".

This page has 9233 bytes of a hex string ([0-9A-F]) in <input type="hidden" value="..."> and dev tools uses "word-wrap: break-word".

Before, we measure character by character when "word-wrap: break-word" and stopped measuring when it reached available width. With r385693, we measure words by words and find the mid-word break point in the word that overflows.

So when we have 9233 bytes of a hex string to wrap 100 chars/line, we measure:
1. Measure the word of 9233 chars, then find its first 100 chars can fit.
2. For the next line, measure the word of 9133 chars, then find its first 100 chars can fit.
3. For the next line, measure the word of 9033 chars, ...

None of these measures are likely to hit the cache, and measuring such a long string is expensive. comment #87 in  issue 593679  says 250kb of a hex string can hang.

Hard to revert r385693 because it fixes layout taking minutes when break-all.

Thinking options:
A. eae@/behdad@ suggested to add hard-max limit to shape at 32kb, but this case is only 9kb. Set lower hard-max such as 1kb?
B. Change r385693 fix back to char-by-char only for break-word. The fix does a) fix perf issue for break-all and b) more correct measuring for ligatures/joining for break-all/break-word. By giving up the "correct measuring" part, we could fix break-all perf without making break-word slower.
C. Bring the once discarded idea; add more cache segment delimiters (i.e., [0-9A-F]), maybe only if a word is too long and characters that don't participate in GDEF/GPOS.
D. Line breaker can use some heuristics to avoid useless measure. For instance, if available width is 800px and break-word, it's probably useless to measure more than 800 chars because we'll find mid-word break from the ShapeResult and discard the rest anyway.

eae@, drott@, behdad@, WDYT?

I'm fine with 1k limit.  Even lower.

Adding RB-label, please change if required 

Tested option A (hard limit) with the attached test (a word of 9233 bytes):

Stable: 15ms
Canary: 850ms => 56 times slower

With 1024 limit: 3 times faster (19 times slower than Stable)
With 512 limit: 4 times faster (14 times slower than Stable)
With 128 limit: 5.5 times faster (10 times slower than Stable)
With 64 limit: 6 times faster (9 times slower than Stable)

Haven't measured if this is linear to the length or power.

Does this look good enough until we get the new line breaker, or more interim solutions needed?

I'll send the hard limit CL anyway, but inputs are appreciated.

Deleted: break-word-long-603398.html 7.3 KB

break-word-long-603398.html 7.3 KB View Download

One finding: caching works only for strings shorter than 15 chars. So when we width() then offsetForPosition() then selectionRect() for the same string, we shape it 3 times.

Another option:
E. if > 15 chars && break-word && !ligature && !kerning, segment each char.

Correction:
E. if > 15 chars && 8bit && !ligature && !kerning, segment each char.
break-word is not really a necessary condition, we can do it always?

Local content_shell buildtype=Official seeing different characteristics than #7 (debug):
Current: 1650
Limit=1024: 1600
Limit=128: 1650
Limit=16: 3050
Limit=15: 95
char-by-char if >15: 350

nextWordIndex() is expensive for char-by-char, we could try to optimize it, but probably not this time.

 Issue 601476  is also about words longer than 15.

2 CLs are under experiments:
https://codereview.chromium.org/1894863002
https://codereview.chromium.org/1900513002

The former can address other cases as well but doesn't look good at this point. The latter addresses only for break-word.

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

commit 41fe145a8629f1f7002b41a8e12687b97d5e635f
Author: kojii <kojii@chromium.org>
Date: Mon Apr 18 19:01:07 2016

Prevent to measure the whole word when break-word

crrev.com/385693 changed the line breaker to measure word-by-word then
rewind if break-word/break-all. This causes a performance regression
when a word is extraordinary long, such as minified JS/CSS or
hex/base64 data.

This patch fixes to measure character-by-character, but unlike before
r385693, it lets overflow by 2em then rewind to the correct position.

This prevents the line breaker to measure the whole word, while
still measuring ligatures/kernings correctly as long as the sum of
such effects is within 2em.

BUG= 603398 

Review URL: https://codereview.chromium.org/1900513002

Cr-Commit-Position: refs/heads/master@{#387974}

[modify] https://crrev.com/41fe145a8629f1f7002b41a8e12687b97d5e635f/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/41fe145a8629f1f7002b41a8e12687b97d5e635f/third_party/WebKit/LayoutTests/platform/win/fast/text/midword-break-after-breakable-char-expected.png
[modify] https://crrev.com/41fe145a8629f1f7002b41a8e12687b97d5e635f/third_party/WebKit/LayoutTests/platform/win/fast/text/midword-break-after-breakable-char-expected.txt
[modify] https://crrev.com/41fe145a8629f1f7002b41a8e12687b97d5e635f/third_party/WebKit/Source/core/layout/line/BreakingContextInlineHeaders.h

Could this be merged into M-50? It looks like this patch helped to mitigate a very nasty  crbug.com/593679 .

[Automated comment] Request affecting a post-stable build (M50), manual review required.

Merge approved for M50 (2661)

This is a regression for  issue 591793  (M51), so we only need for M51.

Not in Canary yet, should I merge-reuqest-51 after a few days?

Yes, once baked and verified in canary, you can merge-reuqest-51
(Removed M50 related labels per Comment #17)

We're cutting M51 Beta candidate tomorrow @ 5:00 PM PST. Please request a merge to M51 branch 2704 once it is baked in canary.

Today's Canary on the same PC as comment #7:

> Stable: 15ms
> Canary: 850ms => 56 times slower

is now 24ms. 35 times faster than before the fix, still slower than Stable but I think it's a necessary cost to do the right thing such as  issue 380667 .

I call this fixed, cancel the other candidate in #12, and merge-request-51.

Your change meets the bar and is auto-approved for M51 (branch: 2704)

Tested this issue on Windows 7 using chrome latest canary M52-52.0.2713.0 and
observed the Devtools window is responsive and able to click on customize and devtools option as expected. Hence adding TE-verified label.



 

Deleted: Devtools.png 419 KB

	Devtools.png 419 KB View Download

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

commit 7183255cb9dd01ff20a267c2b682d92feb6ad2a1
Author: Koji Ishii <kojii@chromium.org>
Date: Wed Apr 20 15:11:43 2016

Prevent to measure the whole word when break-word

crrev.com/385693 changed the line breaker to measure word-by-word then
rewind if break-word/break-all. This causes a performance regression
when a word is extraordinary long, such as minified JS/CSS or
hex/base64 data.

This patch fixes to measure character-by-character, but unlike before
r385693, it lets overflow by 2em then rewind to the correct position.

This prevents the line breaker to measure the whole word, while
still measuring ligatures/kernings correctly as long as the sum of
such effects is within 2em.

BUG= 603398 

Review URL: https://codereview.chromium.org/1900513002

Cr-Commit-Position: refs/heads/master@{#387974}
(cherry picked from commit 41fe145a8629f1f7002b41a8e12687b97d5e635f)

Review URL: https://codereview.chromium.org/1907503002 .

Cr-Commit-Position: refs/branch-heads/2704@{#145}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/7183255cb9dd01ff20a267c2b682d92feb6ad2a1/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/7183255cb9dd01ff20a267c2b682d92feb6ad2a1/third_party/WebKit/LayoutTests/platform/win/fast/text/midword-break-after-breakable-char-expected.png
[modify] https://crrev.com/7183255cb9dd01ff20a267c2b682d92feb6ad2a1/third_party/WebKit/LayoutTests/platform/win/fast/text/midword-break-after-breakable-char-expected.txt
[modify] https://crrev.com/7183255cb9dd01ff20a267c2b682d92feb6ad2a1/third_party/WebKit/Source/core/layout/line/BreakingContextInlineHeaders.h

 Issue 621165  has been merged into this issue.

 Issue 628952  has been merged into this issue.