Remove fallbackUrl from explainer

[w3c]

Remove fallbackUrl from explainer

[rsolomakhin]

We never implemented fallbackUrl. None of the origin trials have used it and yet the results are positive. For initial version of the spec, it would make sense to remove it. If a strong use case comes emerges, then we can reconsider for future versions.

[tblachowicz]

I think there is value in supporting the fallbackUrl. My impression was that the browser would open the fallbackUrl in the modal dialog window in 1PC. This is clearly the benefit over the redirection, IFrame, or generic pop-up window.

[tblachowicz]

OK. I understand Chrome has not implemented it. However, the fact that the feature has not been used in any of the original trials does not mean it isn't a useful feature.

I do have my doubts if support of the fallbackUrl should be part of the SPC API, but I wouldn't throw it away at this stage. There had been merit in the idea originally and I believe there are some use-cases over and beyond the original trials that would support fallbackUrl as a feature.

I suggest adding the issue to the agenda to discuss with the TF.

[stephenmcgruer]

I do have my doubts if support of the fallbackUrl should be part of the SPC API, but I wouldn't throw it away at this stage.

I do not consider removing something from the explainer to be throwing it away, nor are we making any statement of the usefulness other than "we haven't heard any concrete reason to have it yet". A future spec (or spec revision) could add or reintroduce any concept including fallbackUrl if there is a concrete use-case identified. The explainer however should not (and cannot) exhaustively capture every possible extension idea - it is a MVP description of one possible solution for SPC.

Furthermore, the inclusion of fallbackUrl was causing confusion. We have had questions from partners who are confused as to what they're meant to put there and why it is required by the API.

I suggest adding the issue to the agenda to discuss with the TF.

I personally do not consider discussing this removal a good use of time for the TF, and would rather see a concrete proposal for having fallbackUrl as part of SPC first written up in an issue. We can then discuss that issue and bring that issue to the TF for resolution if necessary. That said, if you want to propose this for the agenda I'm of course not going to block - cc @ianbjacobs

[tblachowicz]

I do not consider removing something from the explainer to be throwing it away, nor are we making any statement of the usefulness other than "we haven't heard any concrete reason to have it yet". A future spec (or spec revision) could add or reintroduce any concept including fallbackUrl if there is a concrete use-case identified. The explainer however should not (and cannot) exhaustively capture every possible extension idea - it is a MVP description of one possible solution for SPC.

I take your point.

I suggest adding the issue to the agenda to discuss with the TF.

I personally do not consider discussing this removal a good use of time for the TF, and would rather see a concrete proposal for having fallbackUrl as part of SPC first written up in an issue. We can then discuss that issue and bring that issue to the TF for resolution if necessary. That said, if you want to propose this for the agenda I'm of course not going to block - cc @ianbjacobs

Perhaps I was not clear enough. What I had in mind was discussing the fallbackUrl feature by the TF at some point in time, not discussing the removal of the fallbackUrl from the explainer.

[stephenmcgruer]

Perhaps I was not clear enough. What I had in mind was discussing the fallbackUrl feature by the TF at some point in time, not discussing the removal of the fallbackUrl from the explainer.

Ah, I see. Yes, I think that's a great agenda item for the TF at some point :)

[ianbjacobs]

@tblachowicz,

Would you be willing to raise a new issue on fallback flows with a use case or two that you would like us to discuss? We could close this issue and use the new one as the basis for task force discussion.

I mention "fallback flows" instead of "fallback URL" to avoid describing the solution.

Ian

[stephenmcgruer]

fallbackUrl has been removed from Chrome's IDL file in 92.0.4491.0 . Users of SPC don't need to make any change, as passing non-existent members to a dictionary in WebIDL is valid, but after M92 is in Stable (approximately August) they may wish to clean up their code to not pass it.

[ianbjacobs]

@stephenmcgruer, can we close this issue?

[stephenmcgruer]

Apologies for the delay in responding, I was OOO.

I was going to hold this issue open until M92 is stable (which is a little sooner than I realized; late July rather than August), and then send a follow-up PR to remove fallbackUrl entirely from the explainer (and spec, if we have one then). This is because until M92 is stable, developers do still need to specify something for fallbackUrl, as it's required (though unused) in M91 and earlier.

[ianbjacobs]

Hi @stephenmcgruer,
I think M92 is available; can action be taken here?

Also, if there is no longer a fallbackURL, I think we can close issue #4.