No UI indication for more than 10 fingerprint enrolling progress

[Alex Tu]

There is no progress information shows to user while enrolling fingerprint if the number of required enrollment steps is greater than 10.
It might confuse user thinking it as freeze failure.

Also it's not possible to enroll more than one finger.

steps:
1. enroll fingerprint in gnome-control-center
2. click 'Next' on the enrolling page
3. There is no message tell user that it need at least 12 times touching fingerprint.
4. user press fingerprint for 5 times, there is no way to cancel enrolling.
5. user wait for timeout and get error message for timeout notification.
6. after 5. user page of setting will always failed and show no user found.

And this also introduce some critical issue of step 6 that user page in settings failed forever.

However if the enrollment succeeds:
7. If trying to add a new fingerprint, the user is forced to delete its enrolled prints

So, the suggestion would be:
1. remind user to press 12 times on fingerprint for step 3.
2. show the progress during user pressing fingerprint for step 4.
3. Allow to enroll more fingers

As per this, GNOME design has produced some artwork that we want to implement to fix all these issues:
 - https://gitlab.gnome.org/Teams/Design/settings-mockups/-/issues/18

There will be few new strings, although most of the action events are already covered by the fprintd translations.

UI will change quite a lot, but the current documentation [1] should not be affected by the change, being quite generic, but in case it might be updated to be clearer.

[1] https://help.ubuntu.com/19.10/ubuntu-help/session-fingerprint.html

----

ProblemType: BugDistroRelease: Ubuntu 20.04
Package: gnome-control-center 1:3.35.91-0ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18
Uname: Linux 5.4.0-14-generic x86_64
ApportVersion: 2.20.11-0ubuntu18
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Mar 3 16:44:13 2020
InstallationDate: Installed on 2020-03-02 (1 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200301)SourcePackage: gnome-control-center
UpgradeStatus: No upgrade log present (probably fresh install)

[Alex Tu (alextu)]

user page in setting failed forever after fingerprint enrolling time out.

[Alex Tu (alextu)]

after user click 'Next', there is no message remind user the progress of fingerprint enrollment.
And also no reminder for the necessary of 12 times finger pressing.

[Sebastien Bacher (seb128)]

Thank you for your bug report. Is the 5 vs 12 a driver difference? Which driver are you using?
On the test lenovo test laptop Marco is using with synaptic there are an UI displayed which updates each time a fingerprint swipe is validated, it's not the case for you? Could you maybe do a screencast of the full enrolling process you are experiencing?

[Alex Tu (alextu)]

I just also verified on Lenovo X230 with fingerprint device 147e:2020
the UI indication for fingerprint enrolling progress looks good.
So, I'm wondering if the issue is caused by private built IHV proprietary driver + libfprintd pkgs.
I will check it again while get the latest IHV driver which built with latest V1.90.1+tod1.

[Alex Tu (alextu)]

from the latest IHV driver, it seems the requested enroll stage (12) exceeds MAX_ENROLL_STAGES (10). I'm trying to extend MAX_ENROLL_STAGES but it seems still failed.

It's puzzle to me for now that who provided the 12 times requesting and why it failed to exceed MAX_ENROLL_STAGES.

[Alex Tu (alextu)]

after IHV changed the driver, the UI indication shows during enrollment.
It caused by the driver holding signals untile enrollment done.

But there's still an issue that will confuse the user that IHV driver asks for 12 enrollments but the MAX_ENROLL_STAGES is 10. This means the UI indication of the final 2 enrollments is hidden.

I feel we should extend MAX_ENROLL_STAGES to 20 or 30 and should not restrict the number of enrollments needed by the FP driver.

[Iain Lane (laney)]

I'd like to hear from the documentation team now if this has any UIF implications (please mail their list), but I think from the release team POV it's a bit premature to be considering this - the unknown nature of the change (code size) and it not being ready yet means we can't really assess the change based on the current information.

I'd say: once this is ready to go, please come back to us again and we can see where we are in the release cycle vs. the risk. It might for example be that this should be SRUed to have additional and explicit verification.

[Gunnar Hjalmarsson (gunnarhj)]

The applicable doc page is an upstream one. I assume this will make it upstream sooner or later, and that the doc page will be modified if needed, even if the latter step will lag a bit. The proposed change is not important enough to create a temporary Ubuntu specific page. So from a docs POV this is fine.

As regards translatable strings: Even if they exist in fprintd, the translations won't automatically move to the gnome-control-center-2.0 translation domain. Therefore, whether it's uploaded before the release or afterwards as an SRU, please notify the translators on the ubuntu-translators list as soon as the new g-c-c strings are available for translation in LP.

[Marco Trevisan (Treviño) (3v1n0)]

Gunnar, the strings in case will stay in fprind anyways, as we get them through dbus.

However, sure I will notify for the new ones.

Laney, I did sent the message to the documentation list, but my message is under moderation, so I hope someone would moderate it.

[Gunnar Hjalmarsson (gunnarhj)]

On 2020-03-26 17:13, Marco Trevisan (Treviño) wrote:
> Gunnar, the strings in case will stay in fprind anyways, as we get
> them through dbus.

Ok, then I misunderstood that part.

> However, sure I will notify for the new ones.

Good.

> Laney, I did sent the message to the documentation list, but my
> message is under moderation, so I hope someone would moderate it.

It got through - it's because of that message I'm here. :)

[Marco Trevisan (Treviño) (3v1n0)]

So all the work is implemented here:
  - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/741

So and that diff can be considered as the one needed to fix this bug, there are less than 20 new strings added.

[Sebastien Bacher (seb128)]

Thanks Marco, that looks great but it's a bit late now for such change. We should probably try to get that into a SRU once it has been reviewed upstream, what do you think?

If we do postpone should we include at least the bump of the enroll counter suggested in comment #8?

[Iain Lane (laney)]

Agreed, doing a proper round of review / testing on this would be best. I'll unsubscribe the release team from this bug, thanks!

(btw, the UI looks great!)

[Marco Trevisan (Treviño) (3v1n0)]

> Thanks Marco, that looks great but it's a bit late now for such change. We should probably try to get that into a SRU once it has been reviewed upstream, what do you think?

Yeah, given that the change was not a small one, I was expecting to be more SRU material at this point.

Nevertheless I'm quite confident with this code as it has been tested quite heavily, but indeed I'd prefer not to be too different to what I'd like to have upstream as well.

> If we do postpone should we include at least the bump of the enroll counter suggested in comment #8?

Ok, I can look at that as well; that would only fix the "no-dialog" shown issue, though while not the ability to enroll multiple fingers to have a proper identification (in the current state only the first finger, in no clear order is considered).

However I'd say we also need
 https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/727

As some divers might cause hanging.

[Marco Trevisan (Treviño) (3v1n0)]

Ok, I've also fixed the limited number of enroll of the current UI (still available as part of the gnome-control-center!727 MR), so that is enough to fix the first part of this bug.

As per ubuntu, I've the packaging bits ready at https://salsa.debian.org/gnome-team/gnome-control-center/-/merge_requests/15 so let me know whether I should proceed with that.

[Marco Trevisan (Treviño) (3v1n0)]

Moved the multiple-fingers enrollment part to https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1873298 as this one will be fixed by g-c-c release.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-control-center - 1:3.36.1-1ubuntu5

---------------
gnome-control-center (1:3.36.1-1ubuntu5) focal; urgency=medium

  * debian/patches/git-info-crash-on-nvidia.patch:
    - backport a fix for an info panel segfault on nvidia cards
      (lp: #1870737)
  * debian/patches/git-nongnome-segfault.patch:
    - don't segfault when started outside of GNOME (lp: #1870735)

  [ Marco Trevisan ]
  * d/p/0028-user-panel-Add-reference-to-selected-user-and-clear-.patch,
  * d/p/0029-user-panel-Don-t-wait-for-fprintd-on-initialization.patch,
    d/p/0030-fingerprint-dialog-Don-t-use-sync-calls-for-deleting.patch,
    d/p/0031-fingerprint-dialog-Don-t-limit-the-number-of-maximum.patch:
    - Don't wait for fprintd on initialization and don't limit enroll stages
      (lp: #1865845)

  [ Robert Ancell ]
  * debian/patches/0027-window-Stop-using-HdyLeaflet.patch:
    - Disable adaptive layouts, theres some bugs and they're not required on
      desktop (LP: #1871195)
  * debian/patches/0028-applications-Fix-only-connected-snap-interfaces-show.patch:
    - Fix disconnected snap interfaces not showing (LP: #1870600)
  * debian/patches/0029-applications-Use-new-snapd-glib-API-for-labelling-Sn.patch:
  * debian/control:
    - Use shared names for snap interfaces, fixing some interfaces that don't
      have labels.

  [ Gunnar Hjalmarsson ]
  * debian/patches/0030-temporarily-revert-alt-char-key.patch:
    - Revert the "Alternate Characters Key" commit temporarily awaiting
      a proper fix of LP: #1867548.

 -- Sebastien Bacher <email address hidden> Thu, 16 Apr 2020 12:30:37 +0200