Gracefully handle documents that are not fully active

[marcoscaceres]

Closes #78

The following tasks have been completed:

• Modified Web platform tests - unfortunately, we don't have the capability to test this with WPT.

Implementation commitment:

• WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko (https://phabricator.services.mozilla.com/D117273)

cc @rakina

---

Preview | Diff

[rakina]

Thank you! Looks good to me, just need the WPTs now :)

[reillyeon]

Maybe I'm missing the issue this change is attempting to fix but what happens after the following sequence of events,

1. Document is fully active.
2. Script calls navigator.geolocation.watchPosition().
3. Document becomes not fully active.
4. A "significant" change in position occurs.
5. Document becomes fully active.

As written it seems like when a significant change in position occurs while the document is not fully active it will cause the watch to be canceled. Is this intentional? More likely it seems like we want to explicitly cancel all pending requests on transition to being not fully active. We definitely don't want to deliver a position update while not fully active but we may want to preserve active watches and check on transition back to fully active whether a significant change in position has occurred.

[marcoscaceres]

Yeah, I agree. We might need some kind of independent watcher that checks before the callbacks happen.

[marcoscaceres]

@rakina @reillyeon, I've reworked this a bit so now:

1. if not fully active and the API is called, gracefully return an arbitrary number.
2. if document suddenly becomes not fully active, drop the position request on the floor (and keep dropping them until such time as as the doc becomes fully active).
3. Do the above also for page visibility too - so that only fully active visible documents receive position updates.

I'll put together some tests for what I can.

[rakina]

Do we want to remember that it happened (not the exact position, but just that we dropped an update) so that we can send an update with the current position when the document becomes fully active and visible again? Otherwise when a page is restored from bfcache and the user stopped moving (?) it might be stuck with a stale location.

[reillyeon]

In w3ctag/design-principles#317 the example explicitly calls out the Geolocation API as a case where updates should not be queued and delivered once the document becomes fully active. It is however important to note that a site which has called watchPosition() expects geolocation updates when there is a significant change in position. To do otherwise will likely cause the site to appear stale when it is restored from bfcache and result in a poor user experience. Therefore, while updates SHOULD NOT be queued so that the site can observe the history of location changes while it was not fully active a single update SHOULD be delivered if the location is significantly different from the last value the site received while it was fully active.

[rakina]

Yep that's what I wanted to say. I guess we need to track the last position when the page becomes not fully active / visible then, so that we can compare it to the position when it becomes fully active & visible again?

[marcoscaceres]

@reillyeon wrote:

watchPosition() expects geolocation updates when there is a significant change in position.

That's true, but iff the document is visible (and fully active).

If the document transitions from "hidden" to "visible", it's perfectly reasonable for the page to call getCurrentPosition() to get a position update. But, .watchPosition() must only receive new significant position changes when visible. That is, if the page was hidden and there was a significant update, then that's too bad/too late - it has to wait for the next significant change.

See code below.

@rakina wrote:

Yep that's what I wanted to say. I guess we need to track the last position when the page becomes not fully active / visible then, so that we can compare it to the position when it becomes fully active & visible again?

My opinion is that we don't need to go to this level, because it can be handled by the developer:

// handle switching tabs
window.onvisibilitychange = () => {
   if (document.visibilityState === 'visible') {
    navigator.geolocation.getCurrentPosition(updateMap);
  }
}
// keep getting significant updates indefinitely...
navigator.geolocation.watchPosition(updateMap);

[rakina]

My opinion is that we don't need to go to this level, because it can be handled by the developer:

I guess that sounds reasonable, for the bfcache case web devs can listen for the pageshow event as well. I guess I'm a bit worried that most web devs are not aware of bfcache and thus might miss this edge case (and we kinda want to have existing pages to "just work" with bfcache), but I don't really have a strong opinion on this so I'll trust your decision here!

[marcoscaceres]

I think it might not be possible to test this with WPT. The limitation that we have is that I can't spin up a tab, then switch back to the original test's tab, which would cause the background tab to be "hidden".

Similarly, with an iframe: removing the iframe makes it "hidden", but it simultaneously trashes the iframe's window object, hence you can't call geolocation on it (unless you steal a reference to geolocation before it is GC'ed, but at that point you are dealing with dead objects).

[rakina]

Similarly, with an iframe: removing the iframe makes it "hidden", but it simultaneously trashes the iframe's window object, hence you can't call geolocation on it (unless you steal a reference to geolocation before it is GC'ed, but at that point you are dealing with dead objects).

Is this still true for the window on a nested iframe too? (so you detach the parent iframe but watch on the nested iframe). Also what about testing the "watch position -> detach, update position -> attach again, see no location update is sent"?

If that's not possible, I guess the only way to test this is through BFCache. Currently @hiroshige-g is setting up the foundations for BFCache WPTs at web-platform-tests/wpt#28950. I think he's planning to write a Geolocation WPT eventually, but if you want to try writing one now you're more than welcome to! (also it's great to have a feedback on the WPT foundations from a non-BFCache person :) )

[marcoscaceres]

Is this still true for the window on a nested iframe too? (so you detach the parent iframe but watch on the nested iframe). Also what about testing the "watch position -> detach, update position -> attach again, see no location update is sent"?

I holds true there too. Once the iframe is removed, the whole document and the window object is GC'd. Reattaching it creates a both a new Window and a new Document (i.e., so position updates are not sent).

Currently @hiroshige-g is setting up the foundations for BFCache WPTs at web-platform-tests/wpt#28950. I think he's planning to write a Geolocation WPT eventually, but if you want to try writing one now you're more than welcome to! (also it's great to have a feedback on the WPT foundations from a non-BFCache person :) )

@hiroshige-g I've be happy to help review those, as it would be an opportunity for me to learn about BFCache.

I'm going to go ahead and merge this, as at least it gets all the browsers aligned on behavior and it's a great privacy improvement.