andrewtrapani Reporter
	Description • 8 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

1. Go to the article here "Interactive Map Of Bay Area Shows What Presidential Candidates Your Neighborhood Backs"

http://sfist.com/2016/03/17/you_wanna_be_on_top.php

2. Find the interactive map of political donors in the SF bay area.

3. Scroll up (in) and down (out) on the interactive map.

4. Firefox hangs completely.

Force quite is the only option.

Completely repeatable on FF 45, OS X 10.10.5 with whatever specific add ons I have.


Actual results:

Firefox hangs and does not recover.

FF uses 100+% on the activity monitor. OS X's kernel_task uses 100% CPU and then 50~60% after about 10 seconds. Monitored for over 90 seconds and stayed the same.

User must force quit FF.

Crash reporter does not initiate a report on restart.

Imagine scrolling down the page and accidentally scrolling in on the map. Unavoidable hang up.


Expected results:

Map scrolls in and out without crashing.

	Vuyisile Ndlovu [:terrameijar]
	Comment 1 • 8 years ago

Thanks for reporting this. 

I was able to partly reproduce this bug in a pre-release version of Firefox on a different Operating System, details below:

Actual Results:

Firefox hangs for a second or two, CPU Usage on one core shoots to 100% and the "Bad news first: This tab has crashed" page shows up.

The browser doesn't hang and it is possible to continue browsing after the crash

System details:

Firefox 48.0a1 User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

Crash report: https://crash-stats.mozilla.com/report/index/7591da43-039d-45c7-92b8-f93cc2160321

	Vuyisile Ndlovu [:terrameijar]
	Comment 2 • 8 years ago

Possibly related to or a duplicate of: https://bugzilla.mozilla.org/show_bug.cgi?id=1255130 the crash signature I posted in comment 1 and the one in  bug 1255130 are similar

	Jamie Nicol [:jnicol]
	Comment 3 • 8 years ago

The difference between comment 0 and comment 1's behaviours is that e10s is disabled in comment 0 and enabled in comment 1. These tickets could well have the same underlying reason, but e10s means it manifests in different ways.

I can only reproduce this with hardware accelerated layers enabled. I notice when I reproduce that firefox's memory usage keeps increasing and increasing while it is frozen, until the process is killed by the OS. This is with e10s disabled.

I couldn't find a regression window, as using older builds with layer acceleration force-enabled caused crashes for other reasons.

cc kats and nical since they have been active on bug 1255130, which might be related.

	Nicolas Silva [:nical]
	Comment 4 • 8 years ago

Yeah, looks very much like bug 1255130.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 5 • 8 years ago

I can repro this as well, it brings the browser to its knees and should probably be investigated at some point.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 6 • 8 years ago

If anything for me it's better now than when it first went bad:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=095d2a9c2be5&tochange=869971ad9fd6

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 7 • 8 years ago

If I was guessing, I'd guess something on the APZ side, perhaps bug 1034376 or bug 1037591, but I can't build that far back on OS X.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 8 • 8 years ago

Kats, sounds like you can also reproduce - do you see the same regression range, can you build through those changes?  No inbound saved that far back.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 9 • 8 years ago

I can repro on http://archive.mozilla.org/pub/firefox/nightly/2014/07/2014-07-16-03-02-02-mozilla-central/ but I can also repro on the previous build, http://archive.mozilla.org/pub/firefox/nightly/2014/07/2014-07-15-03-02-07-mozilla-central/ so based on that I think it regressed earlier than what your range indicates. I'll run mozregression as well to see if I can track it down.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 10 • 8 years ago

mozregression gave me http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=588424024294&tochange=89dcadd42ec4

I'll try to do local builds on that range.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 11 • 8 years ago

I'm also unable to do local builds, I keep running into compile errors with libvpx, and even disabling webm doesn't make them go away.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 12 • 8 years ago

A complete shot in the dark, but the interactive map's got SVG, and there was a large-ish SVG change in the range from comment 10 - bug 655877...

	Markus Stange [:mstange]
	Comment 13 • 8 years ago

This page is generating 514 active transforms for me, each containing a 8488x8488 PaintedLayer.

	Markus Stange [:mstange]
	Comment 14 • 8 years ago

Each of the <path> elements has a transform attribute with a gigantic scale, e.g. transform="translate(187886.09983278048,62740.97735421615)scale(551117.3421597779)", and during zooming this transform gets updated by JS (which will cause us to treat the transform as active).

Still not sure what in the regression range could have affected our behavior here.

	Cameron McCormack (:heycam)
	Comment 15 • 6 years ago

Coming back to this, I don't see any ballooning memory or CPU usage when interacting with the map.