972713 - Inactive layer construction can behave in strange ways

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

A few patches coming up.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1: Make all callers of GetAnimatedGeometryRootFor pass a display item so we can stop searching when we reach the item's reference frame

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 2: Ignore active scrolled roots in inactive layer trees, because they don't help and could hurt

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The first hunk of patch #1 causes regressions. The problem is that for, say, an inactive transform display item or an SVG-transformed display item, GetAnimatedGeometryRootFor(i, aBuilder) returns the item's own frame as the geometry root --- because we don't let the search go up beyond i's ReferenceFrame(), which is its own frame. OTOH GetAnimatedGeometryRootFor(i->Frame()) would search all the way up to an actual animated geometry root. So we think the item is an animated geometry root and RequiredLayerStateForChildrenInternal returns LAYER_ACTIVE, which is wrong.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1 v2

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b5486b9ed88c
https://hg.mozilla.org/integration/mozilla-inbound/rev/7829e535cdd7

Comment 6

[David Baron :dbaron:]

So this made bug 791480 start happening 100% of the time on the Win8 reftest-noaccel.

I landed 
https://hg.mozilla.org/integration/mozilla-inbound/rev/94e20568f4e8
before realizing that this was a new 100%-of-the-time failure rather than an intermittent whose annotation needed updating.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Backed out: https://hg.mozilla.org/integration/mozilla-inbound/rev/148794d81e95

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b5486b9ed88c
https://hg.mozilla.org/mozilla-central/rev/7829e535cdd7

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Per comment 7, this shouldn't have been merged to m-c.

Comment 10

[Carsten Book [:Tomcat]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #9)
> Per comment 7, this shouldn't have been merged to m-c.

grr sorry yeah my fault will merge the backout cset to m-c when its ready

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Also, shouldn't dbaron's change in comment 6 be backed out? Doesn't look like it was.

Comment 12

[Carsten Book [:Tomcat]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #11)
> Also, shouldn't dbaron's change in comment 6 be backed out? Doesn't look
> like it was.

setting needinfo for dbaron so that this don't get lost

Comment 13

[Carsten Book [:Tomcat]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> Backed out:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/148794d81e95

also landed on central as https://hg.mozilla.org/mozilla-central/rev/148794d81e95 (sorry again, my fault)

Comment 14

[David Baron :dbaron:]

RyanVM backed it out.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I can't reproduce this on my Windows laptop, having tried various configurations.

I'll try chaos mode to see if that helps.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c6a7a027c126
https://hg.mozilla.org/integration/mozilla-inbound/rev/93265ade3bc9

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c6a7a027c126
https://hg.mozilla.org/mozilla-central/rev/93265ade3bc9