From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) by hurricane.the-brannons.com (Postfix) with ESMTPS id D0A517A4D9 for ; Wed, 12 Jul 2017 05:54:55 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 1001) id D3F6CC01B; Wed, 12 Jul 2017 14:55:42 +0200 (CEST) Date: Wed, 12 Jul 2017 14:55:27 +0200 From: Dominique Martinet To: Edbrowse-dev@lists.the-brannons.com Message-ID: <20170712125527.GB2295@nautica> References: <20170703051927.GA1994@nautica> <20170709144030.GA24038@nautica> <20170609174513.eklhad@comcast.net> <20170710045636.GA3943@nautica> <87tw2joaop.fsf@the-brannons.com> <20170712061115.GA3270@nautica> <874luhon6h.fsf@the-brannons.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <874luhon6h.fsf@the-brannons.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Edbrowse-dev] Disabling local echo for password fields X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 12:54:56 -0000 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