Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Assignee
	Description • 11 years ago

With APZ turned on the fixed headers script (fixed_header.js) which is used in multiple places (call log, contacts, sms) is not really smooth since it listen for scroll events and then it is out of sync compare to the currently displayed view.

I would like to hope that position: sticky would fix that soon but https://bugzilla.mozilla.org/show_bug.cgi?id=915474#c0 states that sticky elements are tied to the scroll events for now.

I can probably live with that for 1.3 and pray for position: sticky to be enable soon with bug 915474 fixed.

	Corey Ford [:coyotebush]
	Comment 1 • 11 years ago

No, as of bug 897105 position: sticky works well in between scroll events. Bug 915474 is a followup to that, and I've only noticed the "flickering" (distinct from jumping on each scroll event) behavior on Android. When I tried FFOS hardware, it looked great.

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Assignee
	Comment 2 • 11 years ago

(In reply to Corey Ford [:corey] from comment #1)
> No, as of bug 897105 position: sticky works well in between scroll events.
> Bug 915474 is a followup to that, and I've only noticed the "flickering"
> (distinct from jumping on each scroll event) behavior on Android. When I
> tried FFOS hardware, it looked great.

Heh, thanks for fixing my misunderstanding. Just in order to double check, you tried in the browser for FFOS, right?

	Corey Ford [:coyotebush]
	Comment 3 • 11 years ago

Yes, with the html5rocks demo page [1] mostly, plus I tried making the headers in the Settings app position:sticky, and that worked too. This was all several months ago when I was finishing work on bug 897105, though.
[1] http://html5-demos.appspot.com/static/css/sticky.html

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Assignee
	Comment 4 • 11 years ago

Thanks again.

So it sounds like position: sticky is the way to go here . This is a bit painful though since position: sticky has a few crashes and issues that prevent it to be turned on.

Andreas, any suggestions here ? Are you fine with the fact that fixed header are a bit laggy, or should we try to get position: sticky turned on for b2g ?

Just in case fixed headers are the thing in the contacts apps that stays at the top telling you into which category you are, or the thing in the call log that stays at the top telling you the date of the calls you are looking at.

	Andreas Gal :gal
	Comment 5 • 11 years ago

Turning on sticky for 1.3 sounds like the right thing to do. What do you need for that?

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Assignee
	Comment 6 • 11 years ago

(In reply to Andreas Gal :gal from comment #5)
> Turning on sticky for 1.3 sounds like the right thing to do. What do you
> need for that?

There is a few followups for it and a few crashes. Not sure any of those will affects our use cases though but random may content can use it.

So either we fix those crashes in 1.3,  or otherwise we can try to find a way to enable only for certified app until it is ready. Or the lazy road is to enable it and decide that due to our low volume for the moment, it does not really matter.

In order I would prefer (1), but this one depends on resource/prioritization, or (2) since it exposes only us and let us dogfood it and carefully ensure it will not break random stuff (but it feels a bit sad), and (3) if the crash really happens in specific cases where people use it (since probably nobody use it too much yet).

	Kevin Grandon :kgrandon
	Comment 7 • 11 years ago

I have three pull requests up for the apps which use FixedHeader.js. They are all blocking this bug.

Unfortunately position:sticky seems to not play well with BrowserElementPanning it seems. My preference would be to enable position: sticky at the same time we enable APZ, and work hard to resolve any crashes in parallel.

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Assignee
	Comment 8 • 11 years ago

(In reply to Kevin Grandon :kgrandon from comment #7)
> I have three pull requests up for the apps which use FixedHeader.js. They
> are all blocking this bug.
> 
> Unfortunately position:sticky seems to not play well with
> BrowserElementPanning it seems. My preference would be to enable position:
> sticky at the same time we enable APZ, and work hard to resolve any crashes
> in parallel.

BrowserElementPanning will be disable more or less completely for child processes with APZC so that should be fine. Can you start to get some reviews on them so we can land when we're ready with APZ ?

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Assignee
	Comment 9 • 11 years ago

I played with position: sticky and the patches and I have seen some issues in the sms app, where the fixed bar is above the other one while panning, a bit less fps, and some rendering artifacts.

I wonder if for 1.3 we should not just tweak the values at http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncPanZoomController.cpp#221 to mitigate the issue.

Kats do you have any opinion on that ?

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

I'm ok with tweaking the frequency of the async scroll event, but I'm not sure how that helps. AFAIK the position:sticky implementation is implemented similarly to position:fixed and doesn't depend on those events at all. Are you using the async scroll events to keep other things in sync with position:sticky items? Or do you not want to use position:sticky at all?

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Assignee
	Comment 11 • 11 years ago

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #10)
> I'm ok with tweaking the frequency of the async scroll event, but I'm not
> sure how that helps. AFAIK the position:sticky implementation is implemented
> similarly to position:fixed and doesn't depend on those events at all. Are
> you using the async scroll events to keep other things in sync with
> position:sticky items? Or do you not want to use position:sticky at all?

If we tweak the async scroll events this is in order to not use position: sticky at all in 1.3. I think we should still use it for 1.4 and fix the artifacts of position: sticky and the underlying Gaia patches.

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Assignee
	Comment 13 • 11 years ago

https://hg.mozilla.org/integration/b2g-inbound/rev/f56f433b9bd5

	Ryan VanderMeulen [:RyanVM]
	Comment 14 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/f56f433b9bd5

	Ryan VanderMeulen [:RyanVM]
	Comment 15 • 11 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/ece134164e58