Deprecate form prepopulation support from form.js

Thank you for opening this issue and attaching the screenshot.

The tag for the sprint, according to https://groups.drupal.org/node/447258 should be SprintWeekend2015 (no #).
Also, tags should be separated by comma, not a space.
In this case the component is find, we dont want a new tag #user module.

---

Please embed the screenshots into the issue summary.
The browser plugin from http://dreditor.org is what some contributors use to make that easier to do.

I updated the issue title to describe the issue described in the issue summary.

I pulled my 8.0.x to make sure I had the latest.
I installed.
I am not able to create any account using an email already used by a user.
I am not able to create any account using a username already used by a user.

Is your problem that the form fields at admin/people/create are prefilled with already used values, .... but the form errors ok, or is the form submitting ok?

user/register
is also having errors nicely when submitting the form with a username (or an email) that is already in use by a user.

hmm.
logging out, and using the url
user/register
submitting, and then again
user/register
I do get the form pre-filled with values I have previously used. but it errors fine if I try to resubmit the form with same values.

I think this is fine.

note admin/people/create is not pre-filling (if I am logged in as admin and using the page over and over)

As per user experience it should be fixed.

Let me give you an example. If there is a D8 drupal site is getting used by the educational institutes, And the same system is getting using by staff and students. is that case it should not show the last email id registered from the system(Browser) is visible for the next one.

We should fix it.

After some digging, it is a browser data attribute being set on the form.

    // For non-admin users, populate the form fields using data from the
    // browser.
    if (!$admin) {
      $form['#attributes']['data-user-info-from-browser'] = TRUE;
    }

cgit link

When this line is commented out, the reported issue does not happen. Found this change notice when I did a Google search of the data attribute - https://www.drupal.org/node/2243627

in drupal 8

when I do a ag (like grep but better)
ag data-user-info-from-browser

I get:

core/misc/form.js
179:      var $forms = $('[data-user-info-from-browser]').once('user-info-from-browser');

core/modules/comment/src/CommentForm.php
91:      $form['#attributes']['data-user-info-from-browser'] = TRUE;

core/modules/contact/src/MessageForm.php
113:      $form['#attributes']['data-user-info-from-browser'] = TRUE;

core/modules/user/src/RegisterForm.php
48:      $form['#attributes']['data-user-info-from-browser'] = TRUE;

core/modules/user/src/Tests/UserCreateTest.php
77:    $this->assertNoRaw('data-user-info-from-browser', 'Ensure form attribute, data-user-info-from-browser, does not exist.');

Linking issue which added this to D8 - #749748: Contact, register and comment forms do not prefill with user info from browser

*actually* linking.

I pulled my 8.0.x

admin/people/create
user/register
I'm not able to create any account using an email already used by a user.
I'm not able to create any account using a username already used by a user.

i think its working fine.

Retitling to be clear about what the issue is, and bumping to major to evaluate the potential privacy concerns. (I wouldn't call this critical really, since browsers do remember email addresses in other ways typically, but it seems very unexpected from a privacy perspective that if you go to a public computer, register for an account on a Drupal site, close the browser when you're done... the next person who comes along sees your private email address staring them in the face when they load the form.)

Adjusting title - the email address is the worst part but populating it with the last person's username is wrong too.

Those info and this behavior used to be inside cookies with a 365 days expiration. Now it's in localStorage with no expiration date.

As you can see in the related issue, breaking this behavior was considered a bug. I'm fine with it, just get rid of drupal.form library and the data attribute in the register form and we'll be done with it.

This is a triage at the Los Angeles Sprints. @cilefen and I did the triage.

The issue summary is up-to-date but could be rewritten to improve legibility.

The issue can be reproduced by registering on a given D8 site (e.g., http://d8.dev/user/register), entering a username and email address, submitting the form, and then reloading the user/register page. Clearing local browser data removes the preloaded data, however.

#749748: Contact, register and comment forms do not prefill with user info from browser was the issue that introduced this bug.

This issue was marked as Major by an experienced contributor in comment #14 and we agree with the assessment. Normal issues have “isolated impact”. This issue will occur on all browsers, and there is a privacy impact.

(Saving proposed issue credit for discussion and triage participants at LA.)

Re-uploading patch for the bots.

@prasad_gogate looking into this issue

Issue is not replicate.
Tried to created users with the user registration form
Steps

• 1. Navigate to - admin/people/create
• 2. Add user
• 3. Save.
• 4. click add another user
• 5. Populated next form does not show the previous added user.

Version tested - 8.1.0-dev

The issue is not yet triaged as a current major hence un-tagging

I think this issue refers to self-registration. Can you please try again?

And, this is a bug so you should test on 8.0.x also to be sure.

@cilefen: Yep, @prasad_gogate, @nagwani, and I untagged the issue because it was accidentally the wrong tag, but we figured we were missing a step to reproduce the issue properly given comments from @David_Rothstein and yourself above. @nagwani was working on trying to reproduce the issue in 8.0.x as of when it was filed but not sure if that got done among all the other triage work. :) Thanks!

