Keeping it low priority as we dont have complete data to RC issue.

+pbommana@

More reports about this issue
https://listnr.corp.google.com/report/72439270797 [Youtube Screenshot.png]
https://listnr.corp.google.com/report/72438826226 [0.jpg]

Deleted: 0.jpg 322 KB

	0.jpg 322 KB View Download

Deleted: Youtube Screenshot.png 433 KB

	Youtube Screenshot.png 433 KB View Download

CC'ing several others in case this is a real regression in M61.

QA folks, could you please try to reproduce this in house and provide links to affected videos as well as about:gpu from affected machines?

So far I wasn't able to reproduce the issue on Windows 7 and 10, Based on offline chat with Dale, jainabhishek@ can we please reach out to users and ask for below information :

1. Ask user's to play the video and visit "chrome://media-internals" to save the log and share it with us.
2. As Ken updated we we need "about://gpu" details.  

Tested in chrome Beta #61.0.3163.79 and Canary #63.0.3206.0 on win 10.0 & 7 and not able to reproduce the issue.Please find the screen cast and GPU details for your reference.

@jainabhishek: Could you please let me know if i have missed anything and if possible,Please create new profile without extensions and apps.Re-check once and let us know the observations of the issue which would help us to triage the issue further.

Thanks in Advance.

Deleted: GPU Details.txt 8.7 KB

GPU Details.txt 8.7 KB View Download

Deleted: 762132.mp4 4.2 MB

	762132.mp4 4.2 MB View Download

Related comment on Chrome Release blog post - https://chromereleases.googleblog.com/2017/09/stable-channel-update-for-desktop.html#gpluscomments

*after the last chrome update, youtube became very laggy, have to use explorer for youtube now.

We have similar playback issues on Android (762652) and iOS (759827) as well.
Team later filed an internal bug b/65167859 which was fixed by Youtube team today.

More comments on release blog post:
* Facebook and youtube and most sites became very laggy and the cpu became very busy !!
* After update to the last version of chrome (61) Youtube respone very slow and freezes, that problem happen on the Hebrew language layout, when i change to English the problem gone. Please fix it.

Most recent comment on release blog post:
* after the last update youtube and facebook became very laggy.
i change the ui language in this sites from hebrew to english and it solve the problem !
i try to change it to arabic and the problem came again.
so , i believe that the new Version 61.0.3163.79 have a big bug with languages wrriten right to left like arabic and hebrew !!
google !!
pay attention !!

We also have ~5 or so feedback reports and community posts about Chrome being laggy when the language is set to Hebrew, but that sites (like Facebook and Youtube) work when the UI is set back to EN.

+fonts/i18n folk.

+ jshin

Re #12:  melodychu@, are the feedback reports more recently? 

Per comment #9, there was internal bug reported and fixed on September 6th - https://b.corp.google.com/issues/65167859#comment5. 

Also no related recent comments on chrome release blog post (last comment was on September 7th).

I can't think of any Chrome-side RTL/BiDi change that could results in this slowness at Youtube.  

Has anybody (QA team) been able to reproduce this issue locally with the UI language set to Hebrew or Arabic?  

How about other non-English UI language? 

On Windows, it's easy to do that with a command line flag ( --lang=he, --lang=ar )

Test team did tried to reproduce the issue on a VM with Windows Hebrew and wasn't able to reproduce the issue.

I will give a try with the CMd flags as you mentioned in comment#16.

On Linux (I know this bug is about Windows), I can't reproduce this issue in any of 3 RTL locales (he, ar, and fa). 

> i change the ui language in this sites from hebrew to english and it solve the problem !

> that problem happen on the Hebrew language layout, when i change to English the problem gone. Please fix it

When visiting Youtube to reproduce, make sure that Youtube UI language is in Hebrew.  Anyway, I can't reproduce the problem on Linux with that. 

I have this bug too
I use chrome 61 in openSUSE in hebrew lang
I try to disable all the extensions but only changing the site to english help
I can't change the browser language, there isn't "display chrome in this language" in the menu

I open chrome with:
LANGUAGE=en LANG=en google-chrome --lang=en-US,en
on linux
the bug still exist if the site is RTL

