So far I'm unable to repro on Linux, Chrome Stable version #57.0.2987.133.

Hello, I can confirm the OP's issue as well. Everything but main feed loads normally. I did notice that most of the page's elements load, except the ad space circled here. As the other user noted, I am unable to interact with the tab at all after loading facebook.com. Chrome itself does not crash, just the specific tab. Thanks!

Deleted: fb.JPG 59.3 KB

	fb.JPG 59.3 KB View Download

Same issue for me too, but only on this particular machine (Windows 10.0.14393.953, Chrome Version 57.0.2987.133 (64-bit)). 

www.facebook.com loads the first page of content just fine, then freezes. This issue does not occur when accessing other pages on the domain, like www.facebook.com/events/birthdays.

In my  issue 708768 , Facebook on Chrome 57 works fine, but Chrome Canary 59 not. https://youtu.be/gU-vg4CzdH8

Able to reproduce this issue on Dell precision M3800 HiDPI using chrome latest stable #57.0.2987.133. After logging in to Facebook account the page loads for few seconds and it goes completely unresponsive. 

Tested the same on older version of chrome #56.0.2888.0 and observed similar behavior. This issue is not reproducible on Mac OS 10.12.4 and Ubuntu 14.04 as well. I am able to reproduce this issue only on Windows NT 10.0.14393 operating system. Attaching chrome://gpu details for further investigation. 

Crash ID's:
ea794b59e0000000
f6de40d210000000
484910d210000000

Deleted: GPU Details.txt 11.1 KB

GPU Details.txt 11.1 KB View Download

Issue 708461 has been merged into this issue.

Bisect Information:
=====================
Good build: 54.0.2794.0
Bad Build : 54.0.2795.0

You are probably looking for a change made after 404867 (known good), but no later than 404885 (first known bad).

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/af2f49ba57ed217d06e69830f325c9ba7e7ce0bd..57b70dae30c2bc7d60e70efd8ebae83e01fe9119

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2138363002

jochen@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Note: Unable to reproduce this issue on chrome latest Beta #58.0.3029.54 and latest canary #59.0.3063.4.

Issue 708937 has been merged into this issue.

Issue 708833 has been merged into this issue.

if facebook would hit this codepath, they'd previously just crash. Also, it would crash on ToT as well.

If you can repro, could you do a revision precise bisect please?

btw, the crash IDs posted are all pointing at different issues :/

I have tested this issue on multiple machines but no luck to reproduce it other than my Windows-10 . Since per revision bisect builds are crashing on windows-10 I am unable to provide the single CL. 

Hi Same issue experiencing here. Chrome 57.0.2987.133 and windows 10 pro, version 1607, build 14393.953. any information i can provide to help?

I am on Windows 10, with an Acer using Chrome 57.0.2987.133.  I had NO problems with Facebook, until this update.  I am now accessing Facebook on Firefox or Edge with no problems.

I did a quick comparison regarding the crashers between latest 56 and latest 57. I don't think it is crashing more often and suspect that this MIGHT be a red herring: https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27%27%20AND%20custom_data.ChromeCrashProto.url.simplified%3D%27https%3A%2F%2Fwww.facebook.com%2F*%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&compProp=product.Version&v1=57.0.2987.133&v2=56.0.2924.87

Crashers for 57: https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27%27%20AND%20custom_data.ChromeCrashProto.url.simplified%3D%27https%3A%2F%2Fwww.facebook.com%2F*%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27%27%20AND%20product.Version%3D%2757.0.2987.133%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#-samplereports:5,day:1000

Crashers for 56: https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27%27%20AND%20custom_data.ChromeCrashProto.url.simplified%3D%27https%3A%2F%2Fwww.facebook.com%2F*%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27%27%20AND%20product.Version%3D%2756.0.2924.87%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#-samplereports:5,day:1000

Display the "Day" field and you see that there is no crash spike with 57.

I though think that the real problem is this endless loading. That sounds awfully similar to crbug/701601 

justification for my suspicion:

1.) random malfunction of the page (endless loading)
2.) not 100 % reproducible
3.) Happens on JS/DOM heavy pages

Another reason might be that Facebook currently runs a broken A/B experiment.

@ hablich - 

