Closed Bug 1211507 Opened 9 years ago Closed 5 years ago

APZ causes elements to be rendered in the wrong position on page

Categories

(developer.mozilla.org Graveyard :: Design, defect)

Product:
developer.mozilla.org Graveyard
Component:
Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: vladan, Unassigned)

References

(
URL
)

Details

(Whiteboard: [apz-evangelism] [sitewait]) 

STR:
1. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial
2. Scroll the page all the way to the bottom
3. Use the mousewheel to quickly scroll back to the top of the page. Observe the "In this article" sidebar on the right

Expected: Page scrolls normally to the top, "in this article" side bar never moves higher than the article title

Actual: "In this article" sidebar gets moved all the way to the top of the page, overlapping the other page content (see attached screenshot)
Version: 43 Branch → Trunk
I can reproduce this. It looks like there is some script that changes that block from fixed position to non-fixed and vice-versa, based on the scroll position. They should probably be using position:sticky instead which would work with APZ.
Blocks: apz-desktop
No longer blocks: paint-fast
Yes, position:sticky would avoid this problem. But the delay in the transition from fixed to non-fixed seems excessively long. It looks like we invalidate the whole page when that happens.
Whiteboard: [apz-evangelism]
Chris, do you know who is working on the JS/CSS of MDN?
Flags: needinfo?(cmills)
Whiteboard: [apz-evangelism] → [apz-evangelism] [sitewait]
CSS topic owner — Jean-Yves Perrier
JS topic owner — Florian Scholz
Flags: needinfo?(cmills)
hehe Chris, I meant the MDN CSS/JS for the UI, not the documentation part :) Little hands developing the back-end and front-end. Sorry for the fuzzy request.
Flags: needinfo?(cmills)
Oh, sorry ;-)

Best person to talk to about MDN front end dev/UI is probably Stephanie Hobson.
Flags: needinfo?(cmills)
Stéphanie, 
could you help us with this bug?
Flags: needinfo?(shobson)
Even if MDN is changed to use position:sticky, we should still figure out where the invalidation is coming from, and why it only happens when the sidebar transitions from fixed to absolute and not in the other direction.
There is a delay because we debounce[1] the function that performs the scroll position check before adding or removing the position:absolute from the sidebar.

What is APZ?


[1] https://davidwalsh.name/javascript-debounce-function
Flags: needinfo?(shobson)
APZ is the new asynchronous panning mechanism that we are turning on in Desktop Firefox (46 and onwards). I have a blog post relevant to this at https://staktrace.com/spout/entry.php?id=834 which might provide some helpful background info.
If you're just seeing a delay you should compare what you're seeing to the behaviour in a release version of Firefox. I suspect the behaviour will be the same (or possibly just have a slightly longer delay if I understand the implications of APZ).
If there is a delay in the release version of Firefox, it's not noticeable (to me at least). With APZ the delay is noticeable.
There's a delay on release for me. It drives me nuts but not enough to fix it since it's a long standing problem ;)

You can open a bug in the MDN component if you like but I don't think it will get much movement for a few months.
I'll move this bug over; there's nothing else actionable for this on the platform side. Please feel free to adjust the component as needed, I'm just guessing at the right one.
Component: Panning and Zooming → Design
Product: Core → Mozilla Developer Network
Version: Trunk → unspecified
This hasn't been converted to position:sticky, but it works much better now on Nightly than it did a few weeks ago. It looks like the invalidation is no longer happening.
I'm removing this bug from the blocking bug 1013364 list, but I'm not closing it because position:sticky is still the right thing to use here.
No longer blocks: apz-desktop
We won't be updating to position:sticky until our user base can support it.
There are polyfills which make it easy to use position:sticky in browsers that already support it.
Stephanie, does the availability of polyfills for position:sticky change the situation at all?
Flags: needinfo?(shobson)
The core team is very short on resources at the moment.

You are welcome to submit a pull request yourself :)

https://github.com/mozilla/kuma/blob/master/CONTRIBUTING.md
Flags: needinfo?(shobson)

Site has changed, the sticky sidebar doesn't seem to exist any more.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.