Canceling a form submitted to an iframe target [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: Thomas 'PointedEars' Lahn on 6 Jan 2010 17:47

kangax wrote:

> Thomas 'PointedEars' Lahn wrote:
>> 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.
>
> How would you detect faulty DOM implementation?

IIUC, the only faulty DOM implementation is the MSHTML DOM. There must be
properties that are available in this DOM but not in other DOMs. I do not
know if (in essence) `window.attachEvent && !document.addEventListener' (I
would not try `window.addEventListener' as `window' is not supposed to refer
to a Node implementation) is the final word on the subject, but it is a
start.

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>

From: David Mark on 6 Jan 2010 18:03

From: David Mark on 6 Jan 2010 18:20

On Jan 6, 11:52 am, kangax <kan...(a)gmail.com> wrote:
> 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.

No, you have to do nothing of the sort. We went over this last time.
If I were designing an event library from scratch, I know what I would
do. There was only one missing link in My Library (to avoid
expandos). A better design would look something like this:-

var myHandle = attachListener(el, fn, context); // Number

....

detachListener(el, myHandle);

Now, the typical library goof will retort that "that's not what people
want to use" or "that doesn't look cool". Well, it is what they want
to use if they want to be competent. And "coolness" doesn't really
enter into it when you are drowning in incompetence. ;)

>
>
>
> >> 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?

Yes. It was far worse than I remembered. It's got the same set of
functions over and over, one set for each browser they've heard of.
That's inconceivably bad strategy, but perhaps they thought _that_ was
"cool." I don't. :(

>
>
>
> >> 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.

The roughest part is the documentation. Granted there are parts of it
that were just slapped together or copied out of old projects. But
consider how many browsers it works with (BTW, I recently fixed a
couple of things for Safari 2.0) and how long it has moved forward,
virtually unattended. Then there is the ease with which you can
determine degradation paths. It also has a ton more features than the
"major" libraries, without relying on dubious plug-ins (e.g. the Flash
module is the best available). Overall, it's light years ahead of
things like Prototype and jQuery.

So what would you have me do to it? Non-capturing regular expressions
and such? If you have suggestions, post them here (and/or in the My
Library forum). I do requests.

>
>
>
> > 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.

Another three-year triumph. Go team! And when you think about it,
what does the trunk matter? That just means that a ton of people
would have to re-download the thing (assuming they can, which is very
iffy due to all of the other changes), re-test everything, etc. It's
no way to run a Website or application in the "Real World".
Businesses want as small a cost of ownership as possible, not never-
ending Alpha tests for some amateur's hobby. So the whole appeal of
"free" libraries has always been lost on me (and my clients). ;)

From: David Mark on 6 Jan 2010 18:20

On Jan 6, 1:21 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Jan 5, 7:11 pm, acoleman616 <acoleman...(a)gmail.com> wrote:
>
> > I'm currently having a dilemma. I'm using an iframe as a target to
> > handle a form submit to allow users to submit file uploads without
> > requiring a page reload. What I want to do is this: when the user
> > clicks the submit button, I want a "cancel" button to appear -
> > clicking that "cancel" button will then kill/cancel the form submit
> > currently in progress. Any thoughts?
>
> Can't you just change the url of the target iframe? That should stop
> any process currently submitting the file, should it not? You might
> have to handle the broken connection on the server side.
>

You'd never know if it got through or not. Cancel means cancel.

From: David Mark on 6 Jan 2010 18:30

On Jan 6, 1:28 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Jan 6, 10:52 am, kangax <kan...(a)gmail.com> wrote:
>
> > > Among many other things. It kills IE with ActiveX disabled, even
> > > though IE has supported XHR without ActiveX for years.
> > ActiveX problem is fixed in a trunk, AFAIR.
>
> Indeed, I thought David would be watching the jquery-dev list like
> usual, notice yesterday's thread, and trumpet in here how the change
> is long over-due and he was the one who got them to change it! Heh.

I certainly don't "watch" any jQuery lists. And I never trumpet
anything in here. It's more like you start talking about "progress"
with jQuery and I _respond_ that if I hadn't beaten certain salient
points (e.g. browser sniffing, typeof xyz == 'array', etc.) into them
for years, sometimes talking directly to them, they wouldn't have
known what was wrong or what to do. The browser sniffing is but one
example, but perhaps the most important (and most obvious). Go back
to the Fall of 2007 and notice how Resig vehemently denied everything
I said in my review of jQuery (centered on sniffing). Then remember
that _you_ went over there to their list and argued my points for days
(if not weeks). That thread must have been 100 posts at least. And
remember how Resig wanted to see "my cool library" and then I
published it two months later? It was less than a year later that
Resig announced that he had figured out browser sniffing was evil and
unnecessary and had the "code to prove it" (much of which looked
suspiciously like similar code in My Library). And that pattern has
repeated itself a few times since, sometimes successful (e.g.
ActiveX), sometimes semi-successful (e.g. that ridiculous SELECT
hack), sometimes futile (e.g. attr/removeAttr).

Now, who is following who?

>
> Interestingly, it looks like "My Library" will fail on local files in
> IE7. It's commented on, but not accounted for.
>

Wrong. See my last response.

First | Prev | Next | Last
Pages: 1 2 3 4 5 6 7 8
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)