I disagree about your points 1 and 2. It's NOT random and IS 100% reproducible for me (happens every time), and I suspect for many other persons reporting the issue as well. 

I have same issue on Windows 10 with Chrome 57.0.2987.133. It is 100% reproducible and it also occur on secret window, but it does not occur on guest mode.

Re #29: with 100 % reproducible I meant not for everybody. Sorry for being not clear.

Is it possible that you try it out with the latest Chrome Beta? That already includes the fix for crbug/701601 . If the error is not reproducible on Beta, that might be a clue.

interesting update. the bug if the browser is zoomed at 110% or 90% does not appear. my resolution is 3840*2160 and the fonts are set at 250%

Please try to repro this bug on Chrome Beta #58.0.3029.54 and update the result here. Thank you.

Re #32 there was also this change from the bisect above: https://codereview.chromium.org/2044963004

+bsep, +oshima

I have tried all of the "tips" suggested. Facebook loads, then freezes. Works fine on Firefox. Just fix it, please. 

Hi All 

If possible can one of you try the same using Chrome Beta(https://www.google.com/chrome/browser/beta.html) and let us know if you are able to reproduce the issue. 

Note : If you have any book marks and other useful data please make sure you don't check the option "Also delete your browsing data?" which would retain your Userdata folder and upon installing Beta you still have all your data and once checked you can switch back to Chrome stable(https://www.google.com/chrome/browser/desktop/index.html).

Thank you all in advance. 

Pending feedback from people who can reliably reproduce this crash on whether the issue still persists in Chrome Beta.

@brajkumar

Given that this does not reproduce in beta (comment #19), would it be possible to perform a reverse bisect to identify possible fix candidates. That should help progress in determining the underlying issue here.

My 2c from the Style team: I haven't been able to reproduce this on my windows machine with my facebook account and any of these builds. I also tried changing the font size, window size, and zooming as per #32's comment.
56.0.2924.87
57.0.2987.133
59.0.3064.0 

I opened all the crash id's above in crash server. There were 5 different "Renderer Hang" traces, and one didn't have enough of a stack trace to get any useful info.

Expanding the "day" tag, there was definitely a increase in these kind of crashes on 2017/04/03. According to OmahaProxy, the only release that went out on or around that date were canaries (list below), but the vast majority of these crashes (94%, 97%, 98%, 97%, 96%) seen on stable. The most recent stable is 57.0.2987.133, which went out on 2017/03/29.

Looking at random stack traces from each of the 5 crash types, they all have somewhat-to-really deep recursive style recalculation (55, 37, 26, 37), (36, 26,  <120 frames omitted> + 20, <154 frames omitted> + 20), (28, 32, 36, 27), last two had too many low quality stack traces.


I wonder if the fact that some users see this consistently and some don't see it at all really does mean that Facebook is doing some user A/B testing where only some users are seeing some large DOM structures that take a long time to recalculate style, causing the renderer to take so long that the hang detector is killing it.




omahaproxy release list for 2-4 April:
android,canary,59.0.3062.3,2017-04-04 22:32:14.985590
android,canary,59.0.3062.0,2017-04-04 14:09:14.714470
win64,canary,59.0.3062.0,2017-04-04 10:21:01.868740
win,canary,59.0.3062.0,2017-04-04 09:25:01.980840
win64,canary,59.0.3061.3,2017-04-04 09:25:01.487540
win,canary,59.0.3061.3,2017-04-04 08:29:01.378130
win,canary_asan,59.0.3062.1,2017-04-04 07:05:01.528530
win64,canary_asan,59.0.3062.1,2017-04-04 07:05:00.988490
mac,canary,59.0.3062.0,2017-04-04 06:37:00.874670
mac,canary,59.0.3061.3,2017-04-04 05:41:00.891380
android,canary,59.0.3061.0,2017-04-03 14:06:14.337400
win64,canary,59.0.3061.0,2017-04-03 09:48:00.931930
win,canary,59.0.3061.0,2017-04-03 09:06:01.247080
win,canary_asan,59.0.3061.1,2017-04-03 07:14:02.317360
win64,canary_asan,59.0.3061.1,2017-04-03 07:14:01.567810
mac,canary,59.0.3061.0,2017-04-03 06:32:01.429550
win64,canary,59.0.3060.0,2017-04-02 10:13:01.183610
win,canary,59.0.3060.0,2017-04-02 09:02:01.751940
win,canary_asan,59.0.3060.1,2017-04-02 07:10:02.343500
win64,canary_asan,59.0.3060.1,2017-04-02 07:10:01.808700
mac,canary,59.0.3060.0,2017-04-02 06:28:01.391570

I can't reproduce this so unfortunately I can't tell you much.

Looking at the crashes in Comment 15, these are hangs in deeply recursive style recalc. This is probably not Issue 701601. It might be a problem with style resolver. Comment 32 about zoom also points to style/layout.

Here's a query that summarizes renderer hangs on FB across versions. We should keep in mind that this just looks at the rate of renderer hangs, relative to all crashes. It doesn't tell you anything about whether Chrome is getting more or less stable.

https://crash.corp.google.com/dremel_query_ui?q=SELECT%20product.version%2C%20custom_data.ChromeCrashProto.channel%2C%20SUM(hit)%2C%20COUNT(*)%2C%20SUM(hit)%2FCOUNT(*)%0AFROM%20(SELECT%20product.version%2C%20custom_data.ChromeCrashProto.channel%2C%20custom_data.ChromeCrashProto.magic_signature_1.name%20CONTAINS%20%27%5BRenderer%20hang%5D%27%20AS%20hit%0AFROM%20crash.prod.latest%0AWHERE%20product.name%3D%27Chrome%27%20AND%20custom_data.ChromeCrashProto.url.simplified%3D%27https%3A%2F%2Fwww.facebook.com%2F*%27%20AND%20%2750%27%20%3C%20product.version%20AND%20product.version%20%3C%20%276%27%0A)%20GROUP%20BY%201%2C%202%0AHAVING%20COUNT(*)%20%3E%201000%0AORDER%20BY%202%2C%201%20DESC

I did some aggregation by version and day to try and separate out whether this was a change in Chrome version or the environment. At the level of detail I can see from crash/ the rate of renderer hang reports versus crash reports for this site looks pretty normal.

I also produced the same graphs for renderer hangs versus crash rate across all sites and nothing sticks out about 57. 

It's possible something happened about two weeks ago which affected 57.0.2987.133 on this site. That could be the population of users that version reaches, something on the site, etc. I would need access to more data to sort through it.

Re: A/B tests, something like ad targeting could also look like that; it selects a population of users.

A friend of mine could reproduce this. And he sent me two stack dump files.
According to them, the main thread is in a infinite loop while calculating styles.

Version: 57.0.2987.133 windows x64

------------------------------
>	blink::Text::recalcTextStyle	C++
 	blink::ContainerNode::recalcDescendantStyles	C++
 	blink::Element::recalcStyle	C++
 	blink::ContainerNode::recalcDescendantStyles	C++
 	blink::Element::recalcStyle	C++
 	blink::Document::updateStyle	C++
 	blink::Document::updateStyleAndLayoutTree	C++
 	blink::CSSComputedStyleDeclaration::getPropertyCSSValue	C++
 	blink::CSSComputedStyleDeclaration::getPropertyValue	C++
 	blink::CSSComputedStyleDeclaration::getPropertyValue	C++
 	blink::CSSStyleDeclarationV8Internal::getPropertyValueMethod	C++
 	v8::internal::FunctionCallbackArguments::Call	C++
 	v8::internal::`anonymous namespace'::HandleApiCallHelper<0>	C++
 	v8::internal::Builtin_Impl_HandleApiCall	C++
 	v8::internal::Builtin_HandleApiCall	C++
 	0000011bfe58442b	Unknown


------------------------------
>	std::basic_streambuf<char,std::char_traits<char> >::showmanyc	C++
 	blink::Node::parentComputedStyle	C++
 	blink::Text::recalcTextStyle	C++
 	blink::ContainerNode::recalcDescendantStyles	C++
 	blink::Element::recalcStyle	C++
 	blink::ContainerNode::recalcDescendantStyles	C++
 	blink::Element::recalcStyle	C++
 	blink::Document::updateStyle	C++
 	blink::Document::updateStyleAndLayoutTree	C++
 	blink::CSSComputedStyleDeclaration::getPropertyCSSValue	C++
 	blink::CSSComputedStyleDeclaration::getPropertyValue	C++
 	blink::CSSComputedStyleDeclaration::getPropertyValue	C++
 	blink::CSSStyleDeclarationV8Internal::getPropertyValueMethod	C++
 	v8::internal::FunctionCallbackArguments::Call	C++
 	v8::internal::`anonymous namespace'::HandleApiCallHelper<0>	C++
 	v8::internal::Builtin_Impl_HandleApiCall	C++
 	v8::internal::Builtin_HandleApiCall	C++
 	000000be4d30442b	Unknown

Is anyone seeing this in Mac (or linux)? OS label has bot, but all issues reported so far are on windows.

Can someone who's having this issue try followings?

a) use another directory as your data directory:

   chrome --user-data-dir=<temp dir>

   then login

b) create a new facebook account and test using it

