I've had a few instances where users have copied and pasted the first eMail address into the second one, which, of course, defeats the purpose of having the second eMail address field. Is there any way to make this field non-pastable, and force the user to type in the eMail addy again?

Comments

sdsheridan’s picture

sdsheridan
he/him/his
CreditAttribution: sdsheridan commented

Further to this, i found the following construct on a website:

<input type="text" name="emconfirm" onpaste="event.returnValue=false;">

Don't know if that helps...

hunmonk’s picture

hunmonk CreditAttribution: hunmonk commented
Project: LoginToboggan » Drupal core
Version: 5.x-1.3 » 7.x-dev
Component: Miscellaneous » user system
Category: support » feature

password fields are provided by core. moving to the right queue.

sdsheridan’s picture

sdsheridan
he/him/his
CreditAttribution: sdsheridan commented

Well, ok, thanks, but that's not helping me right now... What can I do with my current site?

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented
Project: Drupal core » LoginToboggan
Version: 7.x-dev » 5.x-1.3
Component: user system » Code

Back to logintoboggan, where that issue belong: the second e-mail field is managed by that module.

By the way, you should probably not do anything: don't babysit your users. The true validation is not that second input, but the validation email.

hunmonk’s picture

hunmonk CreditAttribution: hunmonk commented
Status: Active » Closed (won't fix)

whoops, you're right. email field is not password field!

adding this is overkill IMO, i agree w/ damien that if a user wants to paste, that's their deal.

sdsheridan’s picture

sdsheridan
he/him/his
CreditAttribution: sdsheridan commented

Well, I guess then it begs the question why bother having it at all then, if one is going to permit the end user to circumvent the purpose of the field.

Is it not there to ensure that, upon retyping the eMail to confirm that the user didn't make a mistake when typing it into the first input box, if they don't match,

  1. we don't get spurious accounts on our sites, and
  2. the user does indeed get the confirmation eMail letting them into the site, thus enhancing their first interaction with our site, as opposed to them walking away thinking the site is flaky because it promised to eMail a confirmation and never did?

I see this behaviour on various sites all the time, and while I have in the past uttered the odd "grrr" under my breath when I did indeed have to retype the eMail address, now being on the other side, and having these accounts where the eMails are bounced back to me undeliverable, I get it why those sites didn't let me paste.

So, can I request a reconsider? And if not, some pointer as to how I might patch the module to achieve my goals if you feel it's not appropriate as an option for the community at large?

Thanks in advance, shawn

hunmonk’s picture

hunmonk CreditAttribution: hunmonk commented

i think this change would need a little more general support before i'd reconsider it.

i don't really have time to work out a patch. you may want to consider sponsoring one, or asking in the drupal.org forums.

Michelle’s picture

Michelle
she/her
Primary language English
Location Wisconsin, USA
CreditAttribution: Michelle commented

As someone who copies and pastes her email because I think the double email fields are silly, I'm glad to see this won't fix'd. Why assume people are incapable of typing their emails correctly? Not to say there aren't people out there clueless enough to put in the wrong email, but the assumption that everyone is has always annoyed me. The password fields I can understand because you can't see what you're typing. But the emails? Meh... Silly.

Michelle

sdsheridan’s picture

sdsheridan
he/him/his
CreditAttribution: sdsheridan commented

@Michelle: I wish the world was different, but people get silly sometimes, and then as the administrator, I wind up having to clean up (have already had to do this on my site ... eMail addresses like so-and-so@htomail.com). I'd just rather not do that, and there is also a reputational issue for a young site that I just don't want to have to deal with..."that stupid site never sent me my eMail confirmation!" ... "that's because you, stupid user, didn't type your eMail correctly, then copied and pasted the wrong one in the confirmation box." ... "Did not! Your site is ******!" ... "No it's not." "Yes it is."... you get the idea...

I don't like them frankly any more than anyone else (having to retype my eMail address), but I do understand why banks, governments, and other organisations do it. It's to prevent the administrative and reputational nightmare that would likely ensue otherwise. But I also appreciate your perspective.

For those of us who feel we need this, after some research, I found altering the definition of $form['conf_mail'] as follows does the trick in IE, Safari, Chrome, but interestingly enough, not FF:

          $form['conf_mail'] = array('#type' => 'textfield',
            '#title' => t('Confirm e-mail address'),
            '#weight' => -28,
            '#maxlength' => 64,
            '#description' => t('Please re-type your e-mail address to confirm it is accurate.'),
            '#required' => TRUE,
            '#attributes' => array( 'onpaste' => 'event.returnValue=false;' ), //added 2008-10-13 sdsheridan --- force user to retype password, not just paste
            );

Now I just have to figure out why FireFox is ignoring this... but at least this will cover the majority of users.

pisco23’s picture

pisco23 CreditAttribution: pisco23 commented

@sdsheridan - on a (non drupal) site I co-run, which has a reasonably big community (25000 users) - we have about 5% of the (single field) emails being incorrectly typed.... as you noted, 'hotmial', 'htomail', 'xxx.con' etc as well as (bizarely) lots of "www.me@mysite.com" !!!

I'm definately in favour of a twice typed email field at registration, even if it feels silly when doing it.

eoneillPPH’s picture

eoneillPPH CreditAttribution: eoneillPPH commented

The trouble being that 'onpaste' (according to my quick confirmatory Google search) is a "proprietary MSIE event", so it would not be recognized by Firefox (though one posting says Safari has this event as well). I see a few places where people try to fudge it, but none seems to be the same as what you are trying for. And who knows what all the other browsers do with it.

Suppose we could assume all the 'silly people' who can't type their own email address are using I.E.... that's not too farfetched. But by the same token, we could also assume that folks silly enough to mistype their own email address are too stupid to conceive the idea of copying and pasting it, so two fields would be fine and don't worry about the 'onpaste' pseudo-event.

Just keep in mind the main point: 'onpaste' is not a standard Javascript event.

rafamd’s picture

rafamd CreditAttribution: rafamd commented
Version: 5.x-1.3 » 7.x-1.x-dev

my 2 cents go for preventing pasting in the confirmation email field, that will enforce the purpose of the field.

just for the record ... :)

JordanMagnuson’s picture

JordanMagnuson CreditAttribution: JordanMagnuson commented
Status: Closed (won't fix) » Active

I think this issue is worth re-opening...

Opinions on making a confirmation filed "not pastable" are obviously going to vary: there are pros and cons on each side, and you can't have it both ways.

In terms of the case for preventing pasting, I think it's valid based on the fact that a certain percentage of people DO mistype their email addresses, and thus never receive confirmation emails. This leads to lost members, and extra hassle for administrators who need to followup with people who mistyped their email addresses.

Of course, I understand the case on the other side, for not "babying" and annoying users.

Since there is no clear "right answer" on this issue, why not make it an OPTIONAL setting in the LoginToboggan administrator settings? Then we simply add the relevant bit of js based on whether the option is set?

Would patches offering this functionality be considered?