Canceling a form submitted to an iframe target

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

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]

IIUC, the only faulty DOM implementation is the MSHTML DOM.  There mustbe
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]

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]

http://groups.google.com/group/comp...oup/comp.lang.javascript/msg/a3112ff1853fdd70

Thanks for reviving those.

And I hardly consider commenting on those threads to be "trumpeting".

 

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

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

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]

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?

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]

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

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]

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

I stand corrected. Sorry, it was too much of a "slip of the keyboard" for
me to imagine.


PointedEars

 

[David Mark]

IE 6, 7, 8 had none, last time I checked. But we need to definefasthistorynavigation 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.

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


PointedEars

 

[David Mark]

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.