Closed Bug 1091000 Opened 10 years ago Closed 10 years ago

Too fast fading during transform (slideshow)

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
34 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox33 --- unaffected
firefox34 --- ?
firefox35 --- ?
firefox36 --- ?

People

(Reporter: epinal99-bugzilla2, Unassigned)

References

Details

(Keywords: regression)

STR: 1) Open http://mte90.github.io/Presentazione-FirefoxOS/ 2) Play with left/right arrows to switch ths slides Result: When clicking on the right arrow, we can't see the fading of the current slide to the next one (on the left side of the current slide), it's too much fast. We should see the current slide moving "behind" the next slide. It works fine in FF33. Regression range: good=2014-08-08 bad=2014-08-09 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=18f408a5984e&tochange=83f519eb1a3a Probably suspected bug 1042772.
status-firefox33: --- → unaffected
status-firefox34: --- → ?
status-firefox35: --- → ?
status-firefox36: --- → ?
Keywords: regression
There's a bunch of graphics changes in that range...
Regression window Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/d7680ff0e960 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140807194932 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/23ea95cbd92f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140807204245 Pushlog https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d7680ff0e960&tochange=23ea95cbd92f
Blocks: 1042772
In local build Last Good: 5948f9164d2d First Bad; 23ea95cbd92f Triggered by: 23ea95cbd92f Timothy Nikkel — Bug 1042772. Update the reference frame and current frame offset when moving to outside a transform so that we can use the correct offset to compute the initial visible rect for wrap list display items. r=roc * * * The current reference frame is still the same as our reference frame because we set and restore it in nsFrame::BuildDisplayListForChild before this. So we need to actually compute it.
Guessing this has something to do with preserve 3d.
In firefox 33 the problem not exist, is a very annoying bug :-/
The problem is that when we do preserve 3d wrapping on a frame that also has opacity the opacity item gets moved from inside the transform to outside the transform, but we don't update the opacity item's reference frame or visible rect.
I was just about to post my patch before roc beat me to posting the same patch to bug 1098266. The patch there with my suggested change fix this bug for me.
Depends on: 1098266
Should be fixed by bug 1098266 now.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.