Opened 17 years ago

Closed 17 years ago

#7 closed defect (fixed)

bind() behavior with formNode + url (+ method) not well defined

Reported by: anonymous Owned by: alex
Priority: high Milestone:
Component: General Version:
Keywords: Cc: [email protected]
Blocked By: Blocking:


In trying to work with the form handling features of dojo, I have a snippet that works fine under Firefox but fails under IE 6.

Heres the code snippet:

  function divChange() {
    var divToChange = document.getElementById("directoryInner");
    var inputForm = document.getElementById("directorySearch");{
      url: "/tools/directory_inner.jsp",
      load: function(type, data, evt){
        divToChange.innerHTML = data;
      error: function(type, error){
        alert("Error: " + error.message);
      mimetype: "text/plain",
      formNode: inputForm

The form has a button that calls 'divChange()' and the form has an onSubmit="divChange(); return false;"

As mentioned on Firefox this works. On MS-IE 6, the request seems to generate a "sampleTransport Error: 404 Not Found". When I look at the request on the server I see a request to "/tools/[object]?search=foo", which appears as if the 'url' parameter is not in a string format.

Change History (7)

comment:1 Changed 17 years ago by anonymous

It appears that the intention was to change the url if the formNode has an "action" parameter. Heres where the problem occurs.


	url = kwArgs.formNode.getAttribute("action");

Under Internet Explorer this conditional is being entered whether an "action" parameter exists or not. In either case this seems to come back as an object rather than a string, which breaks the XMLHTTPRequest.

I'm not sure how to fix this, but for now I've just commented out this block.

comment:2 Changed 17 years ago by schontz at gmail

severity: normalmajor
Summary: Potential bug with MS-IE 6?bind() behavior with formNode + url (+ method) not well defined

I've run into issues setting method and url when I supply a formNode in Firefox and IE. I don't believe that the behavior in that situation is well-defined, but it needs to be. Either 1) ignore those fields when a formNode is supplied or 2) ignore the formNode action + method when the fields are supplied. I think option 2 is less confusing ("I set the URL, but nothing happened!"), but I kind of like option 1 better ("I just give it a form and it performs magic!"). Although, forms are kind of "broken" in the sense that they can only have one action, so the replace-with-my-url option 1 sounds real nice.

Choices, choices.

comment:3 Changed 17 years ago by alex

Priority: normalhigh
Status: newassigned

comment:4 Changed 17 years ago by alex

Cc: [email protected] added

comment:5 Changed 17 years ago by ringmaster at midnightcircus

I would like to see option 2 implemented. It would be very beneficial to specify an alternate posting URL so that the returned value could be something more appropriate for client-side processing. If a url or method parameter is supplied, those supercede the ones given by the form. If one is missing, the form value is used instead. That way, you can just specify a form and have it work, or you can provide a custom handler and method. Very flexible, but simple.

comment:6 Changed 17 years ago by [email protected]

I think I agree that a passed URL should over-ride an implicitly defined one (on the form node).

I'll work up a patch.

comment:7 Changed 17 years ago by alex

Resolution: fixed
Status: assignedclosed

(In [562]) merging patch from Owen Winkler and a fix for bug # 7

fixes #7

Note: See TracTickets for help on using tickets.