I found something that may be helpful:
In the console I saw there is a lot of item "hidden by the filter"
I click on 'All levels' and check 'Verbose'
this message added repeatedly:
"[Violation] Forced reflow while executing JavaScript took **ms"
every time the page stuck this message appears repeatedly, when the page response it stop.

it occur on facebook and youtube in hebrew
it not occur in youtube in english.

I think it may be because this commit: https://chromium-review.googlesource.com/c/chromium/src/+/567200

I check in chrome beta - 62
the bug doesn't occur there.
In the console I still see the message from Comment 22 here and there, in a much lower frequency.

Thanks, ttv200@.

Adding estade@ : just in case he has some hunch. 

pfeldman@ was added because he appears to have written a function that emits

[Violation] Forced reflow while executing JavaScript took **ms

He may have some hunch on the cause of long layout. 

 Issue 764638  has been merged into this issue.

I got the same extremely-slow response experience, rending chrome practically unusable (writing this using FireFox...).

My Chrome version is 61.0.3163.79 (Official Build) (64-bit).
OS is Ubuntu 16.04.3 LTS (4.4.0-93-generic x86_64).
Home language is Hebrew, but both my OS and browser ae set to Englisg (US).

It'd be very helpful if you could upload the output of 'chrome://gpu' here.  Thank you. 


1. Go to chrome://gpu 
2. Save to a file (it does not matter whether you choose 'web page complete' or not)
3. Attach 'gpu.htm' or gpu.html' (saved in step 2). 

I also have the issue with lags on many sites (especially Facebook and youtube and more). the issue wasn't on version 60 of chrome, only when the 61 version came, the chrome become very laggy with poor performance, and no matter what i did, it didn't fix.

Since the last two  updates of chrome ,  youtube and facebook ,  became very laggy and broken.
I have to change the ui language in these sites from HEBREW to ENGLISH to fix the problem.
It's almost  impossible to surf when it set to hebrew !!
Also in arabic !!
Internet explorer , Opera and Firefoks work just fine.
Many peoples from ISRAEL using chrome , suffer this problem since the last two updates.
Thankyou.

here mine
facebook and youtube in Hebrew work very slow

Deleted: gpu.htm 59.2 KB

gpu.htm 59.2 KB View Download

re: comment 35
> Internet explorer , Opera and Firefoks work just fine.

I wonder if there's a version of Opera with the same (or close-enough) version of Blink as included in Chrome 61.  Trying that to see if it has the same issue may help narrow down the list of potential causes (e.g. whether it's Blink or something else like scrollbar behavior change).

We'have multiple external reports on "Youtube and Facebook are very slow when the site UI language is Hebrew or RTL languages". 

+ benhenry@ and sullivan@ for perf/speed metrics
+ asvitkine@ and rkaplow@ for UMA
+ jainabhishek@ for spike in user reports and feedback

Could you please provide above data to determine how wide spread and critical this issue is as currently M61 Stable AU is halt at 15% for Windows and Mac?

ttv200@ or any others here suffering from this issue:

Can you run bisect using http://dev.chromium.org/developers/bisect-builds-py ?  

It'd be great if one of you could run the bisect tool to narrow down the range of culprit changes to a few (if not just one) .  

Thanks a lot in advance. On Linux, it should be fairly simple to run the tool because Python is already available. 

Adding Victor and John in case there's something obvious we're missing. Will start to dig into UMA.

If anyone can reproduce this, please attach a trace. If I missed that, which comment? Looking at DrawInterval2 for countries which use RTL as their primary language (no way to filter RTL in UMA?) and it's not showing anything interesting. I'm hoping Victor can point out better metrics to look at.

I assume you meant to re-add kbr@.

> no way to filter RTL in UMA?

I wonder if UI language is  recorded in UMA. If so, filtering with lang={hr,ar,fa} would work. Is it not recorded? 

We do record application locale in UMA. I don't think we have any RTL specific split, but as #46 mentions we could just use some of the locales.

What would be the best UMA metric to look at? benhenry mentions DrawInterval2, would that be Scheduling.Renderer.DrawInterval2?

https://uma.googleplex.com/timeline_v2?sid=2585a06f1856d9f0f6b40c50e8affb9d

I don't see a measurable difference in this metric between 60 and 61

