Polymer: Element stamping doesn’t occur in background tabs until window is focused

[andybons]

Repro Steps

• Visit https://gerrit-review.googlesource.com/?polygerrit=1 (to ensure the Polymer version is turned on).
• ⌘-Click (on a Mac) on https://gerrit-review.googlesource.com/ to open the link in a background tab.
• Click on the newly created tab.
• Notice that network requests are not kicked off until the window has focus.
  

  Expected Results

The page loads completely with all data shown.

Actual Results

The user has to activate the tab, which negates part of the reason they opened it in a background tab to begin with.

Browsers Affected

• [x] Chrome
• [x] Firefox
• [x] Safari 9

• [x] Safari 8

  Versions

• Polymer: v1.6.0

• webcomponents: v0.7.22

[sorvell]

I think what is likely happening here is that the work is kicked off in an attached call. Polymer defers attached until requestAnimationFrame to allow dom measuring to function as expected. I believe requestAnimationFrame does not fire until a page is rendered and a never focused page has not yet rendered. This would explain the behavior.

We'll go ahead and repro this with a simplified setup, but in the meantime, you can try calling Polymer.RenderStatus._makeReady() in a script at the bottom of the page or when running without native HTMLImports in HTMLImports.whenReady(function() { Polymer.RenderStatus._makeReady() }).

If I've diagnosed the problem correctly, we'll definitely consider making the fixit function less scary. For our next major version we're going to change attached deferment since it has this type of unintended consequence.

[kaste]

This has been reported as #3252

[andybons]

Adding HTMLImports.whenReady(function() { Polymer.RenderStatus._makeReady() }) to the bottom of index.html has no effect on this behavior. Anything else I can provide?

[cdata]

The core team is aware of this issue. I closed #3252 in favor of this one because this one is somewhat better formatted in accordance with our contribution guidelines.

FWIW the behavior that causes this lazy initialization (due to reliance on requestAnimationFramein certain areas) will be changed in the next major version of Polymer. It is probable that the bug will go away when this change lands.

/cc @sorvell @kevinpschaaf @azakus for more.

[aarongable]

When you say "next major version", I assume you mean Polymer 2.0? Is there an approximate timeline for when we expect to hit that version?

[cdata]

@aarongable Q32016

[andybons]

Since 2.0 has been delayed, can we work together to find a workaround for this?

[samccone]

Any way we can we prioritize this? I just was bit by this in production :/

--

Also if engineering resources are needed to make this happen on 1.x more than happy to donate my time to resolve this.

[nomego]

Will this be solved for 1.x or is 2.0 the only way forward?

[zboralski]

+1

[TimvdLippe]

If I am not mistaken, this issue has been resolved in Polymer 2. The original reported url also does not show the behavior as described in the OP. Could anyone confirm this issue is resolved such that we can close it?

[andybons]

The original URL is still using Polymer 1 and using a hack to get around this. I’m uncertain whether 2.0 has fixed this or not. @cdata?

[TimvdLippe]

Per https://github.com/Polymer/polymer/issues/4217#issuecomment-349997013 this issue no longer exists in Polymer 2. I am not sure if we want to backport this fix to Polymer 1 though.

[samccone]

If you can point us to the correct location for the change, happy to make the pull request if you and team are willing to cut a release with this change.

(There are a non-trivial number of production apps on 1.x that would benefit, and given that polymer 2.x is still not quite "ready" in some contexts many people can not "just" upgrade)

Thank you for your time and work on the project!

[kevinpschaaf]

The "fix" in 2.0 can't be backported to 1.x since it would break 1.0's contract that attached was deferred until computed styling was valid (first rAF). We explicitly changed that contract in 2.0.

The best solution for 1.x is still to have users opt-in to forcing the "render status" tracking to "ready" via an inline script in the main document (the main document script causes all styling to resolve before the script runs, making it safe) using the API mentioned in https://github.com/Polymer/polymer/issues/4217. The only work there is to expose it publicly, so @samccone if this is something you'd still like we can do that in the 1.x branch.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.