[Proto-Scripty] Re: observer ignored for submit buttons in IE 6?
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" wrote:
> Hi,
>
> > Is
> > there a way for submit() to function with > 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 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'
[Proto-Scripty] Re: observer ignored for submit buttons in IE 6?
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 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" 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 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
> > li
[Proto-Scripty] Re: observer ignored for submit buttons in IE 6?
Both of these work beautifully. I'm partial to he last method as I can
still include that in my .js file loaded in the head of the
document.
observing the whole page is what works. I tried observing the parent
div with poor results but I am betting that is because I'm loading the
script prior to the div being loaded. I see no reason why not to just
observe the document which will let me keep this code with my other
javascripts (unless there are implications here i'm not aware of).
even still it looks like a great solution to my problem.
/applaud
On May 22, 12:17 pm, Walter Lee Davis wrote:
> Oh, hey, maybe you should use a different method altogether:
>
> document.observe('click',function(evt){
> var elm = evt.element();
> if (elm.tagName == 'A' || elm.hasClassName('processing')){
> //magic here
> }
>
> }
>
> One observer for the whole page (or pick some DOM element closer to
> the rest of these elements, maybe a common parent DIV) and listen for
> the bubble going past.
>
> Walter
>
> On May 22, 2009, at 12:29 PM, ykaerflila wrote:
>
> > 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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: observer ignored for submit buttons in IE 6?
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 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
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Autocompleter isn't working
check a typo.your missing a "g" in there. I changed that along with the following and it works fine for me changed to On May 22, 5:47 am, MIGhunter wrote: > I bought "Practical Prototype and Script.aculo.us" and I'm going thru > the tutorial on autocompleters. It is really basic but doesn't work > for some reason. Wondering if anyone has any suggestions or has used > this before. You can see looking below that it is loading the > javascript elements. For some reason it is loading with > "autocomplete: off" If I change it to on in firebug, it still doesn't > work. Here is the code for the file: > [code] > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> > > > Chapter 12 > > type="text/javascript"""> script> >