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.

Sign up for GitHub

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

Gracefully handle documents that are not fully active #90

Merged
merged 8 commits into from
Jul 15, 2021
Merged

Gracefully handle documents that are not fully active #90

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
307cc59
Gracefully handle documents that are not fully active
marcoscaceres Jun 9, 2021
f9a9ca7
tidy
marcoscaceres Jun 9, 2021
84217ba
fixup
marcoscaceres Jun 10, 2021
f2412e5
Merge branch 'gh-pages' into fully-active
marcoscaceres Jul 8, 2021
f38c680
Gracefully handle documents that are not fully active
marcoscaceres Jun 9, 2021
be3c046
Integrate better with visibility
marcoscaceres Jul 9, 2021
2c4dba6
Integrate better with visibility
marcoscaceres Jul 9, 2021
e07e3bf
fixup
marcoscaceres Jul 9, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 36 additions & 7 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,8 @@
};
</script>
</head>
<body data-cite="secure-contexts permissions-policy permissions">
<body data-cite=
"secure-contexts permissions-policy permissions page-visibility-2">
<section id="abstract">
<p>
The Geolocation API provides access to geographical location
Expand Down Expand Up @@ -118,6 +119,9 @@ <h2>
has received the following changes:
</p>
<ul>
<li>Added handling for when documents are not [=Document/fully
active=].
</li>
<li>Added the [=geolocation task source=], which handles dispatching
position updates and errors.
</li>
Expand Down Expand Up @@ -591,6 +595,10 @@ <h2>
optionally (and only if |repeats| is true) a |previousId:long|.
</p>
<ol class="algorithm">
<li>If the [=current settings object=]'s [=associated `Document`=] is
not [=Document/fully active=], return an [=implementation-defined=]
{{long}}.
</li>
<li>Let |watchTasks:Set| be [=this=]'s
{{Geolocation/[[watchTasks]]}}.
</li>
Expand Down Expand Up @@ -621,15 +629,17 @@ <h2>
</li>
</ol>
</li>
<li data-cite="page-visibility-2">Wait for document to become
visible.
<li>Wait for document to become visible.
<ol>
<li>Let |document:Document| be the [=current settings
object=]'s [=associated Document=].
</li>
<li>If |document:Document| is [=Document/hidden=], wait for
the |document| to become [=Document/visible=].
</li>
<li>Go to <a href="#wait-for-change">wait for significant
change of geographic position</a>.
</li>
</ol>
</li>
<li data-tests=
Expand Down Expand Up @@ -747,10 +757,29 @@ <h2>
</li>
</ol>
</li>
<li>Wait for a significant change of geographic position. What
constitutes a significant change of geographic position is left
to the implementation. User agents MAY impose a rate limit on the
frequency position changes.
<li>
<span id="wait-for-change">Wait for a significant change of
geographic position</span>. What constitutes a significant
change of geographic position is left to the implementation.
User agents MAY impose a rate limit on the frequency position
changes.
</li>
<li>If |document| is not [=Document/fully active=] or not
[=Document/visible=], go back to the previous step and again
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

@marcoscaceres marcoscaceres Jul 13, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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);

Copy link
Member

@rakina rakina Jul 14, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

<a href="#wait-for-change">wait for significant change of
geographic position</a>.
<aside class="note" title=
"Position updates are exclusively for fully-active visible documents">
<p>
The desired effect here being that position updates are
exclusively delivered to fully active documents that are
visible; Otherwise the updates get silently "dropped on the
floor". Only once a document again becomes fully active and
visible (e.g., an [^iframe^] gets reattached to a parent
document), do the position updates once again start getting
delivered.
</p>
</aside>
</li>
<li>If |watchTasks| [=list/contain|contains=] |watchId|, then:
<ol>
Expand Down