Canceling a form submitted to an iframe target
in [JavaScript]
|
Prev: Workaround for IE6 select width cut off options' width
Next: FAQ Topic - How do I get a jsp/php variable into client-sidejavascript? (2010-01-06)
From: acoleman616 on 6 Jan 2010 07:00 On Jan 6, 3:26 am, David Mark <dmark.cins...(a)gmail.com> wrote: > On Jan 6, 3:11 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: > > > > > kangax wrote: > > > David Mark wrote: > > >> Jorge wrote: > > >>> David Mark wrote: > > >>>> (...) The > > >>>> typical Website today requires a reload every time the user clicks the > > >>>> back (or forward) button. (...) > > >>> Not in current Safaris nor FireFoxes. > > > >> You are very confused, Jorge (as usual). Virtually every major > > >> browser offers fast history navigation (and has for years). You just > > >> don't see it on the Web much due to poorly designed scripts. > > > > Actually no, in reality things are not as bad as you make them sound ;) > > > > First of all, as I'm sure you know, our favorite "browser" the one > > > with ~62% market share at the moment > > > (http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0) > > > has no fast history navigation whatsoever. > > > > Chrome, which has just became 3rd most-popular browser, has no fast > > > history either (although they're planning to add it in a near future; > > > there's a ticket somewhere in their bugtracker). > > > > That leaves us with Firefox (~25%), Safari (~4%) and Opera (~2%). So, > > > roughly, 30% of current browsers support fast history. > > > > I'm bringing this all up just to show that, unfortunately, fast history > > > is not as widely supported as it might seem. > > > JFTR: A recent market study has showed that Firefox has gained a market > > share of 45% in Germany¹, the fourth-largest economy after the USA, Japan, > > and China (according to 2008 IMF/World Bank/CIA figures²). > > > Regardless of numbers, though, fast history navigation is undoubtedly a > > useful feature that is going to be implemented sooner or later in the > > browsers that do not yet implement it. However, it also stands to reason > > that the more common Web applications become, the load/unload problem > > becomes more pressing, and solutions are going to be developed. > > But one of the most maddening misconceptions I come across is that Web > apps must use a single document. Such designs fail to leverage the > browsers' inherent proficiency at browsing. ;) > > > > > So I would take the conservative approach for the time being: Avoid that > > which leads to the necessity of adding `unload' listeners where possible, > > and properly detect the faulty DOM implementation where it cannot be > > avoided in order to add those listeners. > > But it's never necessary, save for applications that paint themselves > into that particular corner at the design stage. > > > > > > Latest jQuery (currently beta, IIRC) attaches "load" listener only when > > > `window.attachEvent` is present (and `window.addEventListener` is not). > > > It would probably be better if they used conditional comments, > > > Those are _not_ Conditional Comments, it is conditional _compilation_, .... > > Yes, I'm sure that was a slip of the keyboard. JFTR, Conditional > Comments are useful for the _occasional_ IE-specific style (but they > are frequently used as crutches). > > From the example site:- > > a.external { zoom:1 } > > That's it. Of course, it might seem mad to have a single rule style > sheet just for IE, but I find it handy in case I have to add more > later (apparently I never did for this one). > > > > > > as > > > Garrett does in APE: > > > > isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ > > > ... and it is utter nonsense in this context. As we had established > > already, the programming language has little or nothing to do with the user > > agent that provides the DOM API which exhibits this flaw. > > It's certainly a flawed strategy to detect the script engine version. > I'm surprised at Kangax. :) Interesting discussion that sprouted... In any case, I need to prevent the page load so that the heavily ajax- based web app will stay in its current state, and allow the user to see their uploaded file within a certain portion of the app immediately. I'm currently running the file upload form in a nyroModal (JQuery-based modal plugin) popup window. If the window is closed mid-upload, then the form submit is cancelled. Maybe I just need to find a way to reload the modal's content on the fly, thus cancelling the upload. Thoughts?
From: David Mark on 6 Jan 2010 07:57 On Jan 6, 7:00 am, acoleman616 <acoleman...(a)gmail.com> wrote: > On Jan 6, 3:26 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > On Jan 6, 3:11 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > > wrote: > > > > kangax wrote: > > > > David Mark wrote: > > > >> Jorge wrote: > > > >>> David Mark wrote: > > > >>>> (...) The > > > >>>> typical Website today requires a reload every time the user clicks the > > > >>>> back (or forward) button. (...) > > > >>> Not in current Safaris nor FireFoxes. > > > > >> You are very confused, Jorge (as usual). Virtually every major > > > >> browser offers fast history navigation (and has for years). You just > > > >> don't see it on the Web much due to poorly designed scripts. > > > > > Actually no, in reality things are not as bad as you make them sound ;) > > > > > First of all, as I'm sure you know, our favorite "browser" the one > > > > with ~62% market share at the moment > > > > (http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0) > > > > has no fast history navigation whatsoever. > > > > > Chrome, which has just became 3rd most-popular browser, has no fast > > > > history either (although they're planning to add it in a near future; > > > > there's a ticket somewhere in their bugtracker). > > > > > That leaves us with Firefox (~25%), Safari (~4%) and Opera (~2%). So, > > > > roughly, 30% of current browsers support fast history. > > > > > I'm bringing this all up just to show that, unfortunately, fast history > > > > is not as widely supported as it might seem. > > > > JFTR: A recent market study has showed that Firefox has gained a market > > > share of 45% in Germany¹, the fourth-largest economy after the USA, Japan, > > > and China (according to 2008 IMF/World Bank/CIA figures²). > > > > Regardless of numbers, though, fast history navigation is undoubtedly a > > > useful feature that is going to be implemented sooner or later in the > > > browsers that do not yet implement it. However, it also stands to reason > > > that the more common Web applications become, the load/unload problem > > > becomes more pressing, and solutions are going to be developed. > > > But one of the most maddening misconceptions I come across is that Web > > apps must use a single document. Such designs fail to leverage the > > browsers' inherent proficiency at browsing. ;) > > > > So I would take the conservative approach for the time being: Avoid that > > > which leads to the necessity of adding `unload' listeners where possible, > > > and properly detect the faulty DOM implementation where it cannot be > > > avoided in order to add those listeners. > > > But it's never necessary, save for applications that paint themselves > > into that particular corner at the design stage. > > > > > Latest jQuery (currently beta, IIRC) attaches "load" listener only when > > > > `window.attachEvent` is present (and `window.addEventListener` is not). > > > > It would probably be better if they used conditional comments, > > > > Those are _not_ Conditional Comments, it is conditional _compilation_, ... > > > Yes, I'm sure that was a slip of the keyboard. JFTR, Conditional > > Comments are useful for the _occasional_ IE-specific style (but they > > are frequently used as crutches). > > > From the example site:- > > > a.external { zoom:1 } > > > That's it. Of course, it might seem mad to have a single rule style > > sheet just for IE, but I find it handy in case I have to add more > > later (apparently I never did for this one). > > > > > as > > > > Garrett does in APE: > > > > > isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ > > > > ... and it is utter nonsense in this context. As we had established > > > already, the programming language has little or nothing to do with the user > > > agent that provides the DOM API which exhibits this flaw. > > > It's certainly a flawed strategy to detect the script engine version. > > I'm surprised at Kangax. :) > > Interesting discussion that sprouted... It's a rerun. :) > > In any case, I need to prevent the page load so that the heavily ajax- > based web app will stay in its current state, and allow the user to > see their uploaded file within a certain portion of the app > immediately. Preserving state is no problem. See my example. > I'm currently running the file upload form in a > nyroModal (JQuery-based modal plugin) popup window. Well, you are screwed then. They only recently took the time to copy my three-year-old object inference. ;) > If the window is > closed mid-upload, then the form submit is cancelled. Maybe I just > need to find a way to reload the modal's content on the fly, thus > cancelling the upload. Thoughts? You really can't do it that way. I promise.
From: Thomas 'PointedEars' Lahn on 6 Jan 2010 09:00 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> kangax wrote: > > [...] one of the most maddening misconceptions I come across is that Web > apps must use a single document. Such designs fail to leverage the > browsers' inherent proficiency at browsing. ;) I would not count them out so quickly. I think can be done properly (which includes in an accessible way) so that there is a benefit to many users as compared to conventional application design. >> So I would take the conservative approach for the time being: Avoid that >> which leads to the necessity of adding `unload' listeners where >> possible, and properly detect the faulty DOM implementation where it >> cannot be avoided in order to add those listeners. > > But it's never necessary, save for applications that paint themselves > into that particular corner at the design stage. I can think about one or two cases where it cannot be avoided, for example timeouts and intervals that should better be cleared then. >> > Latest jQuery (currently beta, IIRC) attaches "load" listener only >> > when `window.attachEvent` is present (and `window.addEventListener` >> > is not). It would probably be better if they used conditional >> > comments, >> >> Those are _not_ Conditional Comments, it is conditional _compilation_, >> ... > > Yes, I'm sure that was a slip of the keyboard. IBTD :) PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: David Mark on 6 Jan 2010 09:51 Thomas 'PointedEars' Lahn wrote: > David Mark wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> kangax wrote: >> [...] one of the most maddening misconceptions I come across is that Web >> apps must use a single document. Such designs fail to leverage the >> browsers' inherent proficiency at browsing. ;) > > I would not count them out so quickly. I think can be done properly (which > includes in an accessible way) so that there is a benefit to many users as > compared to conventional application design. I'm not saying that rich applications are impossible. I was building them for Intranets (usually IE only) last century. Just that cramming everything into one page (usually involving scripts loading dynamically) is a poor angle. > >>> So I would take the conservative approach for the time being: Avoid that >>> which leads to the necessity of adding `unload' listeners where >>> possible, and properly detect the faulty DOM implementation where it >>> cannot be avoided in order to add those listeners. >> But it's never necessary, save for applications that paint themselves >> into that particular corner at the design stage. > > I can think about one or two cases where it cannot be avoided, for example > timeouts and intervals that should better be cleared then. I get your drift, but why would it matter if the timers picked up where they left off? That's how I approach rotating ad banners, "yield managers" and the like (beats loading a hundred 1x1 images on each navigation). Speaking of that, I've noticed an annoying trend that most big sites stall (without any content visible) for 5-10 seconds (sometimes even longer) on each navigation. The worst offenders lock up the browser too (and occasionally bog down the entire OS), rev up the cooling fans, etc. Nothing more annoying than inert scrollbars induced by incompetent Web developers. I can just picture them testing on brand new PC's with nothing else running. :( Unless bandwidth is free these days, it seems like they are stupidly leaking money as well as memory. But I guess they think it is "cool." ;) > >>>> Latest jQuery (currently beta, IIRC) attaches "load" listener only >>>> when `window.attachEvent` is present (and `window.addEventListener` >>>> is not). It would probably be better if they used conditional >>>> comments, >>> Those are _not_ Conditional Comments, it is conditional _compilation_, >>> ... >> Yes, I'm sure that was a slip of the keyboard. > > IBTD :) > Now how would you know? I imagine Kangax knows the difference between the two.
From: kangax on 6 Jan 2010 11:52
On 1/6/10 1:57 AM, David Mark wrote: > On Jan 6, 12:19 am, kangax<kan...(a)gmail.com> wrote: >> On 1/5/10 8:54 PM, David Mark wrote: >> >>> On Jan 5, 8:35 pm, Jorge<jo...(a)jorgechamorro.com> wrote: >>>> On Jan 6, 2:29 am, David Mark<dmark.cins...(a)gmail.com> wrote: >> >>>>> (...) The >>>>> typical Website today requires a reload every time the user clicks the >>>>> back (or forward) button. (...) >> >>>> Not in current Safaris nor FireFoxes. >> >>> You are very confused, Jorge (as usual). Virtually every major >>> browser offers fast history navigation (and has for years). You just >>> don't see it on the Web much due to poorly designed scripts. >> >> Actually no, in reality things are not as bad as you make them sound ;) >> >> First of all, as I'm sure you know, our favorite "browser" � the one >> with ~62% market share at the moment >> (http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0) � >> has no fast history navigation whatsoever. > > IE? It's had it since IE2, IIRC. Did they lose it at some point? IE 6, 7, 8 had none, last time I checked. But we need to define fast history navigation first. I only checked execution of scripts (i.e. that navigating back/forward doesn't re-run them), and how unload listeners affect it. I haven't checked if request is sent to a server. > >> >> Chrome, which has just became 3rd most-popular browser, has no fast >> history either (although they're planning to add it in a near future; >> there's a ticket somewhere in their bugtracker). > > Sure looks like they have it to me. I'll check though. http://code.google.com/p/chromium/issues/detail?id=22291 [...] >> >> Latest jQuery (currently beta, IIRC) attaches "load" listener only when >> `window.attachEvent` is present (and `window.addEventListener` is not). > > Unload? Yes, of course :) > >> It would probably be better if they used conditional comments, as >> Garrett does in APE: >> >> isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ > > No, detecting the script engine version is not a good strategy and > never has been. Address the leak problem _directly_ by not creating > circular references that leak. ;) Yeah, but then you need to stamp elements with expandos. Or use ids, but that's a somewhat obtrusive approach. > >> >> Prototype.js attaches "unload" when `window.attachEvent` is present and >> `window.opera` (as an object with [[Class]] == "Opera") is not. Not a >> bad strategy, but probably not as efficient and future-proof as CC-based >> version. > > Why even bring them up? Have you seen my review of that code? Current Prototype.js codebase? What is there to see? Everyone knows about all of its flaws and legacy mistakes, and that a complete rewrite is in order. Did you actually spend time reviewing it? > >> >> I see that "My Library" adds unload when `attachEvent` is present, but >> not `addEventListener`; pretty much what jQuery does now. But I know >> that you would just ditch all this unload business altogether if you had >> to update things now. > > Yes, we've been over that many times. Back in 2007 I thought it was a > good idea (among other things). And the difference is that mine > doesn't _need_ to do that at all as it creates no circular references > on attaching listeners. ;) I would be really interested to see "My Library" cleaned up and brought up to speed. It has potential, but looks rather rough at the moment. > > And yes, I am going to yank that bit (or at least make it optional, > defaulting to off). > >> >> The real problem is current stable jQuery, which attaches unload >> unconditionally and so kills those 30% of browsers, capable of fast >> history navigation. > > Among many other things. It kills IE with ActiveX disabled, even > though IE has supported XHR without ActiveX for years. And, as we all > know, it hasn't fixed attr/removeAttr despite being handed the > solution in late 2007. Futility doesn't come any clearer than that. ActiveX problem is fixed in a trunk, AFAIR. -- kangax |