1667657 - Form input field replaced with incorrect dummy value

Status: RESOLVED DUPLICATE of bug 520561

(DevTools :: Inspector, defect)

Description

[Kiril Mitov]

Attachment: Screenshot of the rendred value in firefox.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Visit a form on a site

Actual results:

1. The site response with a payload that contains and html form with a hidden field
   The payload in the network tab correctly shows the response of the server. which is

        <input type="hidden" value="636191" name="enroll[group_user_attributes][group_id]" id="enroll_group_user_attributes_group_id" /> 

2. But the form that is rendered contains a different value

<input type="hidden" value="x97PoyV1qw2oUwBxYM1UGj43GVC4wQWYoduWkb2D9/3VX1/H+ZFJ3fHNCjswRscUQkslDXgHtQxIoUO6F1JhgQ==" name="enroll[group_user_attributes][group_id]" id="enroll_group_user_attributes_group_id">

3. Original issue with screenshot - in rails forum because I though this was an Rails issue -https://discuss.rubyonrails.org/t/csrf-token-is-sometimes-filled-as-an-attribute-in-the-form/76283

4. Stackoverflow question - https://stackoverflow.com/questions/64085943/csrf-token-is-sometimes-filled-as-an-attribute-in-a-rails-6-form

This happens only on Firefox and only the first time a form is shown. From then on it is ok.

Expected results:

Render the enroll_group_user_attributes_group_id value correctly

Firefox version - 80.0.1 (64-bit)

Comment 1

[Kiril Mitov]

Attachment: Screenshot of the payload.png

Comment 2

[Kiril Mitov]

I could tell you how to reproduce it on the production site but you would have to create an account and create a new group. It is free. I could give the link to the production site.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 4

[Kiril Mitov]

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #3)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

It certainly do not belong to devtools and netmonitor. The problem is visible without devtools and netmonitor enabled.

Comment 5

[Hubert Boma Manilla (:bomsy)]

Hi Kiril,
This looks like its the inspector not showing correctly. I'll move it.

I could tell you how to reproduce it on the production site but you would have to create an account and create a new group. It is free. I could give the link to the production site.

This would be really useful to help fix, please could you give clear steps to reproduce.

Thanks

Comment 6

[Kiril Mitov]

I have reproduced it, and recorded a video.
I have set up an account where you could try it on a live system.

I will attach the video but here are the steps. Reproducing is simple but we first have to reach the form where it happens and this takes ~10 clicks to login and go there.

1. Visit https://www.fllcasts.com/users/sign_in
2. Username: firefox2009
3. Password: D@U9XMJP (I have not problem keeping this password visible for this account as there isn't much someone could break with it, but I will change it at one point as the issue gets reproduced and resolve, as to not leave it open on the internet).
4. Click Log in
5. Go to Dashboard->Groups
6. Click on the only group called "Reproducing bug 1667657"
7. Click on Enroll
8. Click "Create/Invite a new account"
9. Enter full name: Firefox.
10. Leave email as it is. Username will be automatically generated for you.
11. Click on "Generate" for the password.
12. Select "Keep the password Secure..."
13. Click on "Create FLLCasts account"
14. As a result you are on a new page and this page is the form for enrolling the user in the group.
    Open the form with the inspector and search for input with id "enroll_group_user_attributes_group_id"
    As a value of this input you would see something like "cSUVJRcCUDB6Ey62y4YjKldHy/9js1dsBXj8UwFJgogk3Tr0NgmbsgQofg8TrLLwwvTOY52fXhtq7wGpsTWHRQ=="

It happens only the first time when you visit the form with firefox after you login. Once you visit it the second or third time it does not happen and the value is correct. Note that in the payload of the request response the value is correctly returned from the server, but somehow is changed after that.

Comment 7

[Kiril Mitov]

Attachment: Video showing the reproduction of the issue on Firefox 80.0.1

Here is the video recording

Comment 8

[Kiril Mitov]

Hi

Do you know of a workaround here? Anything I can do while waiting for a resolution?

Even something like

if request.browser=='firefox'
  response.do_somethig
end

will do?

Comment 9

[Razvan Caliman [:rcaliman]]

Hi Kiril,

That value looks like it's a hash of something cSUVJRcCUDB6Ey62y4YjKldHy/9js1dsBXj8UwFJgogk3Tr0NgmbsgQofg8TrLLwwvTOY52fXhtq7wGpsTWHRQ==

The DevTools Inspector does not hash anything and it certainly doesn't mutate values in the DOM without explicit user action.

If there's a difference between the Network payload and the resulting DOM structure after injecting the markup into the document, perhaps check if there are scripts in the page which replace those values at runtime. DOM mutation breakpoints may help you investigate.

Comment 10

[Razvan Caliman [:rcaliman]]

Also, perhaps this is an autocomplete bug similar to Bug 520561. I'm not sure.
Try pinging folks on that bug if you can make a reduced test case to verify this hypothesis.

Comment 11

[Kiril Mitov]

I will try with the autocomplete='off' as mentioned https://bugzilla.mozilla.org/show_bug.cgi?id=520561

I have reproduced it a couple of times with javascript turned off. I will also look at the Dom mutation breakpoints.

What is not clear to me is why https://bugzilla.mozilla.org/show_bug.cgi?id=520561 is closed as it is reproducible with firefox 80. This seems to be an issue.

Comment 12

[Razvan Caliman [:rcaliman]]

I will try with the autocomplete='off'

If that works, then this bug is most likely a duplicate of bug 520561. Let me know and I'll reopen it.

I have reproduced it a couple of times with javascript turned off. I will also look at the Dom mutation breakpoints.

If JavaScript is turned off and this still happens, there can't be any DOM mutations from scripts on the page. No need to test that scenario

What is not clear to me is why https://bugzilla.mozilla.org/show_bug.cgi?id=520561 is closed as it is reproducible with firefox 80.

Bugs which don't get activity for a long period of time may be closed. Same for bugs without clear steps to reproduce consistently. Hence why reduced test cases will generally get the attention of developers quicker; that way they can figure out where to look for the issue in the code base.

Comment 13

[Kiril Mitov]

Thanks for the explanation. I really appreciate it.

I have a video recording, I have a live production site. I've provided registrations, user info, I have provided a 100% reproducible example. What more could I do to help here? The video is showing the values. The form is showing how it does not work.

What I am afraid will happen now Is that I will now add an autocomplete='off' to the field, and will submit, and this will probably resolve the issue and you would no longer be able to reproduce it and this bug like the other will be closed for no activity.

I would love to be able to reproduce it by sending just an HTML page that you can open locally and see the error, but Firefox has no problems with simple HTML pages. I have a real world scenario for a complex issue that has occurred for many others about 5 months ago and is occurring now.

Comment 14

[Kiril Mitov]

I have just added autocomplete='off' and it now works. I will attach the screenshot.

Comment 15

[Kiril Mitov]

Attachment: ScreenshotShowingThatItWorksWithAutocomplete-off.png