PerformanceNaviationTiming API type() for tab duplicate & browser restart

[Yuzu Saijo]

Hi all, 

I realized a surprising behavior of the PerformanceNavigationTiming API. 

When I duplicate a tab / quit the browser and reopen a tab, the navigation type (performance.getEntriesByType("navigation")[0].type) is “back_forward”. 

The behavior is the same on Firefox, while on Safari the navigation type stays the same as the previous state. You can test it with this site. 

Is this expected or specced anywhere?

Thanks,

Yuzu

[Domenic Denicola]

I'm aware of some discussion of related areas, but not this particular problem:

• Microsoft Edge proposal (never implemented?) for a "user agent launch" type, sort of related to your quit-and-reopen case
• +Barry Pollard discussing adding a "restore" type, and the connection to document.wasDiscarded.
  
• Fergal discussing the browser restart case

[Yuzu Saijo]

Thanks Domenic!

Fergal's thread is discussing a slightly different case:

A --> B --(back)--> A --(browser restart)--> A'

On A' , the navigation type is back-forward.

I think this is expected because the navigation type is copied from A, whose latest navigation was back-forward.

What I found is that, every time a tab is cloned or the browser is restarted, the navigation type is back-forward.

A --(browser restart / tab clone) -->A'

On A', the navigation type is back-forward. 

This is surprising in that tab clone and browser restart is indistinguishable from normal history navigation.

I'm concerned about developers calculating the bfcache hitrate.

With the current navigation type, I don't think developers can tell the difference between tab clone/ browser restart vs actual history navigation.

[Fergal Daly]

On Mon, 25 Sept 2023 at 12:30, 'Yuzu Saijo' via bfcache-dev <bfcac...@chromium.org> wrote:

Thanks Domenic!

Fergal's thread is discussing a slightly different case:

A --> B --(back)--> A --(browser restart)--> A'

On A' , the navigation type is back-forward.

I think this is expected because the navigation type is copied from A, whose latest navigation was back-forward.

What I found is that, every time a tab is cloned or the browser is restarted, the navigation type is back-forward.

A --(browser restart / tab clone) -->A'

On A', the navigation type is back-forward. 

This is surprising in that tab clone and browser restart is indistinguishable from normal history navigation.

I'm concerned about developers calculating the bfcache hitrate.

With the current navigation type, I don't think developers can tell the difference between tab clone/ browser restart vs actual history navigation.

Yeah, it seems to me that a tab-clone/restart is more like reload.

I think the spec has nothing at all to say about tab clones and restarts, is that correct?

F

 

On Mon, Sep 25, 2023 at 11:30 AM Domenic Denicola <dom...@chromium.org> wrote:

I'm aware of some discussion of related areas, but not this particular problem:

• Microsoft Edge proposal (never implemented?) for a "user agent launch" type, sort of related to your quit-and-reopen case
• +Barry Pollard discussing adding a "restore" type, and the connection to document.wasDiscarded.
  
• Fergal discussing the browser restart case

On Thu, Sep 21, 2023 at 2:57 PM Yuzu Saijo <yu...@google.com> wrote:

Hi all, 

I realized a surprising behavior of the PerformanceNavigationTiming API. 

When I duplicate a tab / quit the browser and reopen a tab, the navigation type (performance.getEntriesByType("navigation")[0].type) is “back_forward”. 

The behavior is the same on Firefox, while on Safari the navigation type stays the same as the previous state. You can test it with this site. 

Is this expected or specced anywhere?

Thanks,

Yuzu

--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAP-nMoGm-3cTANt0%2Brdh25OKsKTj0HsibhgSxc0L4WgUC-zRvg%40mail.gmail.com.

[Domenic Denicola]

On Mon, Sep 25, 2023 at 2:21 PM Fergal Daly <fer...@google.com> wrote:

On Mon, 25 Sept 2023 at 12:30, 'Yuzu Saijo' via bfcache-dev <bfcac...@chromium.org> wrote:

Thanks Domenic!

Fergal's thread is discussing a slightly different case:

A --> B --(back)--> A --(browser restart)--> A'

On A' , the navigation type is back-forward.

I think this is expected because the navigation type is copied from A, whose latest navigation was back-forward.

What I found is that, every time a tab is cloned or the browser is restarted, the navigation type is back-forward.

A --(browser restart / tab clone) -->A'

On A', the navigation type is back-forward. 

This is surprising in that tab clone and browser restart is indistinguishable from normal history navigation.

I'm concerned about developers calculating the bfcache hitrate.

With the current navigation type, I don't think developers can tell the difference between tab clone/ browser restart vs actual history navigation.

Yeah, it seems to me that a tab-clone/restart is more like reload.

I think the spec has nothing at all to say about tab clones and restarts, is that correct?

Correct.

[Ian Clelland]

I would have expected that tabs loading after a browser restart would have appeared as a new navigation. Back-forward is almost certainly wrong, since there is no chance that the page state would have been preserved.

Tap Duplication is an undefined case, and we've definitely seen oddness in other areas in the past around that. But it makes sense to me that the initial navigation event should be cloned from the original tab; that duplicating the tab wouldn't count as a "navigation" for either clone.

[Fergal Daly]

On Mon, 25 Sept 2023 at 22:20, Ian Clelland <icle...@google.com> wrote:

I would have expected that tabs loading after a browser restart would have appeared as a new navigation. Back-forward is almost certainly wrong, since there is no chance that the page state would have been preserved.

Tap Duplication is an undefined case, and we've definitely seen oddness in other areas in the past around that. But it makes sense to me that the initial navigation event should be cloned from the original tab; that duplicating the tab wouldn't count as a "navigation" for either clone.

I suppose the philosophy of this should be to violate as few expectations as possible. If your type is "navigate" that would imply that history.forward() cannot work.

I guess "back_forward" is accurate in the sense that you have been loaded from a history entry. It leads to fewer contradictions, although it does imply that at least one of history.forward() or history.back() should work but that is not guaranteed.

I think "reload" would have no contradictions as would preserving the value in the original page. Also if the page has cache-control: no-store and has been deleted, tab duplication leads to a 404. So I feel like "reload" is a strong candidate,

F