It should be one of 'he' (not 'hr'), 'ar' or 'fa'. I used Arabic (ar) and found a small  difference (16880=60 and 16810=61:  Is the smaller the worse ? ) 

https://uma.googleplex.com/timeline_v2?sid=c0ebb1d8eeb2ba16be5222043c7db5f2

I'm a bit confused by comments 17-19 which seem to say it's difficult to reproduce going to RTL. 

I've noticed most people have said the problem is fixed by setting youtube or facebook itself to english - and not the browser (which the UMA metrics would reflect).

COuld we try to reproduce by setting the website languages?

As well, did anyone investigate the CL mentioned in #22 (estade) 

Hebrew (he): https://uma.googleplex.com/timeline_v2?sid=b0cb2977b7505f3b709267218a2d7c00

Farsi/Persian (fa): https://uma.googleplex.com/timeline_v2?sid=07e8c509811307d432ebca2213523e96

have the same pattern as Arabic. 

> I've noticed most people have said the problem is fixed by setting youtube or facebook itself to english - and not the browser (which the UMA metrics would reflect).

The UI language of Chrome is used as a proxy for the web site UI language (FB and YT) because we don't have any better way to see what the web site UI langauge is actually used. 

When the UI language of Chrome is RTL, the chance is high that the web site UI languge served to those users is also RTL. (there's no guarantee because a user can change the web site UI language). 

en-US: https://uma.googleplex.com/timeline_v2?sid=fdda94f32753d0f88589b4245939ff7e   
The difference is smaller than RTL locales. ( ~ 6 vs ~ 50). Not sure if it's significant (without any error bar in the plot). 

THe metric is measuring draw latency, so looks like it has gone down in M61, so the drops are probably unrelated to the issue people are reporting here (I would expect to see an increase).

However the graph was originally 50th percentile which I would expect to be unchanged, but if we look at 99th percentile, it still is not showing an increase. Not sure this metric is useful.

Looking at CL list for M61:

https://chromium.googlesource.com/chromium/src/+log/60.0.3112.0..61.0.3163.0?pretty=fuller&n=1000000

The ones that look suspicious (RTL related and web content area) are:
crrev.com/74bd1c084916b057eb7936bf9871721eb0e61fa3
crrev.com/3364acfe2f8c9d3afa5bb0195cd8ef717bfbbcee
crrev.com/d1c316847a808e70590eb0af0486efbd9a92152e

At least, when searching for string " RTL" and ignoring stuff thats in browser UI (rather than web content).

I'm pretty sure the second one ( https://chromium.googlesource.com/chromium/src/+/3364acfe ) is not to blame (it's a bit unfortunate that the source file is named rtl.cc . :-) ). 

--------

It'd be great if anyone who can reproduce this issue on Linux can try this and report back
the narrowed-down range:

python tools/bisect-builds.py -a linux64 -g 481510  -b 499126 --use-local-cache -- \
    --no-first-run --user-data-dir=/tmp  https://www.youtube.com 

(see http://dev.chromium.org/developers/bisect-builds-py  for the instruction on Windows). 

Thank you tons in advance !

I am able to reproduce the Youtube UI slowness on 61.0.3163.91(Windows-10) and working on per-revision bisect. Will update the same here with detailed test steps and per-revision bisect soon.

Amit ran bisect and got this CL to blame:

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

+rune@opera.com 

Amit, is your bisect for 'Youtube video not playing' or 'Youtube or Facebook very slow in RTL language UI (see comment 10 and  bug 764638 )  or both ?  

On Windows, passing '--lang=he' to Chrome (with a clean profile) and going to youtube.com will get you Youtube in Hebrew. 

Able to reproduce the issue on the latest stable(61.0.3163.91) on Windows-10, Mac OS 10.12.6 and Linux Ubuntu 14.04. This seems to be fixed on the latest Beta(62.0.3202.18) and the latest canary(63.0.3220.0).

Forward bisect that broke this
===============================
Last good build: 61.0.3143.0
First bad build: 61.0.3144.0

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

Broken by https://chromium-review.googlesource.com/c/chromium/src/+/548379.


Reverse bisect to identify the CL that fixed this.
==================================================
Last bad build: 62.0.3180.0
First good build: 62.0.3181.0

Changelog:
https://chromium.googlesource.com/chromium/src/+log/62.0.3180.0..62.0.3181.0?pretty=fuller&n=10000

Probably fixed by https://chromium-review.googlesource.com/c/chromium/src/+/606007.

Note:
=====
> I was unable to reproduce the Youtube video not playing but able to reproduce the Youtube UI slowness in hebrew language on stable version: 61.0.3163.91 across all OS.
> Facing some issues with the bisect script while running the reverse bisect, will update the per revision reverse bisect result once its resolved. However manually checking the changelog, https://chromium-review.googlesource.com/c/chromium/src/+/606007 looks more plausible that would have fixed this. 

Below is the tool reverse bisect result which point to the CL that fixed this issue:

https://chromium.googlesource.com/chromium/src/+log/6a43eb8a10f17beaf919046c6a2cb4a128c74f41..c3d15c145666e6b393ffdbdbdb9727285e6aecae

Test steps followed to repro this issue on 61.0.3163.91:

1. Changed Youtube language to Hebrew.
2. Played any video and scrolled to the bottom using arrow down key using the keyboard.(Scroll is really sluggish)
3. Scrolled up using arrow up key and mouse hovered on the volume icon or clicked settings icon. (UI opens really slow on mouse hover or click)

Screen-cast is attached of the same behavior. 

Deleted: 762132_Actual.mp4 8.3 MB

	762132_Actual.mp4 8.3 MB View Download

you don't need to use a clean profile and change the browser UI
you can just use this extention: https://goo.gl/jQpnPh

Requested merge of fix to M-61 in blocker issue.

+ candrada@ to try to repro on Android M61 "Youtube and Facebook are very slow when the site UI language is Hebrew or RTL languages"

Changing summary to keep this issue RTL specific as much of discussion in this bug is "Youtube and Facebook are very slow when the site UI language is Hebrew or RTL languages"

jainabhishek@, pls report a separate bug for "Videos dont play on Youtube".

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

commit 3f83de090df47bf2bb3dc8f86eca45f4e5f4a3f6
Author: Rune Lillesveen <rune@opera.com>
Date: Wed Sep 20 20:10:41 2017

[M61 Merge] No need for recalc on viewport propagation.

Before the fix for  issue 732349 , we relied on propagation from body to
viewport to affect the computed style of the root element which was
handled through a subtree recalc after viewport propagation. This is no
longer necessary. In fact, when rtl was specified on body, but the
computed style of html was ltr, InheritHtmlAndBodyElementStyles would
always trigger a subtree recalc, which would happen every frame we had a
style recalc.

There's a hope this will fix performance  issue 739133 .

I think that InheritHtmlAndBodyElementStyles can be made into a
PropagateStyleToViewport method which can be called at the end of
style recalc to avoid calculating html and body style twice. I'll try
to do that in a separate CL.

Bug:  739133 ,  762132 
Change-Id: I0beebcf850661434eedb8bd19405698c27b7ae89
Reviewed-on: https://chromium-review.googlesource.com/606007
Commit-Queue: Rune Lillesveen <rune@opera.com>
Reviewed-by: Morten Stenshorne <mstensho@opera.com>
Cr-Commit-Position: refs/heads/master@{#492889}(cherry picked from commit c3d15c145666e6b393ffdbdbdb9727285e6aecae)

TBR=rune@opera.com

Change-Id: I0beebcf850661434eedb8bd19405698c27b7ae89
Reviewed-on: https://chromium-review.googlesource.com/675594
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#1248}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/3f83de090df47bf2bb3dc8f86eca45f4e5f4a3f6/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/3f83de090df47bf2bb3dc8f86eca45f4e5f4a3f6/third_party/WebKit/Source/core/dom/DocumentTest.cpp

Rechecked this on on chrome version 61.0.3163.100 on Windows 10, Windows 10 Touch, Mac 10.12.6, Ubuntu 14.04. as per the steps provided in comment#61 and fix is working as intended. No slowness observed on any pages. Verified on both Facebook and Youtube pages.

Adding TE-Verified labels for M61

This patch is now pushing out to stable channel in version 61.0.3163.100 for Desktop (Win,Mac & Linux).