1.29 KB, application/octet-stream
For our embedding application, we embed URIs with a non-standard scheme in some of our HTML content. These URIs provide a way to control the embedding application's behavior from HTML content. We have been detecting user clicks of these "control" links by installing an nsIURIContentListener and watching the URI load attempts in OnStartURIOpen. This is very handy for us as we can easily detect the scheme is ours, handle the command and then simply return an abort value in _retval. In Mozilla versions 0.9.8 or earlier this method worked fine. I just updated our project to work with 1.0.0rc1 and discovered that although OnStartURIOpen is still called for clicked hrefs with this non-standard scheme, it is no longer being called for the submission of forms which use METHOD="GET". I'll attach a sample HTML file with non-standard schemes for both a GET action form and an href link. An interesting side note, the href link when clicked in Mozilla will yield an error dialog. The form action will not.
Created attachment 81572 [details] Sample HTML file with non-standard URI scheme for form action and href I was mistaken above, after further testing I discover that the href with a non-standard does not generate an error dialog in 1.0.0.
16 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
After building a debug version of Mozilla and doing some digging, I see that the problem is occurring in nsHTMLFormElement::GetActionURL when the call to NS_NewURI fails since there is no installed protocol handler for the scheme specified by the actionURL. Of interest, nsGenericElement::TriggerLink which is called for html links ignores the result value of its call to NS_NewURI. It does return the error, without acting on it, all the way back out to PresShell::HandleEventWithTarget which also ignores the error code. It looks like I may be able to work around this problem by registering dummy protocol handlers for the non-standard schemes that we use. Early on (pre 0.9.x) adding protocol handlers to get this behavior was required, even for href links. Somewhere along the way though, the requirement was removed, so I removed the handlers from my project. I will add a protocol handler to my project and see if that actually does work around the problem.
So should every possible submit call OnStartURIOpen() ?? I don't get it--if NS_NewURI() fails we are not going to try to submit. It makes sense to my little brain not to call OnStartURIOpen() if we don't try to actually open the URI on the network. If that's the case then do we need to do this when the submit fails because the user clicked the submit button twice in rapid succession? (In that case we prevent the second submit from occurring at all.) It *should* generate an error dialog, though. Submission has far fewer errors than it should.
In my case, as an embedding application, I'm looking to for a method to intercept the click on the submit button before the actionURL is actually acted upon. This is the previous behavior for form submission and the one We currently get with OnStartURIOpen when a user triggers a link. The embedding application needs the opportunity to look at the actionURL and determine if it wants to either handle it, deny it, or let Mozilla try to handle it. With OnStartURIOpen, the embedding application can simply return an abort value in retVal if they either want to handle the click or don't want the submission to occur for some other reason, so it's kind of the natural hook point. I'm just now resurrecting my old protocol code and trying to bring it up to date. Maybe I can get the behavior I'm looking for from them, instead of, or in combination with, OnStartURIOpen In answer to your question about clicking Submit twice in rapid succession, I'd only want OnStartURIOpen called once, like the normal behavior if the URI had a protocol handler.
Oh. You want to be a form submit observer, OnStartURIOpen is not what you are looking for here. The form reserves the right not to open the URI if it cannot do so. http://lxr.mozilla.org/seamonkey/source/layout/html/forms/public/nsIFormSubmitObserver.h Form submit observers add themselves as observers to the form, and then whenever a submit happens for any reason based on the URL and form. There is another interface (which *will change* after 1.0, be warned!) called nsIFormProcessor, that allows you even deeper control over what is being sent. I haven't done a full review of the nsIFormSubmitObserver interface, but it seems reasonable that it will not change.
I'm okay with adding an nsIFormSubmitObserver, however from what I can see, I'll still have to add dummy protocol handlers. It appears that NotifySubmitObservers is still not called if the GetActionURL fails.
True enough, but that makes sense because the observer takes a URI, and the URI cannot be created if there is no handler for that type of URI. Come to think, OnStartURIOpen() takes a URI too. Do you remember offhand what input you used to receive in the OnStartURIOpen() parameter with a non-standard URI? Was it null or something?
Actually, the nsIURI that comes into OnStartURIOpen appears to be filled out enough for my needs at least. Each URI that comes into my OnStartURIOpen handler is examined by getting the string representation of the URI with GetSpec. We then look at the scheme portion to determine if it is something our application should handle. If the URI a standard scheme, it is passed through a set of filters that may change the URI via SetSpec or abort the load. If the URI is an application specific scheme, one of two things happens: 1) the load is aborted. or 2) The URI is changed via SetScheme and SetPath and the load is allowed. Due to the way the feature is designed in our application, the above modifying the URI on the fly only happens with links, not with form actions.
Hrm, links can build non-standard URIs? I will investigate.
I do not understand why LinkClick is able to give you a URI for a non-supported protocol. I just explicitly checked the return value of NS_NewURI in these cases, and it is null. The system does not seem to support it at all. I am told darin rewrote the URI parser after 0.9.8 specifically to do this behavior. I think you really do need to add protocol handlers for the special URIs you support. darin, assigning to you for comment. I strongly suspect this is RESOLVED/INVALID.
Assignee: jkeiser → darin
I'm running a debug build (built with a fresh pull from the MOZILLA_1_0_0_BRANCH two nights ago) right now looking at it working for links. Granted, it won't actually load anything. It's not supposed to. It does, however, make it through the process far enough to generate a call to OnStartURIOpen for my content listener. This works for links due to the "problem" I noted above (though it's difficult to read due to the lack of carriage returns. sorry.) "Of interest, nsGenericElement::TriggerLink which is called for html links ignores the result value of its call to NS_NewURI. It does return the error without acting on it, [the error is returned] all the way back out to PresShell::HandleEventWithTarget which also ignores the error code." In other news, I have now created a protocol handler for the scheme that is being used in the form action, and it does fix the problem such that OnStartURIOpen is now called for form submission. In my application, generating protocol handlers is kind of a pain, since the schemes we use are configurable and there may be several. It'll be easier once I figure out how to register the protocol handlers at runtime rather than as part of an auto-registered component DLL. I grant you, my application may be rather unique in its needs. In general, though, I guess the behavior of Mozilla should be consistent. If a protocol handler is required for a form action URIs, then it should be for a link. Or vice versa.
I totally agree that the behavior should be consistent. I am still puzzled by link's apparent ability to create a URI for a protocol handler which does not exist. Let us see what darin has to say.
the unknown protocol handler is usually invoked when a builtin protocol handler does not exist. this allows us to hook into OS specific URL services. i'm not too familiar with the unknown protocol handler code... but maybe it is related.
John, do you by any chance register your protocol handler stuff with Internet Config? If you do, then we'd find an external protocol handler for the protocol....
We presently don't register any of the protocols with Internet Config. They are all maintained internally and are only valid for our application when accessed from our application.
mass futuring of untargeted bugs
Target Milestone: --- → Future
setting (some) priority to get it of the list.
This should be fixed once NS_NewURI always succeeds... I'm hoping to get to it in the next week or so.
Depends on: 176904
John, could you possibly retest this with a 2002-11-20 or newer build? This should be fixed now that bug 176904 is checked in....
I'm a bit tied up, but will likely do a pull and build before the end of the week. I'll post back a report as soon as I can.
John, any luck with testing this?
Discussed in topembed bug triage. Minusing.
Keywords: topembed+ → topembed-
This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".
I'm marking this fixed, since according to code inspection bug 176904 fixed it. Please reopen if this is still an issue.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.