yu...@google.com, yu...@chromium.org, fer...@chromium.org
https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
https://github.com/whatwg/html/pull/9360
https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
NotRestoredReason API will report the list of reasons why a page is not served from BFcache in a frame tree structure, via PerformanceNavigationTiming API.
https://github.com/w3ctag/design-reviews/issues/739
Issues addressed
Gecko: Defer (https://github.com/mozilla/standards-positions/issues/766) Once issues (standardized reasons & unsalvageable documents), they would switch to positive.
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/154)
Web developers: Positive (https://github.com/w3c/navigation-timing/issues/171#issuecomment-1062672989)
Other signals: Positive from Origin Trial users:
How likely are you to keep using this feature?
92% answered likely, 8% (1 vote) is unsure
We do not report detailed information about cross-origin iframes. See Security and Privacy section in the explainer.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No.
In DevTools console, try:
performance.getEntriesByType('navigation')[0].notRestoredReasons;
Yes.
NotRestoredReasons API is available on all platforms including WebView, but back/forward cache is not enabled on WebView. So on WebView, NotRestoredReasons API should always say that the page is blocked from being restored from bfcache with the reason being something like “not supported”.
(Currently it reports null due to a bug)
https://github.com/rubberyuzu/bfcache-not-retored-reason/blob/main/HowToTest.md
False
https://bugs.chromium.org/p/chromium/issues/detail?id=1326344
https://launch.corp.google.com/launch/4200848
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues.
https://github.com/whatwg/html/pull/9360
https://chromestatus.com/feature/5684908759449600
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoGAzjUjzv3WmxcRpUSBgnA-AHQ05kh9gXc%2BQB8pRM6%2BfA%40mail.gmail.com Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHe391sAB2PdbEVw9uiSPFxTB_EYsRizcPpZ7-pg16O0A%40mail.gmail.com
Intent to Extend Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e698QcKZSthm%3Dz_4pi8cOzi4kfbx-AXveC%2BAKimUh-tMycA%40mail.gmail.com
This intent message was generated by Chrome Platform Status.
Contact emails
yu...@google.com, yu...@chromium.org, fer...@chromium.org
Explainer
https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
Specification
https://github.com/whatwg/html/pull/9360
Design docs
https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
Summary
NotRestoredReason API will report the list of reasons why a page is not served from BFcache in a frame tree structure, via PerformanceNavigationTiming API.
Blink component
TAG review
https://github.com/w3ctag/design-reviews/issues/739
TAG review status
Issues addressed
Risks
Interoperability and Compatibility
Gecko: Defer (https://github.com/mozilla/standards-positions/issues/766) Once issues (standardized reasons & unsalvageable documents), they would switch to positive.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHYpT3sxWV%2BEipL5NcNSWy8fOdDdAroucmNb%3DZvxJWRBA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXtkH6O82W%2BWm9ckCyYasSJt2cbs9VA4VZAmYhtivgj4g%40mail.gmail.com.
I think specifying these reasons is important. As noted in the linked issue, I think the end goal should be:
- Every reason that a browser ever emits, is found in a specification somewhere. (It doesn't have to be the HTML spec, e.g. the speech synthesis reason could live in the speech synthesis spec.)
- If browsers prevent bfcache restoration for a reason not found in a spec, it is always translated to a standardized reason such as "unknown".
This avoids the usual interop problems with vendor-specific extensions to the web platform, such as: no clear specification for what strings to use; no clear point at which the reason is added to the document's reasons list; etc. Although you claim these reasons are idiosyncratic to Chrome, that won't necessarily be the case; e.g. Firefox has unload handler as a reason, and I suspect most user agents have memory limitations or similar.
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/CAM0wra-P3NxELP28%3Dgh%3D3ROC35m8ijS_5RRcStyjFew1AXNyEg%40mail.gmail.com.
On Wed, 9 Aug 2023 at 12:01, Domenic Denicola <dom...@chromium.org> wrote:I think specifying these reasons is important. As noted in the linked issue, I think the end goal should be:
- Every reason that a browser ever emits, is found in a specification somewhere. (It doesn't have to be the HTML spec, e.g. the speech synthesis reason could live in the speech synthesis spec.)
There's no intrinsic reason for speech synthesis to block BFCache. It just happens that Chrome blocked it. There's no spec reason for unload to block BFCache, in fact the spec says that it doesn't.I think it's good for us to have agreed names, e.g. "unload-event-handler". Should we put into various specs "if an implementer chooses to block BFCache because X has been used, they should use the reason `Y`"?
- If browsers prevent bfcache restoration for a reason not found in a spec, it is always translated to a standardized reason such as "unknown".
This avoids the usual interop problems with vendor-specific extensions to the web platform, such as: no clear specification for what strings to use; no clear point at which the reason is added to the document's reasons list; etc. Although you claim these reasons are idiosyncratic to Chrome, that won't necessarily be the case; e.g. Firefox has unload handler as a reason, and I suspect most user agents have memory limitations or similar.Chrome has over 100 reasons. I'd say at least 50 of them are actionable such that you wouldn't want to lump them into an opaque "unknown" category.I do not relish the idea of updating 50 places in spec to insert a name to be used if you decide to block.How about maintaining a central list of reasons with low friction to add new reasons even if they are browser-specific? The cases where you must block should still be inline in spec (and also on the list),
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/43e32f0e-454e-4525-b317-cbe492e2f23bn%40chromium.org.
I am happy with the spec progress here and don't think it's a significant blocker for the Intent at this point.On the tests and implementation:
- I found performance-navigation-timing-navigation-failure.tentative.window.js which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
- I also found that the Chromium test directory is full of -expected.txt files, which seem to match up with the failures on wpt.fyi. Will those be addressed before shipping?
- I found a nonstandard toJSON() in NotRestoredReasonDetails in Chromium. Was the intent to specify that?
- Can you confirm that Chromium does not plan to ship any nonstandard not restored reason strings, beyond the specified "fetch", "navigation-failure", "parser-aborted", "websocket", "lock", and "masked"?
On Tue, 6 Feb 2024 at 15:13, Domenic Denicola <dom...@chromium.org> wrote:I am happy with the spec progress here and don't think it's a significant blocker for the Intent at this point.On the tests and implementation:
- I found performance-navigation-timing-navigation-failure.tentative.window.js which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
- I also found that the Chromium test directory is full of -expected.txt files, which seem to match up with the failures on wpt.fyi. Will those be addressed before shipping?
- I found a nonstandard toJSON() in NotRestoredReasonDetails in Chromium. Was the intent to specify that?
- Can you confirm that Chromium does not plan to ship any nonstandard not restored reason strings, beyond the specified "fetch", "navigation-failure", "parser-aborted", "websocket", "lock", and "masked"?
I don't know specifically what is there right now but I would expect that we will ship others. E.g. BroadcastChannel blocks BFCache on Chrome and Mozilla but not WebKit and there is currently disagreement. Why would it be better to show "masked" for that case?
On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly <fer...@google.com> wrote:On Tue, 6 Feb 2024 at 15:13, Domenic Denicola <dom...@chromium.org> wrote:I am happy with the spec progress here and don't think it's a significant blocker for the Intent at this point.On the tests and implementation:
- I found performance-navigation-timing-navigation-failure.tentative.window.js which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
- I also found that the Chromium test directory is full of -expected.txt files, which seem to match up with the failures on wpt.fyi. Will those be addressed before shipping?
- I found a nonstandard toJSON() in NotRestoredReasonDetails in Chromium. Was the intent to specify that?
- Can you confirm that Chromium does not plan to ship any nonstandard not restored reason strings, beyond the specified "fetch", "navigation-failure", "parser-aborted", "websocket", "lock", and "masked"?
I don't know specifically what is there right now but I would expect that we will ship others. E.g. BroadcastChannel blocks BFCache on Chrome and Mozilla but not WebKit and there is currently disagreement. Why would it be better to show "masked" for that case?The idea is to follow the standards and not ship nonstandard behavior. The current spec PR actually only allows sending "masked" in the cross-origin case, and doesn't allow sending it for BroadcastChannel. If the intention is to send some value in the BroadcastChannel case (which is this part of the spec) then that needs to be specified in the spec PR before shipping such a value in Chromium.
On Wed, 7 Feb 2024 at 12:26, Domenic Denicola <dom...@chromium.org> wrote:On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly <fer...@google.com> wrote:On Tue, 6 Feb 2024 at 15:13, Domenic Denicola <dom...@chromium.org> wrote:I am happy with the spec progress here and don't think it's a significant blocker for the Intent at this point.On the tests and implementation:
- I found performance-navigation-timing-navigation-failure.tentative.window.js which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
- I also found that the Chromium test directory is full of -expected.txt files, which seem to match up with the failures on wpt.fyi. Will those be addressed before shipping?
- I found a nonstandard toJSON() in NotRestoredReasonDetails in Chromium. Was the intent to specify that?
- Can you confirm that Chromium does not plan to ship any nonstandard not restored reason strings, beyond the specified "fetch", "navigation-failure", "parser-aborted", "websocket", "lock", and "masked"?
I don't know specifically what is there right now but I would expect that we will ship others. E.g. BroadcastChannel blocks BFCache on Chrome and Mozilla but not WebKit and there is currently disagreement. Why would it be better to show "masked" for that case?The idea is to follow the standards and not ship nonstandard behavior. The current spec PR actually only allows sending "masked" in the cross-origin case, and doesn't allow sending it for BroadcastChannel. If the intention is to send some value in the BroadcastChannel case (which is this part of the spec) then that needs to be specified in the spec PR before shipping such a value in Chromium.BFCaching is never required by spec. That means any browser can block BFCache at any time, for any reason and still be in spec.
I think what's missing is that said we would maintain a registry of reasons that were not in the spec so that when we block for unspecced reasons, we don't proliferate a bunch of undocumented names.I'm not sure how to express that in the spec,
Thanks Domenic for bringing up the concerns!
- I found performance-navigation-timing-navigation-failure.tentative.window.js which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
> Updated all the strings to match the spec-defined strings.
- I also found that the Chromium test directory is full of -expected.txt files, which seem to match up with the failures on wpt.fyi. Will those be addressed before shipping?
> Now the failing tests and the expected files are down to three.1) parser-abortedWe currently block with different reason("loading"), as we haven't worked on differentiating loading vs parser getting aborted.
2) navigation-failureWe do report "navigation-failure" when the document errors(implementation), but somehow the test only reports "http-status-not-ok" which is the chrome internal reason.
I will look into this more.3) weblockChrome currently blocks with another reason here (masked), so this failure will not go away. Maybe I should make WPTs to test if the expected reason exists in the list, instead of checking the complete list.
- I found a nonstandard toJSON() in NotRestoredReasonDetails in Chromium. Was the intent to specify that?
> Added this to the spec, thanks!
- Can you confirm that Chromium does not plan to ship any nonstandard not restored reason strings, beyond the specified "fetch", "navigation-failure", "parser-aborted", "websocket", "lock", and "masked"?
> We plan to add user-agent specific reasons to the spec in the may-block section.This is the draft PR (have't added the explanation for each reason yet).Is it okay to ship while we work on the follow-up PR?
On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo <yu...@google.com> wrote:Thanks Domenic for bringing up the concerns!
- I found performance-navigation-timing-navigation-failure.tentative.window.js which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
> Updated all the strings to match the spec-defined strings.
- I also found that the Chromium test directory is full of -expected.txt files, which seem to match up with the failures on wpt.fyi. Will those be addressed before shipping?
> Now the failing tests and the expected files are down to three.1) parser-abortedWe currently block with different reason("loading"), as we haven't worked on differentiating loading vs parser getting aborted.Note that "loading" is a nonstandard reason, so it would be bad to ship in that state. It should either be the correct reason ("parser-aborted") or the generi "masked" reason.
2) navigation-failureWe do report "navigation-failure" when the document errors(implementation), but somehow the test only reports "http-status-not-ok" which is the chrome internal reason.Similar to the above.
I will look into this more.3) weblockChrome currently blocks with another reason here (masked), so this failure will not go away. Maybe I should make WPTs to test if the expected reason exists in the list, instead of checking the complete list.Allowing an implementation to always do "masked" and pass the tests seems reasonable to me.
On Thu, 22 Feb 2024 at 16:32, Domenic Denicola <dom...@chromium.org> wrote:On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo <yu...@google.com> wrote:Thanks Domenic for bringing up the concerns!
- I found performance-navigation-timing-navigation-failure.tentative.window.js which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
> Updated all the strings to match the spec-defined strings.
- I also found that the Chromium test directory is full of -expected.txt files, which seem to match up with the failures on wpt.fyi. Will those be addressed before shipping?
> Now the failing tests and the expected files are down to three.1) parser-abortedWe currently block with different reason("loading"), as we haven't worked on differentiating loading vs parser getting aborted.Note that "loading" is a nonstandard reason, so it would be bad to ship in that state. It should either be the correct reason ("parser-aborted") or the generi "masked" reason."parser-aborted" is a reason that Chrome doesn't currently emit (it doesn't exist in the code). I'm not sure how we ended up speccing a reason that doesn't exist but I don't think we punt the entire NRR feature for another milestone for that.2) navigation-failureWe do report "navigation-failure" when the document errors(implementation), but somehow the test only reports "http-status-not-ok" which is the chrome internal reason.Similar to the above.I think this one we can just make change http-status-no-ok to navigation-failure.I will look into this more.3) weblockChrome currently blocks with another reason here (masked), so this failure will not go away. Maybe I should make WPTs to test if the expected reason exists in the list, instead of checking the complete list.Allowing an implementation to always do "masked" and pass the tests seems reasonable to me.I think this is a general issue with the testing. It should always be OK for a UA to have extra reasons, e.g. when we do add parser-aborted, loading will continue to show up. I guess we could add a hack to suppress loading if parser-aborted is present but really what we care about in these tests is that the specced reason is present in the specced case,
On Thu, Feb 22, 2024 at 6:01 PM Fergal Daly <fer...@google.com> wrote:On Thu, 22 Feb 2024 at 16:32, Domenic Denicola <dom...@chromium.org> wrote:On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo <yu...@google.com> wrote:Thanks Domenic for bringing up the concerns!
- I found performance-navigation-timing-navigation-failure.tentative.window.js which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
> Updated all the strings to match the spec-defined strings.
- I also found that the Chromium test directory is full of -expected.txt files, which seem to match up with the failures on wpt.fyi. Will those be addressed before shipping?
> Now the failing tests and the expected files are down to three.1) parser-abortedWe currently block with different reason("loading"), as we haven't worked on differentiating loading vs parser getting aborted.Note that "loading" is a nonstandard reason, so it would be bad to ship in that state. It should either be the correct reason ("parser-aborted") or the generi "masked" reason."parser-aborted" is a reason that Chrome doesn't currently emit (it doesn't exist in the code). I'm not sure how we ended up speccing a reason that doesn't exist but I don't think we punt the entire NRR feature for another milestone for that.2) navigation-failureWe do report "navigation-failure" when the document errors(implementation), but somehow the test only reports "http-status-not-ok" which is the chrome internal reason.Similar to the above.I think this one we can just make change http-status-no-ok to navigation-failure.I will look into this more.3) weblockChrome currently blocks with another reason here (masked), so this failure will not go away. Maybe I should make WPTs to test if the expected reason exists in the list, instead of checking the complete list.Allowing an implementation to always do "masked" and pass the tests seems reasonable to me.I think this is a general issue with the testing. It should always be OK for a UA to have extra reasons, e.g. when we do add parser-aborted, loading will continue to show up. I guess we could add a hack to suppress loading if parser-aborted is present but really what we care about in these tests is that the specced reason is present in the specced case,As we've discussed elsewhere on this thread, extra reasons are not OK; the APIs we ship need to be specified. "masked" is always OK though, per the spec.
LGTM1
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e913c96-1ebc-415c-9def-81695f5e74d4n%40chromium.org.
LGTM2
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67ea5933-8efb-43d8-abe1-6638415411da%40gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e913c96-1ebc-415c-9def-81695f5e74d4n%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
LGTM3
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e913c96-1ebc-415c-9def-81695f5e74d4n%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67ea5933-8efb-43d8-abe1-6638415411da%40gmail.com.
Thanks all for the replies.
I agree that I should have contacted Barry and his team to update the documentation first before starting the rollout process, sorry for the confusion.
Let me address Yoav's concerns/questions inline.
> `preventedBackForwardCache` going away (compared to the previously-OTed API shape), making it hard for developers to know if BFCache was prevented from being used. Can you help me understand what developers should do here?
The reason why `preventedBackForwardCache` was removed is that this bit of information can be inferred from `reasons`.
`preventedBackForwardCache` used to indicate whether or not the specific document has any blockers. Now you can check `reasons` instead. If `reasons` is empty, that document did not block bfcache, and if it contains any value, it blocked bfcache.
The only exception here is the “masked” case. The outermost main document will have “masked” in the `reasons` when cross-origin children are blocking.
Regarding “whether or not bfcache was used”, i.e. whether the entire page had any blockers, you can check the NotRestoredReasons value. NotRestoredReasons will return null if the page is successfully restored from bfcache, and it will be non-null if not.
As a developer, you can write something like this.
if (the most recent navigation was history navigation) {
if (NotRestoredReasons == null) {
// The page was restored from bfcache.
} else {
// The page was not restored from bfcache.
}
}
> Name-changes that are related to discussions on https://github.com/whatwg/html/pull/10154. Here better documentation can probably fix this.
- One thing I didn't fully internalize (but should have) is that ongoing PR discussion can result in name changes after we ship. How likely do you consider that scenario?
Yes, the names are going to change but unlike e.g. function names, there is no backward-compatibility risk with the names changing - no site's code depends on the names, they may be logged for debugging purposes. Names will be added/deleted as time goes on.
Changing the names a couple of milestones after launch is not ideal but there is very little benefit to anyone from holding back the API until the names are finalized.
> "masked" being used both for reasons that web developers can't do much about, as well as for cross-origin iframes, where we can't expose the reasons due to privacy and security considerations. Can developers distinguish those cases somehow? If so, how?
This reports the same value by design, in order to not expose cross-origin information at all, i.e. hide whether or not cross-origin iframes had any blockers. This is because the mere fact that cross-origin iframes could be privacy sensitive.
We discussed this point with Mozilla folks and they also preferred not to distinguish UA’s internal reasons vs cross-origin blockers.
This is unfortunate because as you say, cross-origin information can still be actionable for developers. We are proposing a workaround: Opt-in header for exposing cross-origin iframes info
(We proposed selecting one random cross-origin iframe and exposing its blocking status, but that was turned down by Mozilla folks.)
On 3/25/24 12:45 PM, Yuzu Saijo wrote:
Thanks all for the replies.
I agree that I should have contacted Barry and his team to update the documentation first before starting the rollout process, sorry for the confusion.
Let me address Yoav's concerns/questions inline.
> `preventedBackForwardCache` going away (compared to the previously-OTed API shape), making it hard for developers to know if BFCache was prevented from being used. Can you help me understand what developers should do here?
The reason why `preventedBackForwardCache` was removed is that this bit of information can be inferred from `reasons`.
`preventedBackForwardCache` used to indicate whether or not the specific document has any blockers. Now you can check `reasons` instead. If `reasons` is empty, that document did not block bfcache, and if it contains any value, it blocked bfcache.
The only exception here is the “masked” case. The outermost main document will have “masked” in the `reasons` when cross-origin children are blocking.
Regarding “whether or not bfcache was used”, i.e. whether the entire page had any blockers, you can check the NotRestoredReasons value. NotRestoredReasons will return null if the page is successfully restored from bfcache, and it will be non-null if not.
As a developer, you can write something like this.
if (the most recent navigation was history navigation) {
if (NotRestoredReasons == null) {
// The page was restored from bfcache.
} else {
// The page was not restored from bfcache.
}
}
> Name-changes that are related to discussions on https://github.com/whatwg/html/pull/10154. Here better documentation can probably fix this.
- One thing I didn't fully internalize (but should have) is that ongoing PR discussion can result in name changes after we ship. How likely do you consider that scenario?
Yes, the names are going to change but unlike e.g. function names, there is no backward-compatibility risk with the names changing - no site's code depends on the names, they may be logged for debugging purposes. Names will be added/deleted as time goes on.
FWIW, if something is exposed to script, there is always a backwards-compat risk to be considered, even if the intended usage is purely for debugging.
https://miketaylr.com/posts/2018/10/(native)-error-prototype-message.html
is one example of this
On 3/25/24 12:45 PM, Yuzu Saijo wrote:
Thanks all for the replies.
I agree that I should have contacted Barry and his team to update the documentation first before starting the rollout process, sorry for the confusion.
Let me address Yoav's concerns/questions inline.
> `preventedBackForwardCache` going away (compared to the previously-OTed API shape), making it hard for developers to know if BFCache was prevented from being used. Can you help me understand what developers should do here?
The reason why `preventedBackForwardCache` was removed is that this bit of information can be inferred from `reasons`.
`preventedBackForwardCache` used to indicate whether or not the specific document has any blockers. Now you can check `reasons` instead. If `reasons` is empty, that document did not block bfcache, and if it contains any value, it blocked bfcache.
The only exception here is the “masked” case. The outermost main document will have “masked” in the `reasons` when cross-origin children are blocking.
Regarding “whether or not bfcache was used”, i.e. whether the entire page had any blockers, you can check the NotRestoredReasons value. NotRestoredReasons will return null if the page is successfully restored from bfcache, and it will be non-null if not.
As a developer, you can write something like this.
if (the most recent navigation was history navigation) {
if (NotRestoredReasons == null) {
// The page was restored from bfcache.
} else {
// The page was not restored from bfcache.
}
}
> Name-changes that are related to discussions on https://github.com/whatwg/html/pull/10154. Here better documentation can probably fix this.
- One thing I didn't fully internalize (but should have) is that ongoing PR discussion can result in name changes after we ship. How likely do you consider that scenario?
Yes, the names are going to change but unlike e.g. function names, there is no backward-compatibility risk with the names changing - no site's code depends on the names, they may be logged for debugging purposes. Names will be added/deleted as time goes on.
FWIW, if something is exposed to script, there is always a backwards-compat risk to be considered, even if the intended usage is purely for debugging.
https://miketaylr.com/posts/2018/10/(native)-error-prototype-message.html is one example of this
Changing the names a couple of milestones after launch is not ideal but there is very little benefit to anyone from holding back the API until the names are finalized.
> "masked" being used both for reasons that web developers can't do much about, as well as for cross-origin iframes, where we can't expose the reasons due to privacy and security considerations. Can developers distinguish those cases somehow? If so, how?
This reports the same value by design, in order to not expose cross-origin information at all, i.e. hide whether or not cross-origin iframes had any blockers. This is because the mere fact that cross-origin iframes could be privacy sensitive.We discussed this point with Mozilla folks and they also preferred not to distinguish UA’s internal reasons vs cross-origin blockers.
This is unfortunate because as you say, cross-origin information can still be actionable for developers. We are proposing a workaround: Opt-in header for exposing cross-origin iframes info
(We proposed selecting one random cross-origin iframe and exposing its blocking status, but that was turned down by Mozilla folks.)
The way that such reliance can manifest itself is in developer-visible dashboards being broken. E.g. RUM providers can collect (the common) "unload-handler" and highlight it, and throw "unload-listener" to the unknown bucket.
That breakage won't be visible to users, but it could diminish the benefits of the feature and may result in developer frustration. It might be worthwhile to be upfront about that in the feature's documentation.