Re: [Edbrowse-dev] Disabling local echo for password fields

[Dominique Martinet <asmadeus@codewreck.org>]

Chris Brannon wrote on Wed, Jul 12, 2017:
> I think the itype_minor idea is a good one, because all these minor
> types are just text for the purposes of edbrowse.  We can add new
> ones if we ever need to do that; they'll still be handled as text.
> The thing I'm a little concerned about is the loss of information.
> I didn't really think this through when I read your patches yesterday.
> When ipass is used successfully to edit a form field, its itype_minor
> automatically becomes INP_PW.  That loses the old itype_minor.  There
> may be cases where we need it, E.G., for the DOM.
> For instance, what if some JS code needs to find the fields having type
> "email"?  This is a bit contrived.

Right, I do not think code ought to rely on that (as they should use the
field id) but that does not mean such does not exist, we probably should
preserve this when needed.
On the other hand, I do not think people would use 'ipass' to enter
their email address, but I want to see the output masked when someones
uses ipass just in case some website "forgot" to set the password type.


What occured to me when writing the user guide part is that there is no
going back from this either, once a field has been set as password you
can still manipulate it with substitutions but you will not ever be able
to see the result.
There is no "unmask" or "print anyway" command that would do that.

I am not sure how much this would be useful in practice, though, so it
is probably OK to put this on some "maybe later" list...


> Perhaps we should add a "maskedText" flag to struct htmlTag, set that in
> ipass, and use it to determine whether or not to print the stars for
> masked fields?  Or maybe my concern is overblown, I don't know.

It is probably cleaner to keep it separate and having an extra bit
should not hurt much, I will go for that and submit a new revision
tonight or tomorrow.


> Sorry for being a harsh reviewer.  I really do like your work,
> and I want to see it merged.

No worry, I am used to much worse and this is better than accepting new
bugs too easily :)

-- 
Dominique