c) run chrome with --force-device-scale-factor=1

thanks

I'm not seeing this issue on Elementary OS Loki (Ubuntu 16.04)

And yes, no issue whatsoever when running with `--force-device-scale-factor=1`

On Windows 10

I took a look at the dumps in Comment 41. If there's a loop its something that has optimized recursion to loops because the stack is small.

My friend sends me the result of chrome://tracing.

Deleted: trace1.png 246 KB

	trace1.png 246 KB View Download

Deleted: trace2.png 113 KB

	trace2.png 113 KB View Download

I dug into the trace a bit. It appears to be the script that's looping; specifically a load event which ends up through something wrapped up in something called TimeSliceRefCountingWrapper. That is repeatedly causing layout. I looked at a couple of the frame snapshots and they appear sane--3.8 K rows and the layout is changing slightly.

Of course Issue 701601 could make an app behave like this but it's safer to assume it is not related.

As per comment #38 providing reverse bisect information below.

Bisect Information:
=====================
Good build: 58.0.3012.0 - 450199
Bad Build : 58.0.3010.0 - 449855

You are probably looking for a change made after 449940 (known good), but no later than 449947 (first known bad).

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/7a8b621535abb3aa5d9c0ff2196299f1d90449a5..28ff32abc83ae8939f56702151b3d982859d56b5

