Markus Stange [:mstange] Reporter
	Description • 9 years ago

In this testcase, the fixed background (the blue-to-black radial gradient square) shouldn't leave the green box to the sides during scrolling.

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

So in current nightly the blue box doesn't *leave* the green box, although it does appear to get clipped a little more than it should during scrolling. Not sure if Botond's work in bug 1208829 will take care of this or not.

	Botond Ballo [:botond]
	Comment 2 • 9 years ago

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> So in current nightly the blue box doesn't *leave* the green box, although
> it does appear to get clipped a little more than it should during scrolling.
> Not sure if Botond's work in bug 1208829 will take care of this or not.

Looks like not.

Note that the only reason I haven't looked at this yet is that Markus said he thought this pattern wasn't common enough to warrant blocking all-aboard-apz, and I'm prioritizing blockers over non-blockers. If the categorization changes, I'm happy to look at this.

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

For the record, Markus says that fixing this bug would give us an alternate way to implement parallax [1] which would be a better solution than what we have now.

He said "it works well in Firefox non-APZ, it jitters with APZ due to bug 1201894, it works well in Safari, and it's extremely slow in Chrome". As opposed to the approach at [2] which doesn't work well on iOS, and may make authors reluctant to use it.

[1] http://tests.themasta.com/transform-fixed-parallax.html
[2] http://keithclark.co.uk/articles/pure-css-parallax-websites/

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

12:11:10 mstange: when I said "works well in Safari", I was referring to Safari on OS X
12:11:26 mstange: safari on iOS doesn't do background-attachment:fixed at all, as far as I can see

so maybe this isn't a better solution, but it's still another solution.

	Botond Ballo [:botond]
	Comment 5 • 8 years ago

I'm going to have a look at this.

	Botond Ballo [:botond]
	Comment 6 • 8 years ago

This is the testcase worked into a reftest.

The reftest analyzer images show that the blue square isn't being clipped, it's being translated incorrectly (and then clipped to the bounds of the outer div).

	Botond Ballo [:botond]
	Comment 7 • 8 years ago

The issue here is that Layout and AsyncCompositionManager handle the interaction between the relevant features (scrolling, background-attachment:fixed, and css transforms) in different ways.

I've investigated the difference a bit, and talked to Matt about it, and we have some ideas on how ACM could be modified to behave like Layout, but in the process we discovered that Layout's behaviour is actually not spec-conforming!

The CSS transforms spec [1] says:

  “For all other elements that are effected by a transform (i.e. have a 
   transform applied to them, or to any of their ancestor elements), a 
   value of fixed for the background-attachment property is treated as if 
   it had a value of scroll. The computed value of background-attachment 
   is not affected.“

So, before making changes to ACM to behave like Layout, we should decide what we want the Layout behaviour to be in the first place.

Matt observed that Chrome appears to be doing the same thing as us, and that, given that, and given that we'd like to have the current behaviour as a parallax option, it might make sense to try and get the spec changed. Markus - any thoughts about this?

[1] http://www.w3.org/TR/css3-transforms/

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

This is very interesting!

This part of the spec has been added about three years ago, and here's the discussion behind it: https://lists.w3.org/Archives/Public/www-style/2012Jun/0635.html
It looks like Edge has changed to match the spec. For Gecko, there's bug 735857, but nobody has touched it.

I think we should just do what the spec says. It's much easier to implement and makes more sense to web authors.
It does mean that we can't recommend it as a parallax alternative, but given the fact that it doesn't work in Edge and is very slow in Chrome, I don't think we could have done that anyway.

	Botond Ballo [:botond]
	Comment 9 • 8 years ago

Thanks for digging this up, Markus! 

The way forward then seems to be to change Layout's behaviour to be as spec'd, which is tracked by bug 735857.

I don't see much point in changing APZ to match Layout's current behaviour if we don't want the current behaviour anyways, so I don't plan on doing that. Instead, I will mark this as dependent on bug 735857; if, once that's fixed, any APZ changes are required to match the new behaviour, we can do those here.

	Botond Ballo [:botond]
	Comment 10 • 8 years ago

This is no longer a candidate for providing an alternative parallax implementation. It's still an APZ bug (as a testcase that doesn't jitter without APZ does jitter with it), but not a particularly urgent one now that it's not going to give us parallax.

	Michelle Funches - QA
	Comment 11 • 8 years ago

Name 	Firefox
Version 	47.0a1
Build ID 	20160201030241
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0

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

This is still visible on OS X.

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

This looks much worse on 48 because of paint-skipping.

	Botond Ballo [:botond]
	Comment 14 • 8 years ago

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #13)
> This looks much worse on 48 because of paint-skipping.

Kats and I discussed this and decided that because of how much worse this test case behaves with paint-skipping, it needs to be fixed one way or another.

There are two ways to fix it:

  (1) Fix Layout's behaviour to match the spec (bug 735857), and then make
      any adjustments to AsyncCompositionManager that might be necessary.

  (2) Adjust AsyncCompositionManager to match Layout's current (non-compliant)
      behaviour.

(1) would be preferable, so I'll start by investigating bug 735857. If that doesn't pan out for some reason, or ends up being more work than we want to do right now, we can fall back on (2).

	Botond Ballo [:botond]
	Comment 15 • 8 years ago

(In reply to Botond Ballo [:botond] from comment #14)
> There are two ways to fix it:
> 
>   (1) Fix Layout's behaviour to match the spec (bug 735857), and then make
>       any adjustments to AsyncCompositionManager that might be necessary.

Bug 735857 is now fixed, and no adjustments to AsyncCompositionManager are necessary - the testcase in this bug now works fine as-is. I'm therefore going to close this as a duplicate of bug 735857.