Password field is not reset when clicking 'New '

[romed]

Did you use the FAQ section?

• Yes, I have read the FAQ and I found no solution/answer there.

After creating a password protected paste, clicking on 'New' returns to the creation form.
In the form the password is already prefilled with the password used for the last created paste.
Because all the other fields are defaulted when clicking on 'New', I would also assume so for the password field.

Steps to reproduce

1. Create a password protected paste
2. Click on 'New' to get back to the creation form
3. Observe the password field -> It is not empty
4. Creating the paste with the prefilled password allows to check that it is indeed the same password which was used for the first paste

What happens

Password field is not emptied when clicking on 'New'

What should happen

Password field is emptied when clicking on 'New' as are all the other input fields

Additional information

There was a similar ticket in the past: #611
It mentioned also the password not being reset, the fix did not cover it though.

Basic information

I can reproduce this issue on https://privatebin.net: Yes

[rugk]

Yeah, I can imagine this. Since PrivateBin is kind of a SPA, that needs to be handled in a custom way. However, it should be as simple as clearing the input at the correct position.

As such maybe a "good first issue" respectively if you want to do a PR, feel free.
We now support GitHub codespaces somewhat to have an easy start and develop directly in your browser. I have also documented this on https://github.com/PrivateBin/PrivateBin/wiki/Development#getting-started now.

[9401adarsh]

Hello there, can I take up this issue if it's still open ?

[elrido]

Sure thing, go for it. The files changed in #612 should give you an idea what method you'd want to look at (TopNav.resetInput()) and within that TopNav class the property $passwordInput should give you access to the input field as a jQuery-wrapped element (from TopNav.init()):

PrivateBin/js/privatebin.js

Line 4530 in f313578

$passwordInput = $('#passwordinput');

[9401adarsh]

Hello, I raised a pull request with the fix. However, it failed a compliance test. Could you let me know how to proceed ?

Run github/codeql-action/upload-sarif@v3
  with:
    sarif_file: snyk.sarif
    checkout_path: /home/runner/work/PrivateBin/PrivateBin
    token: ***
    matrix: null
    wait-for-processing: true
Error: Path does not exist: snyk.sarif
ConfigurationError: Path does not exist: snyk.sarif
    at getSarifFilePaths (/home/runner/work/_actions/github/codeql-action/v3/lib/upload-lib.js:287:15)
    at Object.uploadFromActions (/home/runner/work/_actions/github/codeql-action/v3/lib/upload-lib.js:281:30)
    at run (/home/runner/work/_actions/github/codeql-action/v3/lib/upload-sarif-action.js:56:47)
    at async runWrapper (/home/runner/work/_actions/github/codeql-action/v3/lib/upload-sarif-action.js:84:9)

[elrido]

If I remember correctly, the issue with Snyk is that it requires a secret to use the service, which is of course stored in this project, but won't get cloned into forks. So unfortunately that scan only works for branches living in this project, but not for PRs coming from another forked repo. If anyone has an idea if github actions could be set up not to fire when the PR is not related to a branch of the same repo (or maybe simply by checking for the presence of that secret and skipping the workflow if it isn't) it would avoid confusion and reduce the noise.

[9401adarsh]

keycloak/keycloak#13268

I found something similar regarding the snyk issue. It suggests to run the snyk workflow only if the PR comes from a cloned copy of the original repo rather than a fork.

[rugk]

Just tried to apply this, but apparently already fixed in b32efe0 (@elrido dunno maybe PRs would be useful also for finding changes, master pushes are always hmm…)