Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should we handle content changing when scrolling down the page? #8647

Closed
mattzeunert opened this issue Apr 26, 2019 · 2 comments
Closed

Comments

@mattzeunert
Copy link
Contributor

mattzeunert commented Apr 26, 2019

When a gatherer scroll down the page it can change the page layout, e.g. due lazy loading or infinite scroll loading more content. That might matter because:

  • page content varies between gatherers, so whether the page has been scrolled can affect the scores of audits that look at the DOM
  • the new tap targets gatherer first collects elements location and then scrolls through the page to call elementFromPoint. If an element moves while scrolling down the page the gatherer will think the tap target is invisible
  • if we take a full page screenshot it should match what other gatherers see so we correctly identify elements on it

The accessibility gatherer used to run early on and it scrolled to the bottom of the page. Moving it to run last had a minor impact on some sites' scores.

Should we do anything to make this more consistent and predictable?

  • can we scroll all the way to the bottom of the page once before running any gatherers?
  • maybe after scrolling down once we could get the height of the page and if the page grows again we ignore content beyond that page height? That page height could also be the max height of the full page screenshot.

cc @patrickhulce

@patrickhulce
Copy link
Collaborator

Discussed this the other day with @mattzeunert (Thanks for filing it!) and I think it would be a great followup to #8625 to scroll to the bottom of the current page height before all the afterPass runs to address most of this.

The ignoring all elements that get created seems a little tricker to enforce on gatherers, so I'm more willing to punt that for now/let individual gatherers handle that on a case-by-case basis.

@paulirish
Copy link
Member

  • the new tap targets gatherer first collects elements location and then scrolls through the page to call elementFromPoint. If an element moves while scrolling down the page the gatherer will think the tap target is invisible
  • if we take a full page screenshot it should match what other gatherers see so we correctly identify elements on it

Looks like @connorjclark resolved these concerns with the #11536 and #11118 :D

  • page content varies between gatherers, so whether the page has been scrolled can affect the scores of audits that look at the DOM

this part is still unresolved, but i'm gonna close the issue for now as there's no action plan on the horizon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants