bugGNUstep - Bugs: bug #46410, [Gorm] secure textfield in NIB...


bug #46410: [Gorm] secure textfield in NIB -> Gorm conversion

Submitted by:  Riccardo Mottola <rmottola>
Submitted on:  Mon 09 Nov 2015 09:31:15 PM UTC  
Category:  Gorm Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  Gregory John Casamento <gcasa>
Open/Closed:  Closed

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sat 20 Apr 2019 09:35:15 AM UTC, comment #3: 

I just tested this on a nib made with 10.9.  I don't think this is an issue anymore.

Gregory John Casamento <gcasa>
Project AdministratorIn charge of this item.
Sun 29 Oct 2017 11:59:53 PM UTC, comment #2: 

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.

Gregory John Casamento <gcasa>
Project AdministratorIn charge of this item.
Sun 29 Oct 2017 09:08:07 AM UTC, comment #1: 

I understand what is happening here, but not why. What is happening:

A secure text field in a nib is stored as NSTextField with custom class set to NSSecureTextField. So when the nib is loaded, you start off with a text field and a text field cell.

There is code specifically designed to handle this case, in -gui: GSNibLoading.m has -[NSClassSwapper unarchiver:didDecodeObject:] which is explicitly documented to handle the NSSecureTextFieldCell case. It tests for whether the new class responds to +cellName and replaces the cell object if so.

What I see in that method is that _originalClassName is NSSecureTextField, but newClass is NSTextField so +[newClass cell] returns NSTextFieldCell, and that is what gets set on the nib.

I understand that reversing the sense of that test fixes the problem, but do not understand that code well enough to know why that should be so or what other effects would result.

Graham Lee <leeg>
Mon 09 Nov 2015 09:31:15 PM UTC, original submission:  

In the same PasswordPanel.nib of GNUMail, the secure text field is interpreted as such (and can be checked in the inspector) however once run, I see:

NSTextFieldCell(instance) does not recognize setEchosBullets:

I suppose thus that the Field class is correct, but not the underlying TextFieldCell, which is a normal one and not a Secure one.

Riccardo Mottola <rmottola>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by leeg (Posted a comment)
  • -email is unavailable- added by rmottola (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-04-20 gcasa StatusNone => Fixed
        Open/ClosedOpen => Closed

    Back to the top

    Powered by Savane 3.5