How to handle URL schemes that are not understood during navigation #1446
Comments
|
I think Chrome cancels the navigation synchronously, and tries to find an external handler for the scheme asynchronously. We could probably change that to navigate to an error page if no handler is found. What web-visible implications are you concerned about? Iframe load events? |
|
I'm not really concerned either way. I just want a reasonable model in the specification that everyone implements the same way. I think what Chrome does might actually be more reasonable, as the Firefox way requires knowing supported protocols in advance. @bzbarsky thoughts? |
|
Why does the Firefox way (that is, treating it as a network error) require knowing supported protocols in advance? I don't think it does. Note that Firefox does NOT show a network error if we find an external application to handle the protocol, and I'm 99% sure we do that async. Certainly nothing prevents it being done async in theory. The Chrome way has the drawback that given |
|
Navigate synchronously invokes "abort the active document" at the moment and also decides synchronously whether to delay the load event and a couple of other things. It could be that all of those are wrong of course and are just as asynchronous as fetching the eventual resource. |
|
I would expect that in Firefox clicking a link aborts the active document whether the protocol is "known" or not. It sounds like it's the Chrome behavior that requires knowing up front whether the protocol is "known"... |
|
Note: I wasn't saying that Chrome's UX is perfect or even good. I think I agree with @bzbarsky that we should be showing an error page of some sort. I think we can either do that with our current implementation (e.g. if we don't find a handler, trigger a navigation to some benign endpoint) or by reworking the implementation to check first, then decide what to do with the request. Note also that navigation in Chrome is undergoing a lot of refactoring to both move responsibility for navigation to the browser process, and to remove all the synchronousness that prevents us from moving frames out of process. Now's a reasonably good time to change things, if there's need for a change. |
|
@mikewest if the folks working on that could communicate what is lacking in the current HTML Standard around navigation that would be great. I'm trying to refactor it while fixing issues in the process and the current state of things in the standard is rather messy. |
|
Okay, so I think that means that step 9 and step 12 need to be taken out of synchronous navigation path. Coupled with the fact that redirects do not actually jump back to the "fragments" step I think we can simplify navigation around those parts quite a bit. |
Why, exactly? |
|
Oh, I misremembered the step numbers. I think that's ok. We should check what UAs do in practice with things like clicking a mailto: link while a document is still loading and whether it stops the load or not. |
|
That is the result I get in Chrome (hard to reproduce in Firefox since |
|
Hmm. So Chrome stops the load on that testcase. Firefox does not, looks like. From a user experience perspective not stopping is vastly better, of course... on the other hand your example of protocol handlers implemented via navigating away entirely means the user experience is kinda sucky in somewhat unpredictable ways already. |
|
Note also that we could get that scheme as the result of a redirect. Arguably "aborting" shouldn't happen synchronously, but rather until we have enough information to make an informed decision, but it is probably too late for that. |
Redirect handling had the following issues that are now fixed: * /a navigating to /b which redirects to /a#test would not unload /a. * Headers set on the initial request were not preserved. * Redirects to javascript URLs would not result in an error. Fixes #314. * Location header was not parsed, and HTTP method was not changed where needed. Fixes #461. Another source of complexity was the "gone async" mechanism, which was used for two steps that could just as easily be factored out and had to be since they were run synchronously, but should not be. Changing that fixes #1446 which discusses the issue around unknown URL schemes in more detail.
Redirect handling had the following issues that are now fixed: * /a navigating to /b which redirects to /a#test would not unload /a. * Headers set on the initial request were not preserved. * Redirects to javascript URLs would not result in an error. Fixes #314. * Location header was not parsed, and HTTP method was not changed where needed. Fixes #461. Another source of complexity was the "gone async" mechanism, which was used for two steps that could just as easily be factored out and had to be since they were run synchronously, but should not be. Changing that fixes #1446 which discusses the issue around unknown URL schemes in more detail.
|
#1476 attempts to fix this. |
Redirect handling had the following issues that are now fixed: * /a navigating to /b which redirects to /a#test would not unload /a. * Headers set on the initial request were not preserved. * Redirects to javascript URLs would not result in an error. Fixes whatwg#314. * Location header was not parsed, and HTTP method was not changed where needed. Fixes whatwg#461. Another source of complexity was the "gone async" mechanism, which was used for two steps that could just as easily be factored out and had to be since they were run synchronously, but should not be. Changing that fixes whatwg#1446 which discusses the issue around unknown URL schemes in more detail. multipart/x-mixed-replace no longer invokes the navigate algorithm halfway through, but instead invokes a dedicated algorithm.
Chrome simply terminates navigation synchronously. Firefox displays the equivalent of a "network error". @mikewest, @smaug----?
HTML currently sides with Firefox, though does so in a way that does not delay the load event and such. I believe that also matches Firefox, but it seems rather silly to do that?
The text was updated successfully, but these errors were encountered: