Mouse Gesture Visual Tails [UserJS]

Mouse Gesture Visual Tails [UserJS]

Someone requested this feature in the Desktop Wishlist forum recently, so I made a very little proof of concept script. It draws the trails fine at the moment but it's still a bit buggy.

I don't really want this feature myself tbh, but I understand it's a fairly oft requested feature, so I suppose it'd be nice to get it working well all the same. I can't figure out for the life of me what's causing the problem though.

Here's the script: GestureTrail.js

As I said it draws trails for the mouseGestures, the problem is that I have them set to disappear onmouseup, but Opera doesn't seem to detect onmouseup for the right mouse button. Is this a known bug, or have I made a mistake in my scripting?

(this bug also messes up right click context menus a bit)

Great and nice script! I`m using this userJS: mouse-gesture-track from sohm

...need I mention, Standards...?

Thank you, cym; and many thanks, to sohm!

Thanks for that cym. That's interesting. A completely different approach. The mouseup (line 32) doesn't seem to work in somh's script either - he employs a timeout hack to get rid of the trails instead, so I might try that myself. I must check the standards to see if this mouseup behaviour is actually a bug in Opera.

Originally posted by OakdaleFTL:

...need I mention, Standards...?

??? Not sure I follow...

Hmmmm....
Now this is odd. After further investigation I've found out a couple of things.

(a) The spec doesn't differentiate between right and left click for mousup so Opera's not following it.
(b) I tested my script in Greasemonkey (with a few GM_modifications) and it works. So Firefox does.
(c) The interesting part - bizarrely my script works in Opera if if you disable mousegestures (totally counter-productive of course)

So it seems mousegestures are breaking the standards.

Anyway... for the moment I've updated my script to employ sohm's setTimeout hack. Here: GestureTrail.js

(from JavaScript - Event properties)
Which mouse button has been clicked?

There are two properties for finding out which mouse button has been clicked: which and button. Please note that these properties don’t always work on a click event. To safely detect a mouse button you have to use the mousedown or mouseup events.

which is an old Netscape property. Left button gives a value of 1, middle button (mouse wheel) gives 2, right button gives 3. No problems, except its meager support (and the fact that it’s also used for key detection).

Now button has been fouled up beyond all recognition. According to W3C its values should be:
Left button – 0
Middle button – 1
Right button – 2

According to Microsoft its values should be:
Left button – 1
Middle button – 4
Right button – 2

No doubt the Microsoft model is better than W3C’s. 0 should mean “no button pressed”, anything else is illogical.

Besides, only in the Microsoft model button values can be combined, so that 5 would mean “left and middle button”. Not even Explorer 6 actually supports this yet, but in the W3C model such a combination is theoretically impossible: you can never know whether the left button was also clicked.

In my opinion W3C has made some serious mistakes in defining button.

Take the example from total mouse control... and play with it. You'll see that the right button is a cling-y bugger! This is indeed an Opera bug.

But I suspect code that doesn't use the right mouse button doesn't have this problem...

Thanks for that. No worries, I'm familiar with that document but unfortunately that's not the issue in this particular case.

Detecting which button has been pressed is a tricky cross browser issue because of the different implementations, but in this case as the userjs is for Opera only (FF doesn't have mouse gestures yet does it, so it would be of no use in GM?) we can rely on the button detection always adhering to the same model.

The issue here is not detecting the button on the mouseup event. It's the fact that the mouseup event isn't occuring at all!

My guess is that the mouseup event IS triggered (as per ecma spec), but the code that controls mousegestures is accidentally cancelling it... just a guess though.

P.S. - What did you mean in your first post by standards?

Originally posted by lucideer:

FF doesn't have mouse gestures yet [...], so it would be of no use in GM?

Well, there was an extension... And it included mouse tails. But it didn't work in 3... Oops! Firefox 3.0.1, FireGestures 1.1.6!
Oh, well. There goes the neighborhood...

Originally posted by lucideer:

we can rely on the button detection always adhering to the same model

Nope; not really: The model is -as you've discovered- ambiguously specified; how would you check to see if the right button was released? So: How does Opera?
You'd have to check detail's value, to see if no click occurred. Does Opera? (If it does, it's via mousemove...)
Should your script? (Can it?)

I wonder: How hard would it be, to disable the mouse tails in FireGestures and test various JavaScript emendations...?

Originally posted by OakdaleFTL:

The model is -as you've discovered- ambiguously specified

No... we're talking about two different things.
1 - You're talking about how Opera indicates which button triggered the event - this works fine and is unambiguous. (it sets event.button=2 as per the "poorly thought out" W3C spec you've mentioned above)
2 - I'm talking about whether Opera triggers the event in the first place - this doesn't work.

Originally posted by OakdaleFTL:

I wonder: How hard would it be, to disable the mouse tails in FireGestures and test various JavaScript emendations...?

I can hardly see the point - I assume it'd just work as it does now without FireGestures, but I can instruct you on adapting the script for GM if you feel inclined to play around with it. (I think I just replaced every instance of window with unsafeWindow)

Correct me if I'm wrong, but if Opera "consumes" the event via a previous ",,true" handler, the mouseup for the right button (from a script) is stuck on the queue...

True... my point is that detecting the right mouse button works as expected for the click and mousedown events, and also works for the mouseup event if gestures are disabled. So detection of which button is working. So it seems anyway.

Not exactly sure what you mean by ",,true", but I'd imagine "consumation" of the event might work in someway conceptually similar to opera.addEventListener('BeforeEvent.mouseup',funtion(e){if(e.button==2){e.preventDefault();/*do mouse gesture*/}},0);. Is that what you mean?

Essentially, yes: but your '0' should be 'false'... (A bad habit, that: using numbers in place of boolean values.) You'll note that your script -with mouse gestures disabled- paints the tail and fires the context menu for the page. To bubble or not to bubble, that is the question...

Really? I didn't know this. AFAIK 0,null,undefined==false in every browser (although they obviously don't ===false). Is type conversion especially inefficient? Not something I was aware of. Thanks for the tip anyway, I'll try and keep it in mind. Although I'd like to understand the reasons.

I'm afraid my script isn't triggering that context menu. Try disabling gestures and disabling my script. ;)

Really: It's just me, being finicky. Pay no attention. And I'm sure you're right, about type conversion... (But I cut my eye-teeth on a McCosh C compiler, on a floppy disk system.) The reason I'd give for "preferring" false to 0 or null is that the argument's meaning becomes less clear with them: see this.
Readability should matter! < soapbox />

Oops. (Again.) I meant sohm's script... But I'll try yours, tomorrow.

In the meantime I've installed GreaseMonkey 0.8 and set it up to use Notepad++ as its editor, and figured out how to load scripts from the local host. That's enough for today, I think.

I can see your point coming from C, it's typing system is very different. Tbh, I think both js and C have typing systems suited to their purposes. See here. As for readability, I actually like the 1,0 analogy myself, reminds me of binary on|off for true|false.

Originally posted by OakdaleFTL:

Oops. (Again.) I meant sohm's script...

You misunderstood me here. The context menu does appear with my script. My point was that my script doesn't cause it's appearance. It appears without any userjs as long as you have gestures disabled.

Good to hear about the GM installation. I think cross-browser testing is far too often overlooked in userscripting. It's seen as separate somehow from normal web dev and therefore exempt for some reason. I don't understand why. (although as I mentioned, this particular script is obviously an exception)

Originally posted by lucideer:

The context menu does appear with my script. My point was that my script doesn't cause it's appearance. It appears without any userjs as long as you have gestures disabled.

This -to me- seems wrong: If a "mouse-move" intervenes, between the "button-down" and the "button-up" events, there should not be a "click" event...

I'm sorry, but could anybody please explain one more time the function of this script?! If I got it right, it should display the mouse tail during MouseGesture, right?! I installed the script but nothing happened!
That would be a nice script though, by the way!

Originally posted by alienyd:

I'm sorry, but could anybody please explain one more time the function of this script?! If I got it right, it should display the mouse tail during MouseGesture, right?! I installed the script but nothing happened!
That would be a nice script though, by the way!

Ctrl+F12 > Advanced > Content > JavaScript Options... > Allow the script receive right clicks

thanks, that was my fault! working fine now, just messing the scroller script!

Thanks for that cvm, should've mentioned that in the first post I suppose.

Originally posted by OakdaleFTL:

This -to me- seems wrong

Yep. You're right there. It is:

Originally posted by W3C DOM2 Spec:

If the user moves the mouse between the mousedown and mouseup the [UIEvent.detail] value will be set to 0, indicating that no click is occurring.

[DSK-245156] Bug reported.

Good stuff. Is that the click bug or the mouseup bug you reported? Or both as one?

I suppose it's both. I held Ctrl and clicked lmb, then moved it a bit, the page moved slowly, but not for long, it started jerking right after that. I think it might have some problem with my snap-link js
Thanks anyway

Your script broke the link drag and drop like to put a link bookmark panel or in personal toolbar.

Originally posted by Nickko:

Your script broke the link drag and drop

Fixed: GestureTrail.js
Thanks for the feedback Nickko!

If you meant [DSK-245156], it was the click bug. (I'm not sure the mouseup listener's seeming malfunction is independent... First things first!)
Oh, in case I failed to mention it before: Thanks for the script! Using the canvas for such is a very interesting technique...

Hy.

I really like the script, but i've found one small little problem with it.
I have to click somewhere in the page before the links work, i mean after loading a page, the mousecursor doesn't change to a hand when i hover over the links, but after i click anywhere in the page the cursor changes when i'm over the links.

Note : i'm using Opera 10 (10.00 alpha Build 1229), and i've tried with and without any other scripts.

Is there any way to fix this ?

P.S. with Sohm's script this doesn't happen, but i like it better how your script draws the trails

Hmmm.... I'm not seeing this behaviour using Opera 10 Build 1139. I may try 1229 at some point in a little while.

What my script does is it creates an invisible canvas element the height and width of the page but hides it under everything else until you right-click (and then re-hides it when you release) - so I can imagine what would be causing it - something is bringing it up above everything - including the links. Unfortunately this isn't happening for me so I can't test what's causing it.

All I can think of is it could be some page scripts interfering (is it happening on a particular website, or everywhere?)

Also, are you getting any javascript errors? (Tools->Advanced->Error Console)

After looking at the error console's messages I've managed to solve the problem.

Here's the error I was getting in the ErrorConsole :

CSS - http://my.opera.com/community/forums/topic.dml?id=263915&t=1232704040&page=1
HTML style attribute
Declaration syntax error
Line 1:
  position:fixed;top:0;left:0;z-index=-999;opacity:1;
  -----------------------------------------^

So, I've modified the script and removed the z-index=-999; from the styling of the canvas and added it later on.

So, in other words, I've replaced the next part of the code

	  canvas.style="position:fixed;top:0;left:0;z-index=-999;opacity:"+this.opacity+";";
	  document.body.appendChild(canvas);
	  this.canvas=canvas;

with

	  canvas.style="position:fixed;top:0;left:0;opacity:"+this.opacity+";";
	  document.body.appendChild(canvas);
	  this.canvas=canvas;
	  this.canvas.style.zIndex="-999";

EDIT :
I've also played a little with the "lineWidth" property of the 2D Canvas, if you set it to lets say 8 and set the opacity to 0.25 then you get a very interesting effect, you can still see the trails but just

Nice! Does it all work ok now? If so, I'll add that change.

Ya, I added the options at the start for anyone who wanted to play with that. I should add line-width too actually..

With that modification the script works on all the sites I've tested.
I have no idea why on some sites (like MSDN) it worked correctly while on others (for example this site) it didn't, after all i was using the same script on both sites

Right.. thanks for that. I've put in that change. Sounds like another Opera bug - not applying z-index if it's applied before the element is inserted into the DOM - which is obviously wrong if it is applying position, top and left.

Edit: Scratch that, I've just looked at your post above. It seems to have been a typo (can you spot it), no wonder I wasn't seeing the same behaviour. No Opera bug there. Sorry about that.

Well, I can't find the typo, but i'm not a JavaScript programmer

Anyways, I've found a problem, if I open many pages then Opera will start eating a lot of memory, but only if this script is running.
I suppose that the Canvas object takes up a lot of memory (specially on higher resolutions).

I'm using Opera Alpha 10 (b 1229) so that might also be a problem and i have the habit of having at least 15-20 pages loaded at once

Yeah.. this is possible. I've not noticed a slowdown on Opera10 b1139 but I haven't been monitoring my RAM.

I've seen some canvas benchmarks, but only comparing browsers or canvas vs SVG vs VML; no tests which compare it's efficiency to say... DOM mutation. I know DOM mutation can be quite inefficient (although I know Opera as a browser is especially quick at it), so I thought sohm's original script might have this problem as it does this in loops, but I really have no idea how canvas compares - I know it's reputedly faster than SVG, but beyond that... a speed comparison would be helpful if anyone knows of one?

P.S. - my typo: "left:0;z-index=-999;opacity:1;" should be "left:0;z-index:-999;opacity:1;"

Working fine in Opera 10, thanks.

I'm not a JS genius but i think the problem with the mouse up event not firing comes from the browser.js file. Around line 119 and line 365 they do a lot of manipulation of mouse events.

Originally posted by toyotabedzrock:

I'm not a JS genius but i think the problem with the mouse up event not firing comes from the browser.js file. Around line 119 and line 365 they do a lot of manipulation of mouse events.

Unless browser.js is running on every webpage, I doubt it. I will definitely look into it out of curiosity though.

i really enjoy this userJS,

took a while to figure out that the script wont run with "allow script to detect context menu event" turned off
but i found no problem whatsoever

however i have a small question, how can i change the color of the trail? i changed the color variable a few times but i don't really know what code is which color and i only get shades of red

Colour codes:

#RRGGBB - Three two digit numbers specifying the levels of Red, Green and Blue to mix together.

a,b,c,d,e and f are treated as numbers higher than 9 - so it goes 77,88,99,aa,bb,cc,dd,ee,ff - #ffffff is white - 100% all colours.



Also, if you're not too picky, just specifying "Red", "Blue", etc. instead of a hash-code will usually work for the most basic colours


(btw, #f27 is shorthand for #ff2277)

thank you very much, really appreciated you help.

You should either hide SVG with display:none or maybe remove it when not shown (that will probably be not very fast). It's because scrolling is jerky when there is some fixed positioned element on page.

Superb stuff, this is brilliant.

Originally posted by d.i.z.:

You should either hide SVG with display:none or maybe remove it when not shown (that will probably be not very fast). It's because scrolling is jerky when there is some fixed positioned element on page.

Thanks d.i.z., I hadn't noticed such behaviour but I've added that modification nonetheless.

Originally posted by cvm:

Originally posted by alienyd:

I'm sorry, but could anybody please explain one more time the function of this script?! If I got it right, it should display the mouse tail during MouseGesture, right?! I installed the script but nothing happened!
That would be a nice script though, by the way!

Ctrl+F12 > Advanced > Content > JavaScript Options... > Allow the script receive right clicks

I am on Opera 10. There does not appear to be an option to "Allow the script receive right clicks"

But, allowing "context menu detection" seems to work. Thanks

@mendoc (and others)
Yes the option seems to have been renamed ever so slightly in Opera 10 for some reason. Who knows why... Either way, you found it.

Originally posted by lucideer:

Originally posted by toyotabedzrock:

I'm not a JS genius but i think the problem with the mouse up event not firing comes from the browser.js file. Around line 119 and line 365 they do a lot of manipulation of mouse events.

Unless browser.js is running on every webpage, I doubt it. I will definitely look into it out of curiosity though.

The browser.js runs on every page. Opera uses it to correct site errors. http://www.opera.com/docs/browserjs/

Line 119 is a function that is defined for usage elsewhere. Same for 365. Any time that this is actually used you will see it in the console. 'Opera has modified the JavaScript on '+hostname+' (Mouseover popups do not appear due to document.all sniffing). See browser.js for details'). This particular message is for worldorwarcraft.com

There are a couple of global fixes too, but those specific ones are only used on specific sites (as are all the functions I'd think—if they were needed globally you wouldn't need to to stick them in a function for easy reuse), for some reason mostly webmail.

Originally posted by toyotabedzrock:

The browser.js runs on every page. Opera uses it to correct site errors.

It does on every page, but it really only does anything on a few sites that would otherwise break. Everything else is unaffected.

Originally posted by Frenzie:

It does on every page, but it really only does anything on a few sites that would otherwise break. Everything else is unaffected.

@toyotabedzrock
This is what I meant when I said it doesn't "run" on every page - i.e. it isn't "active" on every page.

Not work properly with mouse control in Opera 10.51 with "open link in new page", "open link in background page"

Thanks, I changed the color to black

Where can I make it a little thicker? Also, when you do a mouse gesture forward then go back, you see the last mouse gesture trail for a second or so.

Find this line: this._2d.beginPath();

Above that, put
this._2d.lineWidth = 10;

Or I think something along those lines should work, anyway. I don't use the script, I just peeked at the code.