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 th
Andrea,
On 28 Feb, 00:42, Andrea Giammarchi
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
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 thes
I am sorry, I am very new at the entire jQuery thing, but isn't there a
ready() function that could trigger the mouse cursor position? In Flash,
this would not even be a thing to be thinking about, let alone an
cross-browser compatibility issue...
Cordially,
Abel K.
www.worldkit.com
On Fri, Feb 2
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
v
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 wrote:
> 2009/2/27 d3r1v3d (Gavin
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
http://de
2009/2/27 d3r1v3d (Gavin Mulligan) :
> 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' window focus manageme
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 Pe
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 o
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 int
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
wrote:
> I tested in IE :D
>
> On Fri, Feb 27, 2009 at 2:20 PM, d3r1v3d (Gavin Mulligan)
> > wrote:
>
> > Yep, I tried your code in a demo page an
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
I tested in IE :D
On Fri, Feb 27, 2009 at 2:20 PM, d3r1v3d (Gavin Mulligan) wrote:
>
> Yep, I tried your code in a demo page and it confirmed my initial
> suspicions. It works great when the DOM of the test page is
> initialized with the mouse coordinates. However, this only happens
> when the m
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 make
Jed,
now your test is accessible, I can load it.
One problem I noticed:
frameWindow.onresize = function( e ) {
$("")
.text( "DOM " + e.type + " event on the " + this.name + " at " +
+new Date )
.prependTo( frameWindow.document.body );
}
when using DOM0 events IE will not pass
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 wrote:
>
> Quick follow up - webkit won't re-fire the events on this.src =
> this.src
Actually, we wrote up how to write API documentation a while back:
http://docs.jquery.com/How_to_write_API_documentation
You can feel welcome to document your plugins on the jQuery wiki (and
in doing so, your docs will be able to be extracted to api.jquery.com,
visualjquery, and other resources).
Yep, I tried your code in a demo page and it confirmed my initial
suspicions. It works great when the DOM of the test page is
initialized with the mouse coordinates. However, this only happens
when the mouse is initially moved after the page is refreshed.
Put your mouse in the middle of the test
I do not need to move the mouse to fire that event ... have you tried?
write this wherever and press F5 without move the mouse ...
document.documentElement.onmouseover = function(){
alert("Who moved?");
};
Regards
On Fri, Feb 27, 2009 at 12:54 PM, d3r1v3d (Gavin Mulligan) <
vtga...@gmail.co
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.
- Gavi
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 = '#';
I know that this may not be the best place to ask this, but since it
was mentioned quite a few times, I'll ask anyway.
At the moment, are there any guidelines for writing documentation for
plugins, or at least some indication on how jquery plugins should be
documented? Or is the pattern of jquery
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 == 'c
$(document.documentElement).bind("mouseover", function(eventObj){
alert([eventObj.clientX, eventObj.clientY]);
});
On Thu, Feb 26, 2009 at 2:49 PM, d3r1v3d (Gavin Mulligan) wrote:
>
> Hi Marcus,
>
> The function I've always used for obtaining the current mouse position
> is:
> function getMo
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,
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 t
27 matches
Mail list logo
