✨ Implements amp-analytics support for amp-next-page#26451
✨ Implements amp-analytics support for amp-next-page#26451wassgha merged 17 commits intoampproject:masterfrom
amp-analytics support for amp-next-page#26451Conversation
|
@zhouyx this is ready for review but I'd be extra careful with it, might have some unexpected implications |
There was a problem hiding this comment.
EDIT: I realized that many of these changes rely on synchronously measuring the layout, such as scrollTop and scrollWidth, which could cause layout thrashing. Please refactor to use measureMutateElement/mutateElement where appropriate. Happy to discuss further if you'd like.
Approving amp-next-page changes once all comments are addressed. Deferring to @zhouyx for overall approvals for merge. :)
| const scrollEvent = { | ||
| top: e.top, | ||
| left: e.left, | ||
| top: e.top - layoutRect.top, |
There was a problem hiding this comment.
Why isn't this expected to be a breaking change?
There was a problem hiding this comment.
same question, could you please expand a bit on what are the this.viewport_.getScrollTop(), layoutRect.top. thanks
There was a problem hiding this comment.
This shouldn't be a breaking change for the non-shadow case because for the top-level page, this.root_ is equivalent to the document body which means that for the existing case, layoutRect.top and layoutRect.left would be 0 (so it doesn't change the existing behavior). For the ShadowDOM case, this.root_ becomes the ShadowDOM's container, in which case the layoutRect.top and layoutRect.left would serve to offset the calculations to become relative to the ShadowDOM's container as opposed to the top level container.
There was a problem hiding this comment.
@zhouyx are there any test suites / manual tests we can do here to ensure that nothing breaks?
There was a problem hiding this comment.
nothing that tests shadow dom that I'm aware of. Please feel free to create and add new ones. Thanks!
There was a problem hiding this comment.
Thanks for the explanation. One more question on the viewport.getScrollTop() for the non-shadow case. Does the shadow doc share the same viewport service as the parent? What is the scrollTop value here?
There was a problem hiding this comment.
If I understand correctly, it does not, the shadow docs will have a viewport service for their own ampdoc instance ( AmpDocShadow as opposed to AmpDocSingle) so viewport.getScrollTop will yield the distance between top of the page and the position of the shadow doc.
| const scrollEvent = { | ||
| top: e.top, | ||
| left: e.left, | ||
| top: e.top - layoutRect.top, |
There was a problem hiding this comment.
same question, could you please expand a bit on what are the this.viewport_.getScrollTop(), layoutRect.top. thanks
|
Added @dvoytenko for sanity checking |
alanorozco
left a comment
There was a problem hiding this comment.
Refactor and rename request.
(No strong preference on specific nouns btw, as long as the structure/positive boolean is kept).
dvoytenko
left a comment
There was a problem hiding this comment.
LG from amp-next-page code itself. I'm leaving analytics review to the respective wg
0603aa1 to
c445ee1
Compare
| } = layoutRect; | ||
| /** {./scroll-manager.ScrollEventDef} */ | ||
| const scrollEvent = { | ||
| top: e.top - scrollTop, |
There was a problem hiding this comment.
If I understand correctly, it does not, the shadow docs will have a viewport service for their own ampdoc instance ( AmpDocShadow as opposed to AmpDocSingle) so viewport.getScrollTop will yield the distance between top of the page and the position of the shadow doc.
I'm a bit lost : ) If that's the case, e.top is the distance of the element to the shadow doc top. Do we still need to minus the scrollTop here?
There was a problem hiding this comment.
Yes :)) So that an element placed at the top of the shadow doc would be considered at 0% of the top (where top refers to the top of the embedded document, not the entire page)
|
Are we waiting for anything on this one? |
|
No, didn't get a chance to review the change. Will do today. |
|
one more unresolved comment #26451 (comment) |
|
@alanorozco @caroqliu ping |
* master: Launch `amp-next-page` v2 & clean up experiment (ampproject#27035) ✨Implement Display Locking on amp-accordion (ampproject#25867) 📖<amp-next-page> documentation and validation (ampproject#26841) Improve visibility event tests (ampproject#26847) amp-geo: Fall back to API for country (ampproject#26407) ✨ Add customization options to <amp-story-quiz> (ampproject#26714) navigation: Minor test improvements (ampproject#26926) ♻️ Alias video.fullscreen action for symmetry with interface names (ampproject#27017) ✨ Implements `amp-analytics` support for `amp-next-page` (ampproject#26451) ✨ amp-video-iframe integration: global jwplayer() singleton by default (ampproject#26969) Fix unit tests broken by ampproject#26687 (ampproject#27000) Filter redirect info from emails (ampproject#27012) 📖 Make amp-bind doc valid, fix amp-form stories filter (ampproject#27003) url-replacements: Minor test improvement (ampproject#26930) viewport: Minor test improvement (ampproject#26931) amp-consent fullscreen warning (ampproject#26467) dep-check: USE CAPS FOR IMPORTANCE (ampproject#26993) fix img url (ampproject#26987) # Conflicts: # extensions/amp-next-page/amp-next-page.md
Changes
ignoreResizeto thescrollSpecof<amp-analytics>. This prevents counting subsequent loaded document heights as part of the host/parent page's scrollable area, which means that at 100%, the first/parent document has been fully read and the user is now transitioning to the next document.viewport.getLayoutRect()instead ofviewport.getScrollWidth/viewport.getScrollHeight)amp-next-pagedocument visibility #25388Assumptions (will be enforced by validator changes):
amp-next-pageelement per AMP documentamp-next-pageis always the last child of the body so there is no content after it (footers will be declared inside theamp-next-pageelement)amp-next-pageand the footer is not counted as part of the host document's scrollable area