On Feb 27, 2009, at 12:12 AM, John Resig wrote:
Do you have a demo that we can look at? Kind of hard to tell from
these snippets.
OK, you can test it with the attached.
How to reproduce:
1) Place the attached file inside your server root.
2) Adjust in your favorite editor the reference to
I think returning undefined is the intention here, same when you do a
lookup for a property that doesn't exist, returning null is not
equivalent. Referencing undefined properties is not a problem in JS,
this error is silly not taking the context in consideration.
- ricardo
On Feb 26, 2:30 pm,
I know there's been a few discussions centred around the image load
event. This (previously suggested) workaround works fine for catching
both new loads and cached images in the testing I have done:
$('img').bind('load readystatechange', function(e) {
if (this.complete || (this.readyState ==
Quick follow up - webkit won't re-fire the events on this.src =
this.src, but this unattractive modification will work fortunately it
doesn't generate any request, nor fire the error event, nor cause any
flicker:
var src = this.src;
this.src = '#';
Yes, but that requires the 'mouseover' event to be executed; which, in
turn, requires that a user move their mouse over the page at least a
pixel for it to trigger.
I believe Marcus was asking if it was possible to retrieve a user's
current mouse position without moving the cursor at all.
-
Thanks for pulling these details together, they're very useful. I've
added it on to the 1.4 roadmap and I'll see if we can't find a way to
simplify all of this.
--John
On Fri, Feb 27, 2009 at 7:08 AM, ajp771 alistair.po...@gmail.com wrote:
Quick follow up - webkit won't re-fire the events
Jed,
now your test is accessible, I can load it.
One problem I noticed:
frameWindow.onresize = function( e ) {
$(div/)
.text( DOM + e.type + event on the + this.name + at +
+new Date )
.prependTo( frameWindow.document.body );
}
when using DOM0 events IE will not pass the
Heads up: I just updated that page because it was a little out of
date, especially with the jQuery UI/Draggables/draggable examples. If
anyone sees any obvious errors, feel free to fix them.
Also, if we're going to make this a standard way for people to
document their plugins, it might
After another days work I found that I didn't have my first pass quite
right.
It turns out that any function that does a config.assertions.push()
[outside
the test fixture itself] can change the order that assertions are made
and need to be included in my waiting list. I'm going to see if I
can
You're right, it does seem to work in IE 7. However, it still fails to
work in Firefox and Chrome...
- Gavin
On Feb 27, 11:42 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
I tested in IE :D
On Fri, Feb 27, 2009 at 2:20 PM, d3r1v3d (Gavin Mulligan) vtga...@gmail.com
wrote:
I'll admit that I wasn't aware this page existed. As for jQuery UI
documentation, it's had a bit of an overhaul over the last couple weeks.
It's now similar, but significantly different (read: incompatible) with the
jQuery docs standard. This is necessary for a number of reasons that I won't
go
Gavin,
FYI in Firefox 3.0.6 on my Mac it seems I can get at those values
using the Java plugin with following bookmarklet:
javascript:alert(java.awt.MouseInfo.getPointerInfo().getLocation
().getX());
by typing that in the URL bar I can get current mouse X coordinates.
I cannot make it work
Diego,
Thanks for taking a look. I've distilled the test case down to make it
simpler:
http://s3.amazonaws.com/iframeWindowTest/before.html
http://s3.amazonaws.com/iframeWindowTest/after.html
And submitted a bug here:
http://dev.jquery.com/ticket/4268
Jed Schmidt
On Feb 27, 7:26 am, Diego
2009/2/27 d3r1v3d (Gavin Mulligan) vtga...@gmail.com:
You're right, it does seem to work in IE 7. However, it still fails to
work in Firefox and Chrome...
Both methods suggested by Andrea Giammarchi are working properly on my
box -- Firefox 3.0.6, Linux.
I wonder if it's just a Windows'
Since .get(-1) will be supported, eq(-1) would be supported too (?).
So your implementation needs some extra code:
eq: function( i ) {
if ( i 0 )
i += this.length;
return this.pushStack( this[i], 'eq', i )
}
However this solution would be still faster then the one on
Just out of curiosity, Marcus, I would be interested to know why you
want to know the user's mouse position before they move it. Maybe
there's a better solution that'll fit snugly within the scope of your
requirements.
- Gavin
On Feb 27, 12:02 pm, unwiredbrain unwiredbr...@gmail.com wrote:
I bet is the classic banner, spot, or JS effect to attach to the mouse and
somebody asked him why it is not attached since the beginning ... well,
Marcus, if it is the case tell them that the browser is inside a window and
if the user is not interacting with that window there's nothing you can do
Hi Abel,
I think it's more of a problem as to when the browsers update the
appropriate DOM elements that determine the user's current mouse
position (e.g. pageX / pageY and clientX / clientY). We can use jQuery
(or really just POJS) to trigger code that runs when a document is
loaded, but if
Andrea,
On 28 Feb, 00:42, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
I bet is the classic banner, spot, or JS effect to attach to the mouse and
somebody asked him why it is not attached since the beginning ... well,
Marcus, if it is the case tell them that the browser is inside a
Jed,
it seems the first error you mentioned is now OK in all browser I
could test.
In Internet Explorer 6 I still see the second error I said above in
line 958 char 6 error: Invalid argument.
But this is a different issue, your patch seems to have corrected the
logic error, hope somebody from
20 matches
Mail list logo
