Canceling a form submitted to an iframe target
acoleman616
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
Not in current Safaris nor FireFoxes.
--
Jorge.
rf
"acoleman616" <acole...@gmail.com> wrote in message
news:58910f54-5100-466a...@s31g2000yqs.googlegroups.com...
> 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
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). ;)
kangax
> On Jan 5, 8:35 pm, Jorge<jo...@jorgechamorro.com> wrote:
>> On Jan 6, 2:29 am, David Mark<dmark.cins...@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.
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.
>
> 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 "problem with major libraries is somewhat bad, but not very bad.
It's also kind of getting better... slowly.
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, as
Garrett does in APE:
isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/
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.
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.
The real problem is current stable jQuery, which attaches unload
unconditionally and so kills those 30% of browsers, capable of fast
history navigation.
[...]
--
kangax
David Mark
> On 1/5/10 8:54 PM, David Mark wrote:
>
> > On Jan 5, 8:35 pm, Jorge<jo...@jorgechamorro.com> wrote:
> >> On Jan 6, 2:29 am, David Mark<dmark.cins...@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 ;)
>
> with ~62% market share at the moment
> 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 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 "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
> On Jan 6, 12:19 am, kangax <kan...@gmail.com> wrote:
>
>
>
> > On 1/5/10 8:54 PM, David Mark wrote:
>
> > > On Jan 5, 8:35 pm, Jorge<jo...@jorgechamorro.com> wrote:
> > >> On Jan 6, 2:29 am, David Mark<dmark.cins...@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?
>
>
>
> > 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.
>
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:-
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
> 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.
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_%28nominal%29>
--
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$8300...@news.demon.co.uk>
David Mark
wrote:
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. :)
acoleman616
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
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
> 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
David Mark
> 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.
kangax
> On Jan 6, 12:19 am, kangax<kan...@gmail.com> wrote:
>> On 1/5/10 8:54 PM, David Mark wrote:
>>
>>> On Jan 5, 8:35 pm, Jorge<jo...@jorgechamorro.com> wrote:
>>>> On Jan 6, 2:29 am, David Mark<dmark.cins...@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 ;)
>>
>> with ~62% market share at the moment
>> 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
kangax
[...]
> 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?
>
>> 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, of course. Thanks for correction.
>
>> 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.
Indeed. I should have thought about it.
[...]
--
kangax
kangax
> Thomas 'PointedEars' Lahn wrote:
[...]
>>>> 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.
Hmm, how would I know the difference between two... :)
<http://groups.google.com/group/comp.lang.javascript/msg/9d86789cac65b2a1>
(funny that you and me already had almost exact same conversation,
although before I started testing FHN).
--
kangax
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
> > Among many other things. It kills IE with ActiveX disabled, even
> > though IE has supported XHR without ActiveX for years.
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
> > 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.
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
> 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
David Mark
That's not true.
API.requireMimeTypeOverride
Set that and it won't use the non-ActiveX version. ;)
David Mark
> On 1/6/10 1:57 AM, David Mark wrote:
>
>
>
> > On Jan 6, 12:19 am, kangax<kan...@gmail.com> wrote:
> >> On 1/5/10 8:54 PM, David Mark wrote:
>
> >>> On Jan 5, 8:35 pm, Jorge<jo...@jorgechamorro.com> wrote:
> >>>> On Jan 6, 2:29 am, David Mark<dmark.cins...@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 ;)
>
> >> with ~62% market share at the moment
> >> (http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0)
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). ;)
David Mark
You'd never know if it got through or not. Cancel means cancel.
David Mark
> On Jan 6, 10:52 am, kangax <kan...@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.
David Mark
wrote:
> 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.
>
Yes, if you must infer about faulty MSHTML, a multiple object
inference is the best bet (as seen in My Library and copied years
later by jQuery). :) The conditional compilation is not needed and
the script engine version is not reliable. Furthermore, it fouls up
minification, at least for the YUI compressor (deflates less).
You could also look at document.expando (boolean), window.external
(host object) and window.external.addFavorite (ActiveX method--typeof
"unknown"). If those check out and there is attachEvent, but no
addEventListener, you can be damned sure that you are in IE < 9 (and
supposedly the leaks are fixed in IE8). If you want to assume IE8
fixed the problem, check document.documentMode (number).
But, as always, when left with such a "solution", think of another way
to deal with the problem, which is never _directly_ related to the
name of the browser or version number.
Scott Sauyet
> On Jan 6, 1:28 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>> 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.
http://groups.google.com/group/comp.lang.javascript/msg/33e110600bfaeeb7
http://groups.google.com/group/comp.lang.javascript/msg/ac02583964f3637b
http://groups.google.com/group/comp.lang.javascript/msg/9c46f34a4477a812
http://groups.google.com/group/comp.lang.javascript/msg/e1d0ee645674a5a5
http://groups.google.com/group/comp.lang.javascript/msg/a3112ff1853fdd70
-- Scott
David Mark
Thanks for reviving those. ;)
And I hardly consider commenting on those threads to be "trumpeting".
David Mark
> On 1/6/10 1:57 AM, David Mark wrote:
>
>
>
> > On Jan 6, 12:19 am, kangax<kan...@gmail.com> wrote:
> >> On 1/5/10 8:54 PM, David Mark wrote:
>
> >>> On Jan 5, 8:35 pm, Jorge<jo...@jorgechamorro.com> wrote:
> >>>> On Jan 6, 2:29 am, David Mark<dmark.cins...@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 ;)
>
> >> with ~62% market share at the moment
> >> (http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0)
Looking it over, I can see a few things that I would change (and
likely will as they are all trivial).
1. Remove unload listeners
2. Remove all signs of gBOF (deprecated method)
3. Optimize regular expressions
4. Copy simplified viewport measurement logic from:-
http://www.cinsoft.net/viewport.asp
5. Copy improved attribute handling logic from:-
http://www.cinsoft.net/attributes.html
...and remove the _ridiculous_ setAttributeByReplacement crutch.
5A. Include hack (no real solution yet) for IE8 bug related to
maximizing elements (or maybe they will fix it in the browser). Under
some circumstances, an element with offsetWidth x will create a
horizontal scrollbar (1 pixel overflow) when viewport width is x.
Obviously x - 1 alleviates it, but that is the wrong width (leaves one
pixel wide gap). (!) The above test page has the hack. Interestingly
enough, sidebars in My Library do not trigger the problem, but
maximized elements do. There's a clue in there somewhere. :)
6. Server needs to filter unneeded method detection for OO layer (it
knows what is going into it when building, of course).
7. Clean up add-ons (e.g. DOM ready simulation)
8. Add new keyboard monitor and a few other miscellaneous bits I've
come up with recently
9. Fill in some of the unsupported CSS2 selectors (lowest priority).
I'm working on a TaskSpeed demo too. Early results indicate it is the
fastest at virtually everything (fairly close to "pure JS" in some
cases). Ironically, this has caused me to work on #9 recently.
I'm sure there are other things that could improve it without
sacrificing any speed or adding much to the size. I welcome
suggestions (and help from qualified applicants). :)
And, of course, the documentation and Website could use some
improvements (perhaps even some pretty graphics). It's just never
been a concern for me to attract users for that thing. It's a loss-
leader for me.
David Mark
Should be clear. Matt was just trying to defuse the situation by
mentioning it first (he must be an aspiring lawyer). Fixed _one day
ago_. Now, I haven't discussed that one in earnest in about year
(when the ticket was originally filed). And, what a coincidence, I
just brought it up yesterday (in this very thread). Resig is a closet
CLJ fan! Either that, or the CLJ-Kruse-jQuery pipeline is still
flowing, despite Resig's recent ostrich imitations. Good and all, but
it won't save jQuery. :)
http://dev.jquery.com/ticket/3623
And yes, Matt Kruse, it was _way_ too late (for anyone foolish enough
to use jQuery any time in the last three years). You know _you_ can't
even upgrade the thing due to broken compatibility (and even if you
could, it's an expensive and unnecessary inconvenience). You
predicting I would say such things does not change the fact that they
are true. And you should have just kept your mouth shut as I didn't
even notice that they fixed it. ;)
David Mark
Oh, BTW, that's the same conversation where I explained that you need
neither expandos nor an ID-requirement to create an addEvent
function. How did that come up again, today? :)
And you don't need handles either, but I think that's the only sane
general-purpose solution. I know some will complain that it isn't
exactly the same as the wrapped DOM interfaces, but how is it the goal
to exactly mimic those? Seems like wrappers are a chance to improve
on them. ;)
Thomas 'PointedEars' Lahn
I stand corrected. Sorry, it was too much of a "slip of the keyboard" for
me to imagine.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
David Mark
> On 1/6/10 1:57 AM, David Mark wrote:
>
>
>
> > On Jan 6, 12:19 am, kangax<kan...@gmail.com> wrote:
> >> On 1/5/10 8:54 PM, David Mark wrote:
>
> >>> On Jan 5, 8:35 pm, Jorge<jo...@jorgechamorro.com> wrote:
> >>>> On Jan 6, 2:29 am, David Mark<dmark.cins...@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
> >>> 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 ;)
>
> >> with ~62% market share at the moment
> >> has nofast historynavigation whatsoever.
>
> > IE? It's had it since IE2, IIRC. Did they lose it at some point?
>
> 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.
>
Right. That's what matters. ISTM that Chrome and IE both have it,
but they preserve the _initial_ state of the DOM, rather than the last
state. In such implementations, unload listeners would not need to
thwart the feature. I'll test that theory when I get a chance.
Thomas 'PointedEars' Lahn
That's a bit non-intuitive, don't you think?
David Mark
wrote:
> David Mark wrote:
> > On Jan 6, 1:28 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> >> 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. ;)
>
> That's a bit non-intuitive, don't you think?
>
Absolutely, but not for requiring the (hack) overrideMimeType method
(which was what I had in mind at the time). :)
Jorge
>
> Right. That's what matters. ISTM that Chrome and IE both have it,
> but they preserve the _initial_ state of the DOM, rather than the last
> state. In such implementations, unload listeners would not need to
> thwart the feature. I'll test that theory when I get a chance.
Test what theory ? preserving the _initial_ state of the DOM, rather
than the last state would effectively be the ordinary cache behaviour
that browsers have had since ~ day 1. What's new and different in the
latest Safaris (Page cache), Firefoxes (Back-Forward Cache) and Operas
(Fast History Navigation) is that when the page is navigated away the
JS execution is halted and every single bit of the page's current
state is fully preserved in a way that permits to have it fully
restored at a later point in time as if it had never been navigated
away: IOW, the page is just hidden and its JS is paused. Currently,
neither Chrome nor IE have that.
--
Jorge.