Closed Bug 141038 Opened 22 years ago Closed 21 years ago

OnStartURIOpen is no longer called for forms with non-standard URI schemes

Categories

(Core :: DOM: Core & HTML, defect, P3)

PowerPC
Mac System 9.x
defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: john, Assigned: darin.moz)

References

Details

(Keywords: topembed-, Whiteboard: [whitebox])

Attachments

(1 file)

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.
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.
Keywords: topembed+
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
Priority: -- → P3
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.
Whiteboard: [whitebox]
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
Closed: 21 years ago
Resolution: --- → FIXED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: