Comment 48 for bug 1765261

(In reply to Michael Catanzaro from comment #29)
> (In reply to Matthew Miller from comment #26)
> > I'm definitely reconsidering my -1. If we can verify that it's just the
> > first attempt and just the lockscreen/askpass, a zero-day would probably be
> > okay.
> >
> > I'll weight Michael Catanzaro and other Workstation team members' opinions
> > on this heavily — if they're not going to be embarrassed, I'll try not to
> > be. :)
>
> I think we should try to fix it ASAP, of course. But if we have a zero-day
> update, then users will hopefully only hit this bug once or twice at most,
> in which case they probably won't even notice.
>
> (In reply to J. Haas from comment #27)
> > I can verify that this also happens in the "create keyring" dialog in
> > Seahorse when setting a password for the keyring. It's not a huge problem,
> > as you need to enter the password twice and the problem only happens in the
> > topmost password box, but it's definitely annoying.
>
> OK, that changes everything. I have two thoughts on this:
>
> (a) Most of seahorse is already super broken and has been for a long time,
> that's why we don't install it anymore
> (b) That's a GTK+ dialog
>
> (b) is very significant because up until now, all the reported password
> entries were gnome-shell: that's why I reassigned the bug to gnome-shell.
> Now you're saying this affects GTK+ as well, right? I just tested with
> seahorse, and the password entry was a normal GTK+ dialog drawn by seahorse
> itself, not the black overlay that gnome-shell draws when it asks for your
> password? That's *really* seriously weird; it's hard to imagine what could
> break password entry in two unrelated toolkits. Maybe ibus?

I just tested this and it is NOT using the GTK+ dialog, it's using the GNOME Shell dialog. I'm not sure when that changed, but I hope that information is less alarming.