[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #46410] [Gorm] secure textfield in NIB -> Gorm conversion
From: |
Gregory John Casamento |
Subject: |
[bug #46410] [Gorm] secure textfield in NIB -> Gorm conversion |
Date: |
Sun, 29 Oct 2017 19:59:54 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (iPhone; CPU iPhone OS 11_0_3 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/62.0.3202.70 Mobile/15A432 Safari/604.1 |
Follow-up Comment #2, bug #46410 (project gnustep):
When reverse engineering the nib files I noticed there were a lot of errors
which Apple had made in encoding. The nib in question is, I believe from
10.4. Examples of such errors are name mispellings and etc some of which are
compensated for in the nib decoding Logic. I believe this is such a case
where the cell is never coded in IB as a secure cell and during deciding it
should just be assumed that it is. Thus this is not a perfect solution in
the general case as it means that the developer can’t explicitly set a class
which is different than the one which is assumed to go with the field type.
I believe the solution here is to make the assumption that if we are decoding
a secure text field that a secure cell should be provided. Why this was not
done by Apple is beyond me, but it nevertheless was not. Riccardo and I have
dug deeply into this issue in the past.
I will create a pull request for this and you guys can review it and decide
whether it is good or not. The challenge has been making this change function
in the general case. I believe I might have a solution that will address
this.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?46410>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/