(Updating issue credit for the major triage.)

I am facing the same issue. When the user registers form and clicks again on registration, still show laster user register detail. i can reproduce this issue on latest Drupal 8 release.

#21 worked for me.

#21 worked.

#21 worked. Awesome work here! I bow my thanks.

Should we be making a general decision about this behaviour? We use the same feature in comments and contact forms for anonymous users. If you submit a contact form on a site I['m not sure I'd expect the site to dump my email address into local storage on that computer.

I think this needs a product manager review to decide if the behaviour of storing user input indefinitely on a computer for anonymous users is desired.

This feature was added in #440876: Reuse comment.module's anonymous cookie information

Working fine.

And lets set that back to needs review for the product manager. Thanks.

@alexpott "Reuse comment.module's anonymous cookie information"

Did some work on cookies last couple months:
- Contact and comment indeed set cookies in this way that contain the name and e-mail (homepage). (search for 'user_cookie_save' in D7)

This maybe should be an option/additional param or something, these cookies are now always set and the only way to stop it is clone the submit function and drop the line that sets the cookie. I had to clone the submit and remove the cookie cause of gdpr.

(and gdpr is 1 but what about eprivacy next year, these cookies contain data that should not be stored like this, or at least - not without consent) (i vote to just remove them completely, taking into account all upcoming changes to privacy, storing data, etc).

My 5 cents: we should not store anything like this. Cause 'desired': not by me, it is actually a hurdle now to fix it for all my visitors... I disabled contact and do not use comment, switched it all for a simple form, wasted some nice private time on this.

hindsight: we should test these in the future, cause the eprivacy amendment already existed back in 2009 and nobody tested if the issue had to conform to any law i guess?

(Side-note: think we need a cookie api...)

User mglaman's comment worked for me.

Added the code in form_alter function:

$form['#attributes']['data-user-info-from-browser'] = FALSE;

And it worked.

Thanks mglaman

The patch seems pretty straight-forward, and I think it is pretty universally agreed that this is undesirable behaviour. Does it make sense to just merge this? Does it need a test to make sure no one comes up with this again?

Although it does raise questions whether prefilling this information is a good idea at all, I think that question is not as nuanced for the registration form than for the comment form.

Using for already some time on our project, I guess this is ready to be merged.

This still needs product manage review, I'll ping some folks

I think this is fine. The only negative side effect I can think of is manual UI testing will be harder because you will need to enter credentials manually. But that is an edge case and normal operation security improvements should not be held by that.

@Gábor Hojtsy should we create issues for the other places this is used. I think the same holds true for anonymously commenting.

I still feel that this not really a fix. We're still storing the data in local storage. This only means that it is not displayed if someone visits the user create form. We need to remove the ability to store personal information in local storage. We shouldn't be saving it for anonymous comments or anonymous use of the contact form. At least the user creation form doesn't usually have the form.js javascript on it because if it did then that would also save these details. But all I'd have to do make this happen is add a text with summary field to the User entity via the UI and allow it to be filled in on the registration form.

for that we can use the Clear-Site-Data header, to empty localstorage, serviceworkers, cookies, etc. I'm using that in the PWA module to clear things on login/logout. To me core should use that header to nuke everything on user logout.

What I did is that on login I clear all the storages (localstorage, serviceworkers, indexdb), and on logout I clear storage and cookies.

@nod_ I think this is different. I think we should never be storing this stuff in local storage. For the Clear-Site-Data header to work you need to log out. This stuff is recorded even if you never log in.

so something like this?

Re-rolled patch #58 for 9.4.x

Also removed this part from the test:

     // Test that browser autocomplete behavior does not occur.
+    // @todo just getting rid of this one? 
     $this->assertNoRaw('data-user-info-from-browser');

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Re-roll for 9.5.x

Try to Fix CCF errors.

I found this issue is still active in D10.0.9
What is the point to keep previous email and user name in register form?

Any patch or fix for D10 ?

Rerolled patch 66 for 10.1.x and 11.x.
However, I should note that this is a blind reroll. Did not check if there are any changes in core that might affect this.

Added new tag GDPR because storing cookies or data in localstorage without consent can violate data protection law, in Germany for example the TTDSG.

I support the proposal to remove it completely from the core.

Rebase the branch 2409107-11x with latest code from 11.x. Need to see if any tests are failing.

Tested the MR with i think originally the changes from taken from patch submitted in #55.

It is fixing the issue of this autocomplete and the username and email address are no longer auto-filled during user registration and browser no longer has values stored in localstorage for Drupal.visitor.mail and Drupal.visitor.name.

Steps to reproduce

1. Login as admin and go to /admin/config/people/accounts
2. Select "Visitors" in "Who can register accounts?" and save
3. Now visit the site as anonymous user and register as a user from "/user/register"
4. Logout with the currently logged in user and try to register another user, you will see that "Email address" and "Username" fields are autofilled with the values you filled to register your previous user
5. Also in the browser's local storage there are 2 propertiesDrupal.visitor.mail and Drupal.visitor.name where these values are also stored.

PR is failing it is showing the test core/modules/block/tests/src/Functional/BlockCacheTest.phpfailing but locally when I executed all the tests passed. Not sure what is causing these test to fail in the pipelines.

Thank you prashant c., the MR works for me (tested with PHP8.3 and D11-dev). Did not change state because of open comments.

@nod_:
- Maybe the `core/drupal.form` is not neccessary in modules/comment/comment.libraries.yml also?
- In modules/user/src/RegisterForm.php on line #36 `drupal.form` is also added.

@jan kellermann

Not sure about the files you mentioned in #80because the other methods from the library could have been used on these forms.

We need a change record. There are contrib modules that will need to be updated due to removing this feature. See http://codcontrib.hank.vps-private.net/search?text=data-user-info-from-b... for examples.

Also I think we should consider adding a deprecation to template_preprocess_form() if the array key exists... $form['#attributes']['data-user-info-from-browser']. That way contrib and custom code can find out about this and update their code.

I'm shocked, that this issue exists for 10 years. I discovered it recently while forking the contact module and didn't find the time until now to report it as a security issue with a proper proof of concept. I guess, I can mark this as done now.

Sorry for the rant. To add something productive: In case this issue persists for some more years, I wrote the module disable_libraries, which can be used to globally disable the core/drupal.form library.

I want to try a quick solution to get Drupal (CMS) GDPR compliant. The deprecation of Drupal.behaviors.fillUserInfoFromBrowser can be done separately later (open a new issue?).

This behavior violates GDPR because personal data are processed without consent.
This behavior violates the EU ePrivacy Directive for writing in user's browser without consent.

It would be great if Drupal CMS would stop violating both of these.

I restored the behavior and only removed the use in core.

I created MR !10644 and Change Record 3495510.

The failed tests do not appear to be related to MR.

Hello,
Tested and verified on Drupal 11,
MR applied successfully
Its working as expected
Attaching before and after screenshots.

I've manually tested on 11.x .... with the feature branch checked out the email address and the username of the person last registered with the browser is no longer displayed, the fields for the email address and the username remain empty. as a crosscheck i've then checked out the 11.x branch again and reloaded the create new account page and the fields for the email address and the username get directly repopulated. so from a manual testing and privacy perspective a big +1 for the approach taken. and if the deprecation of the behavior can be taken care of in a separate follow up it would speed up the resolution of this issue. i leave the the status at needs review cuz i am unable to provide any feedback about the code.

Have not reviewed but issue summary appears incomplete/incorrect, recommend using the standard issue template.
Also there are 3 MRs up if those can be cleaned up.

I created the new child issue #3498834 with issue description according to template.

I also created a new change record. The old change record from this issue can be deleted.

I hope that this will speed up the process.

I set priority to normal because depecration is not as important as getting the core compliant with data protection laws.

Re-titling for the deprecation of the overall functionality.

I merged the latest 11.x and tried to improve the issue summary.

From the title seems like it needs to be deprecated. Also CR is super old.

See https://www.drupal.org/node/3082634. What this issue seems to need is:

• An updated change record
• A call to Drupal.deprecationError() referring to said change record
• A follow-up issue to actually delete the functionality in Drupal 12

Updated issue summary.

Amending attribution.