keyboard entry simulator needed - dom.event.clipboardevents.enabled has pitfalls/issues
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: mozilla.bugs.grokchem, Unassigned)
Details
Steps to reproduce:
I went to a webform that clears out a field if it was populated by pasting from a clipboard. I tried entering a character manually then pasting, then entering more by hand.
I also set dom.event.clipboardevents.enabled → false. I did not restart Firefox -- which might be necessary. However, this is not a bug report on that setting. Will explain in the 3rd box.
Actual results:
Sometimes it works to do a partial manual entry before pasting, but not this time. The webpage cleared my entry every time I left the field regardless of how I pasted (control-v, middle click, rt-click menu).
Expected results:
The paste should have worked because there is really no reason it should be distinguishable from keyboard entry.
It may be possible that restarting FF after changing dom.event.clipboardevents.enabled would have made a difference. But that’s still a bad solution because in reading other bug reports it’s clear that disabling clipboardevents has undesirable side-effects.
I was DEEP into an interactive multi-page interview and had to do SMS confirmations to reach the point I was at. Then what, in the middle of this form filling I am supposed to toggle a boolean and restart the browser and repeat the whole interview? No, FF should be better than that. I should be able to right-click one of these anti-user fields and paste on-the-fly. Right-clicking currently gives:
- paste
- paste as plain text
We should really have more options like:
- paste from primary clipboard
- paste from secondary clipboard
- paste as plain text (not sure what this is)
- paste from primary clipboard simulating as if typing from the keyboard
- paste from secondary clipboard simulating as if typing from the keyboard
We should not need to touch the configs in order to paste into a field.
|
||
Comment 1•8 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•8 months ago
|
||
Thanks for the report.
Can you share the link to the site where you encountered this issue?
You would not likely be able to reach the form. The form is designed so that you must have a GSM phone number from the carrier “Orange”. The first page only wants phone number. Then the a page or two later you reach a form that blocks pasting into the email address field. If you don’t have an Orange account, I don’t think you could even render the next page.
I thought I could perhaps use my number to reach the same point again and save the page, but the form blocked me saying “you already have an account”.
BTW, I would have prefered to DM you but bugzilla seems crippled in this way.. I see no way to DM people.
|
||
Comment 4•8 months ago
|
||
Hi,
not sure I can follow. Is the issue that there is an input field in the form which does not allow pasting? This could be intended behavior on a web page. I actually have seen this as a sort of security measure, especially in forms where the user should confirm their mail address.
Or is there more to this?
Is the issue that there is an input field in the form which does not allow pasting?
Yup.
This could be intended behavior on a web page.
Yes, it is the intent of the web admin to force users to manually type out by hand a field (in the case at hand, it’s the visitor’s email address but this anti-user feature can be applied to any field in any form).
It is the human user’s intent not to do the work of a machine. It is the user’s intent to avoid wasting time and effort into an error-prone process. For example, suppose your email address is:
bobsusername@hi3ftg6fgasaquw6c3itzif4lc2upj5fanccoctd5p7xrgrsq7wjnoqd.onion
Would you like to enter that by hand into a form? Unlikely. It’s an unreasonable ask. I cannot imagine any user who would welcome that. But if a user does want to do so, they have that option anyway.
I actually have seen this as a sort of security measure, especially in forms where the user should confirm their mail address.
It’s not useful to try to guess the web dev’s ultimate intent. For two reasons:
- We might guess incorrectly. We only know point blank that the web admin wants to force users to hand type email address. We don’t know /why/ the web admin wants to put users through that because they do not express rationale. In fact, they typically take the rudest approach and do not even inform users that they expect hand-typing. They simply present a form that puts users into an undisclosed effort under undisclosed expectations.
- Most importantly: it does not matter what various web admins intend because the client software is not created to serve them.
Or is there more to this?
There is a philosophical question to consider: are apps that are excuted suppose to serve the person who executed the app on their own assets? Or should an app serve the interests of outsiders who the app may connect to? I have raised a new ticket because the manifesto neglects to answer that question:
I forgot to mention that the boolean setting dom.event.clipboardevents.enabled likely exists for the purpose of prioritizing the UX above the interests of the web admin in control of the web form. If it’s not Mozilla’s intent to give users control, then that boolean should be scrapped. Otherwise, the app should be consistent with the past decision to give users control.
|
|
||
Comment 7•7 months ago
|
||
Thanks for your reply. In short -- the behavior is expected, and it is the freedom of web apps to do things like that.
Turning off the dom.event.clipboardevents.enabled is not recommended and will likely break lots of web pages. Such prefs are often introduced during development, so that the implementation can be done in several steps, and be tested before enabling a feature on one or all channels.
After the feature has shipped and proven itself to be working, they become more or less useless and might even in some cases give a false sense of security, while at the same time only creating frustration on the user's end because web pages stop working unexpectedly.
We sometimes clean up unused prefs for that matter. However, this one might be worth keeping / extending for a more fine-grained control.
There's Bug 1670383, which might be similar to what you are proposing. I'll close this one as duplicate.
Description
•