Confirmed users
2,615
edits
No edit summary |
|||
Line 134: | Line 134: | ||
== Caveats / What We've Tried Before == | == Caveats / What We've Tried Before == | ||
* The old protocol handling dialog was a simple nsIPrompt which only allowed things to be handed off to the system default. The new dialog is essentially a cleanup and evolution of unknown content-type handler dialog for MIME-types. In a future version, the plan is to use this new dialog to replace that old one too. | * The old protocol handling dialog was a simple nsIPrompt which only allowed things to be handed off to the system default. The new dialog is essentially a cleanup and evolution of unknown content-type handler dialog for MIME-types. In a future version, the plan is to use this new dialog to replace that old one too. | ||
* In {{bug|380415}, the backend changes were originally done as a redirect on the nsExtProtocolChannel after AsyncOpen was called. This had some structural problems, so the code got pushed into the nsHandlerInfo::LaunchWithWebHandler where it switched to simply creating a new channel and sending it to the URI loader. Further refactoring pushed this into nsIWebHandlerApp.launchWithURI where it really belongs. | * In {{bug|380415}}, the backend changes were originally done as a redirect on the nsExtProtocolChannel after AsyncOpen was called. This had some structural problems, so the code got pushed into the nsHandlerInfo::LaunchWithWebHandler where it switched to simply creating a new channel and sending it to the URI loader. Further refactoring pushed this into nsIWebHandlerApp.launchWithURI where it really belongs. | ||
== References == | == References == |