Thanks!

CC'ing karlo@ based on regression range and the mentioning of zoom and slightly changing layouts.

I had this issue and tried the suggested solution to install chrome beta. I didn't have the issue after that anymore.

I was able to get to my FB page, but then it froze. Suggested I reset Chrome to original settings, now I just get a black screen....

Facebook.com will not load in Chrome.  The page freezes and never loads. I don't have problems loading other pages, and facebook loads fine in Firefox.  I tweeted @googlechrome and they told me to try to run the page in Incognito mode which I did.  The page still did not load when I did this.  I got the "page unresponsive" popup box. They told me to report the bug here, but it looks like other users are having the same issue. I also posted this in the forum.
https://productforums.google.com/forum/#!msg/chrome/9TJKYD4i-y8/XUQzTcNnAwAJ;context-place=topicsearchin/chrome/facebook$20slow%7Csort:date

I am also having this issue with my MacBookPro - chrome is up to date and I tried all of the clearing and resetting recommended above.

...Can't believe it's been days and Google still hasn't resolved this issue!!  So discouraging.  I am switching to safari :(  

OSX same issue. Cleared cookies/cache, resinstalled chrome issue persists.

If this is happening on mac, this could be more generic issue around css/media query with some fb (experimental) pages when used on high DPI machine (deviePixelRatio > 1).

#54,54,44, can you open https://bjango.com/articles/min-device-pixel-ratio/ and tell us the value you get for -webkit-min-device-pixel-ratio?

#54,54, do you happen to be using page zoom? 

I was having this precise issue on a brand new laptop (Dell XPS 15, running Windows  10). It has a high-res screen, and Windows had display setting to increase UI size by 250%. When I reduced it to 200%, the problem immediately went away and has not returned. If I return to 250%, it freezes again every time I go to the page.

I'd like to add that I am having this issue on an Acer Chromebook R11.  It is one of the ones running Android app and is a touchscreen.  We have a 2nd older Chromebook (also Acer but not touchscreen or Android ready) and it is not showing this issue.  I confirm that it happens on the Home page.  If I start FB by a link to a page that I manage, I do not see the freezing behavior.

