STEPS TO REPRODUCE:

 1. Run an application showing a GtkEntry with 'visibility' property set to FALSE, meant
     to be used to capture a password from the user (e.g. gtk3-demo, in "Entry" > "Entry buffer")
 2. Type some text in the password field, which will display that text masked (e.g. "******")
 3. Try to access the text in that field through Assistive Technologies (e.g. Orca, Accerciser), by
     using one of the following functions from the AtkInterface:
        - atk_text_get_text()
        - atk_text_get_text_before_offset()
        - atk_text_get_text_at_offset()
        - atk_text_get_text_after_offset()

EXPECTED OUTCOME:

Providing the password field is not empty, you should be getting the actual "masked" string being displayed in the field when calling any of those functions with the right parameters.

For instance, if you typed "12345" in the password field, atk_text_get_text (accessible, 0, -1) should return something like "*****" (where 'accessible' is the instance of GtkEntryAccessible for that instance of GtkEntry)

ACTUAL OUTCOME:

Whenever you call any of those functions over that instance of GtkEntryAccessible, you always get an empty string, as it's hardcoded to be like that in the code:

   static gchar *
   gtk_entry_accessible_get_text (AtkText *atk_text,
                                                  gint start_pos,
                                                  gint end_pos)
   {
      [...]

      /* FIXME: is this acceptable ? */
     if (!gtk_entry_get_visibility (GTK_ENTRY (widget)))
       return g_strdup ("");

      text = gtk_entry_get_text (GTK_ENTRY (widget));
      [...]
   }

Btw, this problem is also causing that no proper "text-change"/"text-insert"/text-remove" signal is being emitted whenever the user inserts/removes new characters in those password fields, making impossible for users of ATs to realize that something happened in there.

I know just exposing the number of characters for a password might be considered a security hole, but from the point of view of ATs like Orca I think it's very interesting to be able to actually deal with these kind of input fields as if they were any other of entries, so users of ATs can interact with those kind of fields in a proper way. For what is worth, this is what Firefox does already for <input type="password"> fields and what we are planning to do in WebKitGTK+ (patch not landed yet)

Adding Piñeiro and Joanmarie Diggs to CC since I'm sure they will be interested in tracking this bug down (and maybe in adding some extra info here)

I'll be attaching a patch soon