Canceling a form submitted to an iframe target

[acoleman616]

Hello all,

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?

I realize that you normally cancel a submit with onsubmit(), but
that's not the case here since the submit is already in progress in
this case.

Thanks in advance for any help.

 

[David Mark]

Hello all,

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?

Yes. It can't be done. And why is a page reload a problem? If your
pages are lean enough, the user won't know the difference. The
typical Website today requires a reload every time the user clicks the
back (or forward) button. Weed those out first as browser navigate
far more often than they upload.

 

[Jorge]

(...)  The
typical Website today requires a reload every time the user clicks the
back (or forward) button. (...)

Not in current Safaris nor FireFoxes.

 

[rf]

Hello all,

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?

Your browser has a cancel button in its toolbar.

 

[David Mark]

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.

The problem is that most "major" libraries hang unload listeners on
the body for no reason, which requires documents to reload on
navigation (otherwise they'd be crippled as all of the listeners have
been detached). As we've discussed here, the listeners aren't the
problem and the real problem (circular references involving host
objects) is easily avoided at the design stage. Sound familiar?

The "solution" that was in vogue for a while was to try to cram sites
and applications into one document, thereby eliminating navigation
altogether. Of course, that short-circuits other things as well (e.g.
bookmarks), "requiring" further hacks, calls to standardize unneeded
events (e.g. hash change), etc.

It's a backwards strategy that discounts what browsers do well (and
what they were designed to do), focusing instead on what they do
poorly (and were never designed to do). Eventually, the whole idea of
applications running on top of documents in browsers will go by the
wayside (particularly since most of these apps are built on top of
scripts that can't even _read_ documents).

 

[David Mark]

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?

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.

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.

Well, it certainly should be (as Chrome would seem to have figured
out). How did that Safari-clone manage to break it?

The "problem with major libraries is somewhat bad, but not very bad.
It's also kind of getting better... slowly.

That's ridiculous. Not one of them comes close to smoothing out IE
oddities (ostensibly their most important task). It's way too late
for them anyway. And look at the "progress" being made in their
discussions. Are you kidding? They can't figure out problems from
the decade before last, let alone deal with the future (I've seen it
and it's murder).

They threw the game away back when there was actually a shred of
justification for their existence. Now they are pretty much
superfluous.

Latest jQuery (currently beta, IIRC) attaches "load" listener only when
`window.attachEvent` is present (and `window.addEventListener` is not).
Unload?

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.

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?

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.

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.

 

[David Mark]

IE?  It's had it since IE2, IIRC.  Did they lose it at some point?




Sure looks like they have it to me.  I'll check though.

They did break it. My pages load fast enough that it's hard to tell
sometimes. There's certainly no such ambiguity with the typical
library-happy designs.

Go here:-

http://www.hartkelaw.net/

Change the theme, navigate to another page (e.g. the Spanish version),
set the default theme back, click the back button and the other theme
should still be applied. It is in Safari, Opera and FF, but not in
Chrome. (!) Good thing they are going to fix _that_.

Appears IE lost it somewhere between 2 and 8 too. Whatever. They
definitely had it at one point as it's the browser I first noticed
doing it (some time in the mid-90's).

 

[Thomas 'PointedEars' Lahn]

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.

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.

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

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.


PointedEars
___________
¹ [de] <http://www.heise.de/newsticker/meldung/Firefox-ueberholt-in-
Deutschland-Microsofts-Internet-Explorer-873082.html>
² <http://en.wikipedia.org/wiki/List_of_countries_by_GDP_(nominal)>

 

[David Mark]

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.

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

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

 

[acoleman616]

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.  




But it's never necessary, save for applications that paint themselves
into that particular corner at the design stage.





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





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?

 

[David Mark]

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.

 

[Thomas 'PointedEars' Lahn]

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.

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.

Yes, I'm sure that was a slip of the keyboard.

IBTD


PointedEars

 

[David Mark]

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.

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

IBTD

Now how would you know? I imagine Kangax knows the difference between
the two.

 

[Matt Kruse]

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.

Matt Kruse

 

[Matt Kruse]

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.

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

Matt Kruse

 

[Asen Bozhilov]

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

Useless conclusion. The problem in the implementation of GC for host
objects in JScript. That is irrelevant with DOM API provided from IE.
Are you write scripts which run in WSH? There again you have host
objects, and they again leak.
David Mark is absolutely right. The real problem is in the head of
developers and the way of their design. Detection `isLeak` itself is
dummy strategy especially in environment which have garbage
collection.

 

[Thomas 'PointedEars' Lahn]

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

 

[David Mark]

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.

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

That's not true.

API.requireMimeTypeOverride

Set that and it won't use the non-ActiveX version.

 

[David Mark]

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.

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

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

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

 

[David Mark]

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.