Having this issue on Dell XPS 13 9360, both on Chrome and chromium based Vivaldi.

Per comment #59, this issue is also seen on Chrome OS. 

Same issue for a few days now on Dell XPS 15.

Chrome version: 57.0.2987.133 (64-bit)

On loading Facebook, the page will load the screen as you would normally see Facebook but won't complete loading. Blue loading circle turns and turns. Unable to scroll the page at all. It takes around 8-10 minutes before prompt appears stating page is 'unresponsive'.

Guys, I've found out a solution, or at least until Google fix it (or if they do), Facebook works once I enable the Proxy extension I'm using, if you can't find a good one then I recommend "Just Proxy VPN", just remember to enable it once downloaded

I'm able to repro on my personal PC and snagged a few crash IDs
4cbd5c69-594a-426f-b84a-075753eaf09f
c441d5e3-77fc-4373-b728-70c9a4c644c7
3a4e62b3-f592-4988-950f-6bdde7d77653

Problem occurs on Stable, even in Incognito. Doesn't occur in Canary with same fb account

I have the same FB issue on chrome but ONLY on this laptop, not others. No problem on other browsers. FB open for a few seconds like normal, then the screen darkens and the FB icon in the browser goes into a continual search till the Aw snap. Kill shuts down ALL open windows in browser. This only happens on this particular FB account, not others on this laptop. Cleared caches, cookies, browse history, ran, defender, CC cleaner and defrag. Started happening a few days ago

When I open Facebook News feed and scroll down it hangs forever (not really. it crashes after 5 minutes). What I see is that chrome's facebook tab is requesting tons and tons of memory after a while it simply runs out of memory and crashes. If you open the chrome task manager then open facebook you will  see it begin to reserve system memory in large chunks. eventually it will reach about 3.9 gig and then crash with the error "Aw Snap chrome ran out of memory". 
Now using the developer's tool and open Facebook I can see that that it is hung processing an error in a java script. .  
* Note that all the other tabs are working fine  
*Only happens on Facebook.
*Facebook works on other browsers like OP, Edge, IE. perhaps the error is occurring in the Facebook script but the other browsers are better at handling that particular error.
* I have observed that trying the same with Edge it will struggle when scrolling down , the news feed (pauses) but recovers and continues scrolling.  
* I'M USING OPERA UNTIL THIS IS RESOLVED    either by FB or Google.  Below is some snips from the developers tool. 

at main.js:198
ThrowError @ main.js:58
Parse @ main.js:171
exports.parse @ main.js:176
OnFrameContextMenu @ main.js:2802
(anonymous) @ main.js:198
error.facebook.com/common/scribe_endpoint.php?__a=1&__af=iw&__be=-1&__dyn=7…7D%7D&ttstamp=2658171985410197656710111297586581701027310011210883798682:1 GET https://error.facebook.com/common/scribe_endpoint.php?__a=1&__af=iw&__be=-1…2%7D%7D&ttstamp=2658171985410197656710111297586581701027310011210883798682 net::ERR_INSUFFICIENT_RESOURCES
main.js:58 Uncaught SyntaxError: JSON s

at main.js:198
ThrowError @ main.js:58
Parse @ main.js:171
exports.parse @ main.js:176
OnFrameContextMenu @ main.js:2802
(anonymous) @ main.js:198
main.js:58 Uncaught SyntaxError: JSON syntax error
    at Object.ThrowError (main.js:58)
    at Object.Parse (main.js:171)
    at Object.exports.parse [as JSONParse] (main.js:176)
    at OnFrameContextMenu (main.js:2802)
    at main.js:198
ThrowError @ main.js:58
Parse @ main.js:171
exports.parse @ main.js:176
OnFrameContextMenu @ main.js:2802
(anonymous) @ main.js:198
main.js:58 Uncaught SyntaxError: JSON syntax error
    at Object.ThrowError (main.js:58)
    at Object.Parse (main.js:171)
    at Object.exports.parse [as JSONParse] (main.js:176)
    at OnFrameContextMenu (main.js:2802)
    at main.js:198
ThrowError @ main.js:58
Parse @ main.js:171
exports.parse @ main.js:176
OnFrameContextMenu @ main.js:2802
(anonymous) @ main.js:198
main.js:58 Uncaught SyntaxError: JSON syntax error
    at Object.ThrowError (main.js:58)
    at Object.Parse (main.js:171)
    at Object.exports.parse [as JSONParse] (main.js:176)
    at OnFrameContextMenu (main.js:2802)
    at main.js:198
REPEAT FOREVER ......CRASH
+1
My profile photoLevel 1
8:57 AM
I said: Edit message
UPDATE. I did observe that if I run chrome and open the facebook page then open the developers it does not crash but hangs for a very long time. 
AND if I use EDGE to open Facebook at the same time my computer slows to a crawl.  I am thinking there is a serious script error in Facebook page and it is not being handled well by either of the browsers. It took me 4 minutes to close chrome and regain control of my computer. 

@robertogden, those IDs are local to your computer. Could you please take another look at chrome://crashes and see if there's a "server ID" for those crashes yet? You may need to click the "upload" button.

i have realized that it is about Facebook's main page (newsfeed) since the other pages work.
Maybe it is caused by getting new data from a DB since it is still occurs when i'm at another facebook url for example clicking new friends, message or notification buttons, just loader is seen, not friend requests, messages or notifs.

Deleted: chrome-fb.PNG 1.4 MB

	chrome-fb.PNG 1.4 MB View Download

Deleted: chrome-fb-nf.PNG 221 KB

	chrome-fb-nf.PNG 221 KB View Download

How long it take to fix an issue that still going on for the last week? How come the status is still untriaged?

1. Facebook login page work fine
2. After login the Facebook page won't load, after a short time it become black then you get the error message "The following page ..." Wait or Kill
3. Facebook work fine with Firefox
4. Other sites work fine with Chrome
5. Empty the cache
6. Check for the latest update
7. Disable all extensions
8. Uninstall and reinstall Chrome
9. Run malware and anti-virus

How long it will take before you take this issue seriously ?

I have the same Issue.. News feed just hangs.. but if u directly log to timeline it works .. but when it comes to homapage it freeze.

Cleared cache , tried plugins , dns flushin all. started on April 4th 2017 this issue. 

On other browsers it works fine!

I have to echo the question about why it is taking so long? It seems to me that the problem is not being taken as seriously as is warranted. I like Chrome, but if the problem is not repaired, quickly, I'll simply make a permanent switch to another brower.

Beginning last Wednesday, my PC became unstable. I ran every malware, spyware, antivirus that I could; uninstalled and reinstalled Chrome after resetting it several times; and then installed other browsers.

My Facebook page will load perfectly but seconds after doing so, the Trending box empties to a spinning wheel and the Notifications button tries to load its contents. The page freezes. Reloading the page does nothing. Making sure that Flash is enabled does nothing.

It turns out that Google issued a new browser, Chrome 57, and it does not like FB. I can load and use my FB account on the other browsers with no issues, although I prefer to continue with Chrome if possible.

This occasionally, and increasingly often, affects the other open tabs, freezing my email page and whatever other pages are open. It can be a wrestling match to close out the tabs, on several occasions requiring me to use the Task Manager. 

So far, Chrome seems to be working on my tablet and my phone....but I am afraid to check which version is operating on them. If it is Chrome 57, it seems the problem is with Facebook. 

To add to Comment 72, my PC has Windows 10 installed. 

FB will not load in Chrome. 
Problem is right side of page, it's the new FB integration app? 

By the way this has been happening nonstop for 12 hours. Thanks. 

Server crash IDs provided by robertogden@.
570cbdc610000000
e1d1c48c80000000
7ffa7493e0000000

Does not repro on 58.0.3029.54 beta

To add to this issue. When user loads Facebook to any other page except the main news feed, there are no issues.

For example; load your own profile facebook.com/yourusername there are no issues, then move to other pages with the exception of the main news feed there are no issues.

It would seem definite that the issue is with the main news feed.

If the bisect from comment 48 is correct, I would guess this issue was
somehow fixed by https://codereview.chromium.org/2640143005 (subpixel border
layout). The issue is clearly something to do with zoom-for-dsf.

