Automate double password confirmation typing by means of Greasemonkey
Ever seen, and really hated, one of these?
Wouldn't it be rather stylish to have a Greasemonkey script fill in the second entry as you type the first, when there was nothing written there in the first place? (Yes, it severely defeats the intended purpose of the double check, I know. But let's move on.)
A good solution to the above would look for any two password fields in any page, that do not have any other visible form widget between them, and attach an onkeypress handler to the first, passing on the event, or a copy of it, to the other field as well. Points of style for additionally verifying that they are not very far apart in the page flow using this, or some variant thereof:
The Google Reader blog mentioned a while ago how you synthesize your own mouse click events; I'm sure it's not far from how it's done with keyboard input. Their code looked like this:
Wouldn't it be rather stylish to have a Greasemonkey script fill in the second entry as you type the first, when there was nothing written there in the first place? (Yes, it severely defeats the intended purpose of the double check, I know. But let's move on.)
A good solution to the above would look for any two password fields in any page, that do not have any other visible form widget between them, and attach an onkeypress handler to the first, passing on the event, or a copy of it, to the other field as well. Points of style for additionally verifying that they are not very far apart in the page flow using this, or some variant thereof:
function getScreenCoordinates( node )
{
var x = node.offsetLeft;
var y = node.offsetTop;
while( (node = node.offsetParent) )
{
x += node.offsetLeft;
y += node.offsetTop;
}
return { x:x, y:y };
}
The Google Reader blog mentioned a while ago how you synthesize your own mouse click events; I'm sure it's not far from how it's done with keyboard input. Their code looked like this:
function simulateClick( node )
{
var event = node.ownerDocument.createEvent( 'MouseEvents' );
event.initMouseEvent( 'click',
true, // can bubble
true, // cancellable
node.ownerDocument.defaultView,
1, // clicks
50, 50, // screen coordinates
50, 50, // client coordinates
false, false, false, false, // control/alt/shift/meta
0, // button,
node );
node.dispatchEvent( event );
}
posted by Johan Sundström
| 22:30
|
3 comments
I didn't know about the simulating clicks!!! That will be very useful!
Regarding simulating keyboard input to the second field - it is probably overkill in most cases. you can just change the value.
Also, might as well change it from a type="password" to type="text" so you can see what was typed :)
I actually think it's both simpler, more robust and elegant to propagate the same event we got to the other form field -- that way, we don't have to figure out what the received keypress was supposed to do with the field, and emulate the same behaviour, but leave that to the browser instead, which knows, guaranteed. Consider what should happen if we give it a keyboard sequence with problematic characters such as backspace, home, cursor right, Ctrl+A and delete.
Not only would our best guesses most likely not be ambitious enough, they might also very well be supposed to behave differently under different operating system environments; Ctrl+A might select the entire field on a Windows system, and it might yield the same action as home did on a Unix system. User preferences might even override these in ways we could not possibly predict. Repeating the event should solve all of these problems.
(I'm not suggesting all of these could not almost as well be solved with a setTimeout which copied the value from the first field some 50 milliseconds after the event fired, only that it is a less elegant solution, and one I would learn less from implementing. So I probably won't take the easy way out. :-)
For some strange reason, I just could not get simulateClick() to work in Firefox, at all. The event would basically never get triggered. I'm on 3.6.3 and the latest compatible GreaseMonkey. Ended up just setting window.location to the link's HREF, which is less than ideal.