I added the line
elm.up('form').submit();
after playing with this script in a simple test page I setup.  I
created a simple html document with just a form w/ 1 field and 2
submit buttons.  In IE6 regardless the form will not submit if you
remove the submit() line.  disabling the submit button on a click
stops the form cold. Since you clicked the button to fire it off I was
counting on the submit=submit being set in the post body I never got
around to testing that because, well when I put this in the app I
found the name="submit" issue stopping me from continuing the submit
after IE stops it.

On May 27, 4:48 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> Hi,
>
> > Is
> > there a way for submit() to function with <input name="submit"
> > type="submit" />  because that is so ingrained into the html and back
> > end code that if I cannot I need to re approach a different way in
> > javascript.
>
> The problem (as I'm sure you figured out) is that IE puts properties
> (well, property-like-things) on the form object for each of the form
> fields using their name, and so the field "submit" is masking the
> form's "submit" property, which normally refers to the submit function
> for the form.
>
> First, off, a question on that code:  Why are you submitting the form
> programatically?  The button that was pressed is a submit button, if
> you don't do anything and if the form's 'submit' event isn't
> cancelled, the form will get submitted.  So...do you really need to do
> this at all?  Can't you just remove that last line and let the browser
> do its thing?  Also, note that if you submit the form via form.submit
> () (somehow), it will not have a 'submit' field submitted with it,
> which you've said the server-side code is expecting to see.  You'd
> have to add that (somehow).  All of which adds up to the need for a
> rethink, I suspect.
>
> Assuming you really do need to do this programatically:
>
> If this were anything other than IE, I'd say you could grab the
> function reference from the form's prototype and then apply it to the
> instance via Function#apply, neatly bypassing the form's own submit
> property, which has been hijacked.  Sadly, though, this is IE and the
> form element won't have the 'constructor' property, etc., because that
> would be far too rational.  You can't even grab the submit function
> from another form element (perhaps creating it on the fly) because
> IE's submit function doesn't have the Function#call and Function#apply
> methods, because it's not really a JavaScript function, it just plays
> one on TV.  And don't even think about deleting the 'submit' property
> from the instance so it stops masking the prototypical submit
> property; it's not really a property and you can't delete it.
>
> *sigh*
>
> So, three suggestions (other than, again, letting the browser submit
> the form itself):
>
> 1. Having a form element named "submit" is a Bad Idea and so a global
> search-and-replace expedition through the code may well be justified.
>
> 2. Barring that, you could use Prototype's Form#request to serialize
> the form and submit it via Ajax.Request, but that won't do everything
> a real form submit would do (e.g., replacing the page with the
> result).
>
> 3. If you _remove_ the button, the form's 'submit' property will
> revert back to referencing the function:
>
>     var form = elm.up('form');
>     elm.remove();
>     form.submit();
>
> ...but again, the submitted form won't have a 'submit' field in it.
>
> FWIW,
> --
> T.J. Crowder
> tj / crowder software / com
> Independent Software Engineer, consulting services available
>
> On May 26, 6:30 pm, ykaerflila <ykaerfl...@gmail.com> wrote:
>
> > sorry its taken me so long to get back in here and reply but I've been
> > fighting with my own ignorance heh.   I got so caught up in the
> > initial problem in here I forgot details about the extra logic I
> > needed, to do exactly what I want when the buttons are clicked.
>
> > I am disabling each and every input button on the page when one is
> > clicked.  When i added this code it was stopping the form from
> > submitting ( in ie6) it just took waisting several hours scratching me
> > head to remember that disabling submit buttons on click stops form
> > submission in IE(not sure about newer IE versions but it does this in
> > 6). Initally i was just using alert("clicked"); to troubleshoot
> > problem.  The actual code w/ logic now looks like
>
> > document.observe('click',function(evt){
> >   var elm = evt.element();
> >   if (elm.tagName == 'A' ){
> >     if (elm.getAttribute('href') != "#"){
> >       $('processing_gif').show()
> >     };
> >   }else if( elm.getAttribute("type") == 'submit' ){
> >     $('processing_gif').show();
> >     $$('input[type="submit"]').invoke('disable');
> >     elm.up('form').submit();
> >   }
>
> > } );
>
> > as you can see I'm handling the buttons and anchors differently.
> > Anchors are simply showing the animated spinner. while buttons show
> > the spinner and disable the rest of the buttons on that page. the
> > current problem is elm.up('form').submit(); is failing.  I discovered
> > it is because when these pages were initially written the input
> > buttons  have the type, value, and, name all set to submit.  which is
> > bombing submit().  If I change the name of the submit buttons
> > everything functions correctly.  Which leads me to the question.  Is
> > there a way for submit() to function with <input name="submit"
> > type="submit" />  because that is so ingrained into the html and back
> > end code that if I cannot I need to re approach a different way in
> > javascript.
>
> > Thanks again for all of your help.
>
> > On May 23, 2:59 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>
> > > Hi,
>
> > > > This does bring into question in my mind the order of onclick vs.
> > > > forum submission.  right now the 2 buttons i've been testing this with
>
> > > FWIW, I think the question you have to ask is why you're seeing this
> > > behavior but I'm not, and moreover, I haven't heard of it either --
> > > this suggests there's something very strange going on specific to your
> > > page.  At first I thought it was form submission too, but a quick
> > > check with IE6 showed that I got the alert before the form was
> > > submitted.  Here's the page I was testing with.[1]  As shown there, it
> > > will alert and then submit the form to blank.html, but there's some
> > > commented-out code to prevent the form submission.  Either way, I got
> > > the click alert.
>
> > > [1]http://pastie.org/487167
>
> > > HTH,
> > > --
> > > T.J. Crowder
> > > tj / crowder software / com
> > > Independent Software Engineer, consulting services available
>
> > > On May 22, 5:29 pm, ykaerflila <ykaerfl...@gmail.com> wrote:
>
> > > > well its not a version issue. I just copied the js files from to
> > > > another to confirm and the issue still persists with dom:loaded
>
> > > > as far as timing goes the submit buttons I'm observing for clicks are
> > > > static HTML elements.  I had been assuming all static HTML is loaded
> > > > upon dom:load (but admittedly I've never looked to confirm that it
> > > > just seem to make sense =)
>
> > > > This does bring into question in my mind the order of onclick vs.
> > > > forum submission.  right now the 2 buttons i've been testing this with
> > > > submit a form when clicked.  In FF I see the alert window telling me
> > > > the 'click' observer is firing off before the form is getting
> > > > submitted.  in IE6 I see nothing so is there a possibility that the
> > > > form is actually getting submitted before the 'click' observer fires
> > > > off?
>
> > > > Then again maybe I'm going about all of this the wrong way.  what I'm
> > > > shooting for here is to show a loading spinner on the page on each
> > > > click of links and selected input buttons.  hence the $$
> > > > ('a','.processing'). The site I'm working on has some AJAX and each
> > > > AJAX request shows/hides a processing spinner. some of the bigger page
> > > > requests and during peak times users are multi clicking buttons
> > > > because they are looking for the AJAX processing spinner(even on non
> > > > ajax requests) rather than watching the IE window and thinking nothing
> > > > is going on.  so what i sat out to do was simply show the processing
> > > > spinner via each click of an anchor tag or button which has
> > > > the .processing class attached to it.  all it needs to do is .show()
> > > > the spinner div onclick but i'd rather not have to go through each
> > > > link and button to add onclick="$('spinner').show()".  IE 6 is
> > > > important because this runs in XPe terminals which of course are all
> > > > running IE6 =)
>
> > > > On May 22, 9:53 am, Walter Lee Davis <wa...@wdstudio.com> wrote:
>
> > > > > You may find that you are using the same version on both sites, which
> > > > > means that my solution fixed the problem, but not for the reason I
> > > > > thought.
>
> > > > > There may be a timing/latency issue somewhere else in your code that
> > > > > is resolved by the DOM being completely settled (onload is very late
> > > > > in the game, the page is already visible in its entirety in the
> > > > > browser).
>
> > > > > You might want to look through for some cases where you expect a thing
> > > > > to be there -- if you act on any element blindly assuming its
> > > > > existence -- and see if wrapping that up in a condition makes the site
> > > > > work again under dom:loaded.
>
> > > > > It's just a hunch, mind you.
>
> > > > > Walter
>
> > > > > On May 22, 2009, at 9:58 AM, ykaerflila wrote:
>
> > > > > > That worked like a champ.  I changed
> > > > > > document.observe("dom:loaded", code.launch );
> > > > > > to
> > > > > > Event.observe(window,'load', function(event){
> > > > > >    $$('.processing').invoke('observe', 'click', function(ev) {
> > > > > >            alert('clicked');
> > > > > >    });
> > > > > > });
>
> > > > > > Now everything is working as expected.  I'm using the same
> > > > > > document.observer("dom:loaded"... in another script as I mentioned
> > > > > > which is working properly( its only being used on checkboxes and 
> > > > > > divs)
> > > > > > so now I'm curious heh. I was pretty sure I used the exact same
> > > > > > version of prototype on the 2 sites, guess I'll go double check just
> > > > > > to see.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to