Assigning to myself for next steps. Adding releaseblock-stable for M57 to block
any further rollout.

What I think is happening is that Facebook has some jasvascript that expects
a sequence of style/layout calculations to converge, and it does not in
certain cases when zoom yields floating-point outputs. The CL referenced
in comment 79 "fixes" the issue because it stops rounding off borders, which
happens to make the loop in the Facebook code converge.

It looks like Facebook will have to fix its javascript not to loop excessively/
infinitely like this.

That would be my guess as well.  The subpixel border patch in question implements
support for fractional borders, which in turn can interact with hidpi (eg. 250% will
zoom 1px borders to 2.5px, previously that would have always been floored to 2px).
Padding already supported fractions, so it's not a huge departure from previous
behavior, but it still looks like a FB script trips up on it and starts looping.

This is probably something that Facebook will have to resolve.

Thanks, it sounds like the one that fixed the issue. I assume Mac users and lowDPI chromebook users were using zoom as Mac isn't using zoom-for-dsf.

FYI it looks like Facebook has likely found a fix. Testing now.

Marking as ExternalDependancy since action required is not from the Chromium team. 

If the issue was with Facebook can you explain why we don't see this issue using a different browser ? For me it looks like you believe the issue was not with your browser that's why it is taking so long to fix. So instead to look into the neighbor backyard for the problem you should look into yours.

Hi marclphotomtl,

Each browser works in slightly different ways, so problems with individual websites can certainly show up on only one browser. In this particular case, as per comment #83, Facebook is aware of the issue and has taken steps to fix it. As per comment #79, another subpixel-related change we have in the pipeline prevents the issue from occurring, so we are prioritizing that change in future releases, but it takes a while for us to roll out a release.

From the start people were saying that the issue was only with your browser and for days the status was showing untangled. And for the comments I read it looks more like you believe the issue was with Facebook and not your fault so you expect them to fix your problem. Instead you shall ask yourself why it work with a different browser and not ours since the last Facebook update or since your last update. This is the real question you should ask yourselves. Then you will be able to fix it.

Hi marclphotomtl,

You seem angry that we haven't done enough to address this bug. I just did a brief trawl through the comments here:

* Comments #9, #10, #15, #19, #23, #64 and #77 are Chromium team members attempting to reproduce the bug (mostly unsuccessfully at first). Reproduction of a bug is an essential first step in being able to fix it. This started the day the bug was reported.

* Comments #31, #33, #36, #42, #57 are Chromium team members asking for more information from bug reporters, again in an attempt to understand what's happening more precisely.

* Comments #18, #27, #28, #39, #40, #41, #45, #47, #79, #80, and #81 are Chromium team members reasoning about crash server output and other information, trying to figure out what's going on.

Particularly of note: it was in #47 that we discovered there was a Javascript loop in the stack frames. This means that Javascript is doing something like saying "lay this out. OK, now lay this out. OK, now lay this out." without pausing between requests - that's the cause of the hang. The Javascript code running on Facebook's site is entirely authored by Facebook. However, investigation continued...

Comment #79 discovered a Chromium change that masks the underlying issue. As has already been communicated, we're working hard to prevent any future Chromium releases from being rolled out without this change included.

It wasn't until comment #80, 5 hours ago, that Facebook's code was proposed to be the underlying cause. And within 3 hours of contacting Facebook, they got back to us indicating that they'd found the problem and were testing a fix (see comment #83).

A few comments:
(1) this is an extremely active bug. Members of the paint, layout, DOM and style teams, as well as test engineers and others, collaborated on finding a fix within 5 days of filing.
(2) If even Facebook agrees that the underlying issue is with Facebook, then the underlying issue is with Facebook.
(3) Nevertheless, the Chrome team is doing all it can to help resolve the issue on our end.

Hope this helps!

Hi marclphotomtl

I think shans's comment answers the technical parts of your question. The chromium bug tracker is not a support channel, so please keep any future discussion on this bug focused on the technical solution.

I want to express my appreciation for the work the Chromium team members put forth to determine the cause of the problem. I assumed it was Chrome; it wasn't and it seems that it took Chromium team members to inform Facebook, which then fixed the glitch. That will teach me to make assumptions about code, about which I know nothing. Way to go! 

