Switching tabs in Safari for iOS still displays the elements that should be hidden

[envilgt]

We implemented it on a solution that opens a webpage, with sensitive data on a header is set to be hidden, and it works for all browsers but Safari on iOS, where the data that should be hidden, is displayed when switching tabs.

[yoavweiss]

/cc @rniwa @philipwalton

Seems like the current spec language would consider "hidden" a document that's not fully active, which I interpret as Safari's behavior being compliant. Maybe we should change the spec to match user and developer expectations of what's considered hidden?

[philipwalton]

Yep, this is good timing as I just filed #59 to discuss a similar ambiguity with when the hidden state should be.

[rniwa]

Well, visibility state is changing to hidden when a tab goes to background. The issue for your use case is that Safari wouldn't update the rendering of the page after firing visibilitychange.

Unfortunately, this is not something we can do as we also tear down the render tree when going to background. Also for security purposes, we freeze the painting of a page when we commit a new page load.

@cdumez

[philipwalton]

We discussed this issue on today's WebPerf WG call and the consensus was that UAs are often not able to make rendering updates after firing the visibilitychange event, and thus it's not recommended that developers use the visibilitychange event to hide potentially sensitive information.

We also resolved to update the spec to clarify that, in the hidden visibility state, it may be possible for a user to still see a non-interactive preview/screenshot of the page. We'll also add a note to clarify that developers should not expect rendering updates to occur after the visibility state changes to hidden (i.e. they won't occur until after it changes back to visible, if it does).

For this particular case, I'd recommend hiding any potentially sensitive information when the tab loses focus. You might find the passive state in this Page Lifecycle article useful.

[rniwa]

For this particular case, I'd recommend hiding any potentially sensitive information when the tab loses focus. You might find the passive state in this Page Lifecycle article useful.

Note that blur would only fire if the document had the focus at the time of swathing the tab, and even then the rendering opportunity (i.e. repaint) would never happen until the tab is re-opened by the user so it's still late.

Unfortunately, as things stand, there is no mechanism for a web page to update its rendering after the user had started switching to another tab. That's not something we support, the same way we don't support updating the rendering of a web page once a new page navigation is scheduled.

[yoavweiss]

Closing as no further action is needed on the spec.