Feature request: Kill readonly on password form fields

[cemeyer]

Here is an example element from treasurydirect.gov's login page, as of today:

<input type="password" autocomplete="off" readonly="readonly" ...>

Paste / browser autofill is fucked with by autocomplete=off (do browsers ignore this now?) and readonly="readonly". Given both of these attributes are nonsensical for input elements with type password, does it make sense for this extension to unfuck them?

Thanks!

[jswanner]

@cemeyer, I tried to find the login page you are referring to but failed to do so. Can you provide a link so I have better context of what you are referring to?

I'm not sure what the purpose of a readonly password field is, seemingly you can't see the value since it's a password field, and if it's readonly you can't change the value. I'm also not sure what the point of making the field editable would be, if they are not wanting you to change the value.

There are many ways in which a site's creator can do some really stupid stuff, I don't really see this extension's purpose to fix all ills. I think it's probably more appropriate to use something like Tampermonkey to make the adjustments you want for any particular site, such as this one.

[cemeyer]

I tried to find the login page you are referring to but failed to do so. Can you provide a link so I have better context of what you are referring to?

https://www.treasurydirect.gov/RS/PW-Display.do is the URL, but you need to enter a valid user id first to get to it.

I'm not sure what the purpose of a readonly password field is, seemingly you can't see the value since it's a password field, and if it's readonly you can't change the value.

The readonly field is intended to be edited by a javascript QWERTY keyboard. Yes, it's about as awful as it sounds. Here's a screenshot:

I'm also not sure what the point of making the field editable would be, if they are not wanting you to change the value.

They want you to fill your password.

There are many ways in which a site's creator can do some really stupid stuff, I don't really see this extension's purpose to fix all ills.

Understood, but I think this falls pretty squarely in "fucking with paste." If you decide it's out of scope, that's ok.

Cheers, Conrad

[jswanner]

Oh no, is this some kind of trend? Someone recently brought up https://online.adcb.com/ADCBIB/kdw#_frmLogin, which has a similar "virtual keyboard."

Understood, but I think this falls pretty squarely in "fucking with paste." If you decide it's out of scope, that's ok.

I would say it's more like they are fucking with typing, along with many norms of the web. This extension really just deals with paste events specifically (well, and copy & cut events)/

For instance, this extension doesn't try to circumvent a site that blocks paste via interfering with the key presses used to initiate a paste event (cmd+p/ctrl+p) -- in that case this extension would still allow for "Edit" -> "Paste" from the browser's menu at least. And, the reason being: the extension would need to intercept every key press event in that case, which is out of the scope of where I'd want this extension to go.

It would be very difficult for this extension to try to "unfuck" every input field without it unintentionally fucking up other things. That's why I would suggest something else like Tampermonkey, that way it could be very targeted with the alterations -- do x, y & z to this field on this page .

[cemeyer]

It would be very difficult for this extension to try to "unfuck" every input field without it unintentionally fucking up other things.

Well, sure, but that's why there is a site whitelist, right? :-)

I'm ok taking the tampermonkey approach if you still think it's out of scope.

[jswanner]

Well, sure, but that's why there is a site whitelist, right? :-)

I think if this extension were to get involved with other DOM events (keyboard & mouse) along with DOM manipulation (such as removing readonly attributes), the configuration would need to be much more granular: declaring which intervention the extension should take for each site. But, I also think that would be adding too much complexity and would be overly cumbersome for rare benefit.

Granted, I whole-heartedly agree that what that site is doing is nonsensical and deserves to be undone; I also can't imagine that it is accessible to those using screen readers and the like. Unfortunately, it's not something I want to handle with this extension. Thanks for bringing it to my attention none the less.

[cemeyer]

That's fair — thanks for considering it.

[nitrocode]

Ah nuts, I was about to post the exact same thing for the exact same website... I thought that the intent of this website was to be able to paste passwords from password managers so anything that blocks that would be in scope.

Do we need a new extension called "Don't fucking add readonly to password fields" ? :joy:

[jswanner]

I thought that the intent of this website was to be able to paste passwords from password managers so anything that blocks that would be in scope.

That's a fair criticism. And, yes, pasting passwords is certainly one of the use cases for this extension.

I use 1Password's browser extension for filling in passwords all the time (which doesn't rely on pasting, instead modify's the field's value directly), I highly doubt their extension would be able to fill in the password on treasurydirect.gov's site, and I wouldn't really call that a problem with the extension but rather just a really messed up site.

This extension is currently focused on the very specific copy, cut & paste browser events, which for a whole lot of sites that try to block those commands is all you need. There are other sites that also interfere with contextmenu (right-click) and keyboard shortcuts. While I have considered expanding the extension to cover those issues as well, it feels like a lot of work for diminishing return, while greatly increasing the potential unintended consequences of using this extension. Some of those concerns I mentioned earlier in this issue:

I think if this extension were to get involved with other DOM events (keyboard & mouse) along with DOM manipulation (such as removing readonly attributes), the configuration would need to be much more granular: declaring which intervention the extension should take for each site. But, I also think that would be adding too much complexity and would be overly cumbersome for rare benefit.

Removing readonly attributes from password fields (while technically an easy task) feels very different from the rest of what this extension does. It's already the case that the amount of code that actually "unfucks" paste is insanely small (4 lines, but really 2 lines) but there's so much more code in this extension that exists to control when to activate the "unfucking" code.

If you all are going to treasurydirect.gov frequently, and having to deal with its readonly password field all the time, then I think having a content script extension just for that is much easier. I can give you all the code you need for that, it would be 2 small files. It's not something I would want to publish to the Chrome Web Store without configuration support this extension has; but having local extensions installed to deal with specific problems like this is what I've done in the past, it's how this extension came to be originally.

[nitrocode]

@jswanner Ok, thank you for considering it. Perhaps it would be easier to ask treasurydirect.gov not to hinder us or do as what you and @cemeyer suggest, which is to use a tampermonkey script to remove the readonly attribute.

No need to contribute the script for this. If you have it already, please feel free to add it to userscripts or similar site and share the link. Thanks again.