All appears to be working now.

Facebook has pushed something to production to address something similar to what was mentioned in Comment 80 and it should be live already. It's entirely possible that there's a few more similar poor assumptions in other UI components. If you can still reproduce it, it would be very helpful if you can reproduce with DevTools open, hit pause once the hang is occurring and hit 'Copy stack', resume, wait, pause, 'Copy stack' again. Repeat about 5 times and attach these stacks here.

I am not "geeky" enough to really contribute to any of this...or understand most of it, but my computer is an ASUS laptop purchased in January of this year, I believe. I have been using Chrome for years...and love it. I believe about a week ago, facebook froze and became unresponsive. I refreshed, restarted, cleared cache, uninstalled/reinstalled...all to no avail. Facebook is a big part of my marketing, so this has cost me several days of productive work. I changed to Microsoft Edge...huge fail. Oh facebook worked, but it was a big cumbersome mess. I changed to firefox...much better, but still cumbersome. I finally shut down that laptop and resurrected my old faithful Samsung...which is the previous windows (8, maybe? as opposed to 10?). I am up and running fine, but this old dog is tired and slow. I look forward to this glitch being cleared up... I hope this helps someone find a cure...

I can confirm, it's working now.

On Chrome Canary 59.0.3068.1 & Chrome 57.0.2987.133

I notice something strange right after this.

I can't post any image to my newsfeed or comment from Chrome Canary 59.0.3068.1 while in Chrome 57.0.2987.133 works just fine.

Anyone had same issue? or I need to open new issue outside here?
Thank you.

Deleted: can't upload image to my newsfeed - Canary 59.png 21.0 KB

	can't upload image to my newsfeed - Canary 59.png 21.0 KB View Download

Deleted: can't upload image to a comment - Canary 59.png 8.1 KB

	can't upload image to a comment - Canary 59.png 8.1 KB View Download

Deleted: can upload image to newsfeed - Chrome 57.png 30.8 KB

	can upload image to newsfeed - Chrome 57.png 30.8 KB View Download

Deleted: can upload image to a comment - Chrome 57.png 51.0 KB

	can upload image to a comment - Chrome 57.png 51.0 KB View Download

re comment #97 - it does not sound related to this issue. If it is still happening, please file a new issue (thanks for taking the screenshots - please attach those as well).

Issue 709795 has been merged into this issue.

It appears that this bug has been fixed by Facebook. Closing. Please comment
if you are still experiencing the same bug. If the symptoms of an issue you
are experiencing are different, please file a new bug.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-57; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-57 label, otherwise remove Merge-TBD label. Thanks.

I got this issue of tabs crashing every time a tab reach close do 500Mb of memory, tried the same website on other Browsersm Like Firefox, in Firefox works fine, with a Heavy load of memory, as expected because is a Video timeline, but works , in chrome the page always crashes.

Hi luis.krotz,

That sounds unrelated, and comments on a closed bug are likely to get overlooked. Please file a new bug :)

With Chrome 58.0.3029.110, it hangs now every time I start to scroll in FB. I cannot use FB any more.

Same here, experiencing the bug with version 58.0.3029.110 (64-bit), even after a full reinstall of Chrome. The newsfeed will freeze after a few seconds scrolling, .or. if I reverse the scrolling direction, .or. if I stop and resume scrolling. Other pages and groups work fine. 
I tried all of the above suggestions and then some more, to no effect. Edge seems to be working fine, didn't try other browsers yet.

Tried another fix and it seemed to work. I went in Default Programs (the old Control Panel version, not the new page in Settings), deselected Chrome as default web browser, selected it again and told it to be the default handler for everything. Note that Chrome was already set up that way in origin, so something must have messed with the settings. 
As of today I am not having crashes while scrolling, so either my fix has worked or else Facebook has put its act together.

We welcome bug reports and working with folks to help track down problems and make Chromium a better browser, and websites more interoperable.

I'd like to remind everyone who is participating in the Chromium community of our Code of Conduct (https://www.chromium.org/conduct). 

With that in mind, I have removed a disrespectful and unacceptable comment from this bug. 

As this bug has been closed for a while now, new comments are unlikely to be acted on - please file a new issue, thanks!