Freezing in content/hang in chrome when visiting Humble Bundle "Double Fine Presents"

VERIFIED FIXED in Firefox 66

Status

()

defect
P2
normal
VERIFIED FIXED
3 months ago
a month ago

People

(Reporter: yoasif, Assigned: sotaro)

Tracking

(Blocks 1 bug, {nightly-community, regression})

Trunk
mozilla66
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox64 unaffected, firefox65 unaffected, firefox66 verified)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

3 months ago

Visit https://www.humblebundle.com/games/double-fine-presents

What happens: Freezing of page, non-responsive chrome. Browser eventually freezes and OS asks to force quit.

See screencast.

12:29.47 INFO: No more inbound revisions, bisection finished.
12:29.47 INFO: Last good revision: fd6b8be34aed51a18d91261abeb586bbbf350e50
12:29.47 INFO: First bad revision: d1b5339852740fc2e559b66668204fc9202daf15
12:29.47 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fd6b8be34aed51a18d91261abeb586bbbf350e50&tochange=d1b5339852740fc2e559b66668204fc9202daf15

(Reporter)

Updated

3 months ago
Blocks: 1508522
Has Regression Range: --- → yes
Has STR: --- → yes
(Reporter)

Comment 1

3 months ago
(Reporter)

Updated

3 months ago
Keywords: regression
(Reporter)

Updated

3 months ago
See Also: → 1517940

Comment 2

3 months ago

Sotaro, might be related to the change in the pushlog above?

Flags: needinfo?(sotaro.ikeda.g)
Priority: -- → P2
Assignee: nobody → sotaro.ikeda.g
(Assignee)

Comment 3

3 months ago

I confirmed the same regression range as in comment 0.

https://perfht.ml/2FASkl2 is a profile before freeze. Majority of time was spent in PrimitiveStore::update_visibility()

Visual Studio Concurrency Visualizer also showed high cpu usage in PrimitiveStore::update_visibility(). Somehow PrimitiveStore::update_visibility() took very very long time.

Flags: needinfo?(sotaro.ikeda.g)
(Assignee)

Comment 4

3 months ago

"for y in p0.y .. p1.y {}" in TileCache::update_prim_dependencies() actually took long time. Iteration was huge since world_rect was very large.

https://searchfox.org/mozilla-central/rev/32d853b479cc0224d67693f0e33e9d924a33c078/gfx/wr/webrender/src/picture.rs#474

Then when picture caching was disabled, I did not saw the hang.

(Assignee)

Comment 5

3 months ago

Frame size became too big, we need to add a size limit to nsDisplayTransform::ShouldPrerenderTransformedContent() for webrender.

Comment 6

3 months ago

Huh, this is very unexpected. That loop should in theory only cover a small amount of tiles, regardless of the size of the incoming content? I can take a look at this on Monday - thanks for looking into it so far!

(Assignee)

Comment 7

3 months ago

Thanks!

(Assignee)

Comment 8

3 months ago

Anyway, it seems necessary to limit frame size of async animation.

Sotaro, I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1521329 which has a bug fix in picture caching for this problem. With the change, the picture caching code is not affected by the size of the primitive dimensions.

(Assignee)

Comment 11

3 months ago

Thanks! I confirmed that the problem was addressed :)

(Assignee)

Updated

3 months ago
Attachment #9037755 - Attachment is obsolete: true
(Reporter)

Comment 12

3 months ago

This now works for me.

Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED

I have managed to reproduce the issue using Fx 66.0a1 buildID: 20190119215456 on Ubuntu 16.04 x64.

The issue is verified fixed using Fx66.0b13 on macOS 10.14, Windows 10 x64 and Ubuntu 16.04.
Please note that the bundle used for the bug submission was no longer available, so another bundle link was used to successfully reproduce the issue and confirm its fix. (here is the link of the bundle)

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.