| 2015-07-28 15:24:35 |
Wise Melon |
bug |
|
|
added bug |
| 2015-07-28 15:25:07 |
Wise Melon |
tags |
|
gnome3 |
|
| 2015-07-28 23:30:26 |
Tim Lunn |
bug task added |
|
ubuntu-gnome |
|
| 2015-07-28 23:30:34 |
Tim Lunn |
ubuntu-gnome: milestone |
|
wily |
|
| 2015-07-28 23:36:33 |
Tim Lunn |
affects |
gdm (Ubuntu) |
gnome-shell (Ubuntu) |
|
| 2015-07-28 23:36:33 |
Tim Lunn |
gnome-shell (Ubuntu): importance |
Undecided |
Low |
|
| 2015-07-28 23:36:33 |
Tim Lunn |
gnome-shell (Ubuntu): status |
New |
Triaged |
|
| 2015-07-28 23:36:43 |
Tim Lunn |
ubuntu-gnome: status |
New |
Triaged |
|
| 2015-07-28 23:36:47 |
Tim Lunn |
ubuntu-gnome: importance |
Undecided |
Low |
|
| 2015-07-28 23:37:26 |
Tim Lunn |
nominated for series |
|
Ubuntu Vivid |
|
| 2015-07-28 23:37:26 |
Tim Lunn |
bug task added |
|
gnome-shell (Ubuntu Vivid) |
|
| 2015-07-29 09:01:09 |
Wise Melon |
bug watch added |
|
https://bugzilla.gnome.org/show_bug.cgi?id=753004 |
|
| 2015-07-29 09:09:21 |
Wise Melon |
bug watch added |
|
https://bugzilla.gnome.org/show_bug.cgi?id=752739 |
|
| 2015-07-31 15:35:59 |
Thomas Ward |
gnome-shell (Ubuntu Vivid): importance |
Undecided |
Low |
|
| 2015-07-31 15:35:59 |
Thomas Ward |
gnome-shell (Ubuntu Vivid): status |
New |
Triaged |
|
| 2015-07-31 15:40:26 |
Wise Melon |
attachment added |
|
lp1479014_vivid_v1.debdiff https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1479014/+attachment/4437034/+files/lp1479014_vivid_v1.debdiff |
|
| 2015-07-31 16:23:29 |
Ubuntu Foundations Team Bug Bot |
tags |
gnome3 |
gnome3 patch |
|
| 2015-07-31 16:23:36 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2015-07-31 17:17:10 |
Wise Melon |
tags |
gnome3 patch |
gnome3 |
|
| 2015-07-31 19:10:25 |
Thomas Ward |
tags |
gnome3 |
gnome3 patch |
|
| 2015-07-31 20:22:53 |
Wise Melon |
description |
I am running Ubuntu Gnome 15.04, and I have recently noticed that when logging in (not from suspend), if I click on "Not listed?", it takes me to a place where I can enter the username, but if I have navigated to this place accidentally, if I press "Cancel" nothing happens, until I press "Next", then the little cog appears, and the "Cancel" button functions as it should.
So I am filing this bug report as I should not need to press "Next", to get the cog, and the "Cancel" button functioning normally.
---
OS Information:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid
Package Information:
gdm:
Installed: 3.14.1-0ubuntu3
Candidate: 3.14.1-0ubuntu3
Version table:
*** 3.14.1-0ubuntu3 0
500 http://gb.archive.ubuntu.com/ubuntu/ vivid/universe amd64 Packages
100 /var/lib/dpkg/status |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug1: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug2: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug3: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug1 fix: Reset "Next" button to "Next" when asking for username.
- Bug2 fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug3 fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug1: I am terribly sorry but this is a bug is not one that I have been experiencing, even though I was asked to include the patch for this one. So I cannot write detailed instructions on how to reproduce it, because I'm not so clear on how to reproduce it myself. So somebody else will have to fill out this section.
- Reproduce Bug2:
On the login screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug3:
On the login screen click "Sign In", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced the bug. |
|
| 2015-07-31 20:23:36 |
Wise Melon |
description |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug1: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug2: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug3: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug1 fix: Reset "Next" button to "Next" when asking for username.
- Bug2 fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug3 fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug1: I am terribly sorry but this is a bug is not one that I have been experiencing, even though I was asked to include the patch for this one. So I cannot write detailed instructions on how to reproduce it, because I'm not so clear on how to reproduce it myself. So somebody else will have to fill out this section.
- Reproduce Bug2:
On the login screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug3:
On the login screen click "Sign In", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced the bug. |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug-1: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug-2: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug-3: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug-1 fix: Reset "Next" button to "Next" when asking for username.
- Bug-2 fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug-3 fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug-1: I am terribly sorry but this is a bug is not one that I have been experiencing, even though I was asked to include the patch for this one. So I cannot write detailed instructions on how to reproduce it, because I'm not so clear on how to reproduce it myself. So somebody else will have to fill out this section.
- Reproduce Bug-2:
On the login screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug-3:
On the login screen click "Sign In", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced the bug. |
|
| 2015-07-31 20:24:02 |
Wise Melon |
description |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug-1: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug-2: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug-3: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug-1 fix: Reset "Next" button to "Next" when asking for username.
- Bug-2 fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug-3 fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug-1: I am terribly sorry but this is a bug is not one that I have been experiencing, even though I was asked to include the patch for this one. So I cannot write detailed instructions on how to reproduce it, because I'm not so clear on how to reproduce it myself. So somebody else will have to fill out this section.
- Reproduce Bug-2:
On the login screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug-3:
On the login screen click "Sign In", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced the bug. |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug 1: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug 2: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug 3: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug 1 fix: Reset "Next" button to "Next" when asking for username.
- Bug 2 fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug 3 fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug-1: I am terribly sorry but this is a bug is not one that I have been experiencing, even though I was asked to include the patch for this one. So I cannot write detailed instructions on how to reproduce it, because I'm not so clear on how to reproduce it myself. So somebody else will have to fill out this section.
- Reproduce Bug 2:
On the login screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug 3:
On the login screen click "Sign In", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced the bug. |
|
| 2015-08-01 13:27:35 |
Wise Melon |
description |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug 1: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug 2: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug 3: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug 1 fix: Reset "Next" button to "Next" when asking for username.
- Bug 2 fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug 3 fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug-1: I am terribly sorry but this is a bug is not one that I have been experiencing, even though I was asked to include the patch for this one. So I cannot write detailed instructions on how to reproduce it, because I'm not so clear on how to reproduce it myself. So somebody else will have to fill out this section.
- Reproduce Bug 2:
On the login screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug 3:
On the login screen click "Sign In", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced the bug. |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug. |
|
| 2015-08-01 14:00:17 |
Wise Melon |
summary |
"Cancel" button does not work at first when selecting user that is not listed on login screen |
"Cancel", "Next", and "Sign In" functioning incorrectly on login or locked screen in "Sign In?" section |
|
| 2015-08-05 13:46:19 |
Wise Melon |
description |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug. |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug.
[Regression potential]
As these patches have already been put to practical use in the upstream version, and the patches which have been put to use in this version, have originated from those patches, I would say that the risk of regression is minimal. |
|
| 2015-08-10 14:49:28 |
Wise Melon |
description |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug.
[Regression potential]
As these patches have already been put to practical use in the upstream version, and the patches which have been put to use in this version, have originated from those patches, I would say that the risk of regression is minimal. |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug.
[Regression Potential]
1. You may notice that we only fade the authentication prompt back in if the auth prompt status is "VERIFICATION_SUCCEEDED". It's possible for it to be "NOT_VERIFYING" if the authprompt gets reset for some other reason in the interim.
2. You may also notice that the user session crashes when the login screen is reactivated. |
|
| 2015-08-10 14:55:24 |
Wise Melon |
bug watch added |
|
https://bugzilla.gnome.org/show_bug.cgi?id=753181 |
|
| 2015-08-11 18:09:47 |
Wise Melon |
description |
[Impact]
There are three patches in this one fix. So there are three bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug.
[Regression Potential]
1. You may notice that we only fade the authentication prompt back in if the auth prompt status is "VERIFICATION_SUCCEEDED". It's possible for it to be "NOT_VERIFYING" if the authprompt gets reset for some other reason in the interim.
2. You may also notice that the user session crashes when the login screen is reactivated. |
[Impact]
There are five patches in this one fix. So there are five bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
- Bug [4]: If the authPrompt gets reset for some other reason in the interim, this would mean that we don't fade the authentication prompt back in when it is needed.
- Bug [5]: The user session will crash when the login screen is reactivated due to the fact that the previous the user verifier has not been cleared.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
- Bug [4] fix: loginDialog now only skips the fade-in if we have already fadded-in. It now also only skips resetting if we have already reset.
- Bug [5] fix: We now make sure that once the user verifier has completed its job (of user verification) that it gets cleared so that it does not get in the way later.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug.
- Reproduce Bug [4]:
Go to the login screen (or locked screen), reset the authentication prompt before you have reached "VERIFICATION_SUCCEEDED", and if you see that the prompt does not fade back in, then you have successfully reproduced this bug.
- Reproduce Bug [5]:
After you have logged in, go back to the login screen, if the user session crashes, then you have successfully reproduced this bug.
[Regression Potential]
As these patches have already been put to practical use in the upstream version, and the patches which have been put to use in this version, have originated from those patches, I would say that the risk of regression is minimal. |
|
| 2015-08-11 18:14:46 |
Wise Melon |
attachment added |
|
lp1479014_vivid_v2.debdiff https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1479014/+attachment/4443022/+files/lp1479014_vivid_v2.debdiff |
|
| 2015-08-11 22:49:37 |
Tim Lunn |
bug watch added |
|
https://bugzilla.gnome.org/show_bug.cgi?id=752438 |
|
| 2015-08-12 10:07:59 |
Wise Melon |
attachment added |
|
lp1479014_vivid_v3.debdiff https://bugs.launchpad.net/ubuntu/vivid/+source/gnome-shell/+bug/1479014/+attachment/4443308/+files/lp1479014_vivid_v3.debdiff |
|
| 2015-08-12 10:47:26 |
Wise Melon |
description |
[Impact]
There are five patches in this one fix. So there are five bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
- Bug [4]: If the authPrompt gets reset for some other reason in the interim, this would mean that we don't fade the authentication prompt back in when it is needed.
- Bug [5]: The user session will crash when the login screen is reactivated due to the fact that the previous the user verifier has not been cleared.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
- Bug [4] fix: loginDialog now only skips the fade-in if we have already fadded-in. It now also only skips resetting if we have already reset.
- Bug [5] fix: We now make sure that once the user verifier has completed its job (of user verification) that it gets cleared so that it does not get in the way later.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug.
- Reproduce Bug [4]:
Go to the login screen (or locked screen), reset the authentication prompt before you have reached "VERIFICATION_SUCCEEDED", and if you see that the prompt does not fade back in, then you have successfully reproduced this bug.
- Reproduce Bug [5]:
After you have logged in, go back to the login screen, if the user session crashes, then you have successfully reproduced this bug.
[Regression Potential]
As these patches have already been put to practical use in the upstream version, and the patches which have been put to use in this version, have originated from those patches, I would say that the risk of regression is minimal. |
[Impact]
There are five patches in this one fix. So there are five bugs which are fixed:
- Bug [1]: If the "Next" button ever gets set to "Sign In", it won't
get reset to next until the next question asked by pam.
- Bug [2]: Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
- Bug [3]: Users are not allowed to cancel if the verification has not started yet and they are typing in their username.
- Bug [4]: If the authPrompt gets reset for some other reason in the interim, this would mean that we don't fade the authentication prompt back in when it is needed.
- Bug [5]: The user session will crash when the login screen is reactivated due to the fact that the previous the user verifier has not been cleared.
- Bug [6]: (LP: #752220) We currently only cancel the user verifier on reset if verifying, but that means we don't properly cancel it when asking for a username at the "Not Listed" screen.
These are rather important things to be fixed as they make the login process more confusing and difficult.
How the bugs are fixed:
- Bug [1] fix: Reset "Next" button to "Next" when asking for username.
- Bug [2] fix: Disallow the user to press "Next" when the username field is empty up front.
- Bug [3] fix: authPrompt no longer ignores the request to cancel before a user has started verification and is still typing in their username.
- Bug [4] fix: loginDialog now only skips the fade-in if we have already faded-in. It now also only skips resetting if we have already reset.
- Bug [5] fix: We now make sure that once the user verifier has completed its job (of user verification) that it gets cleared so that it does not get in the way later.
- Bug [6] fix: We now unconditionally cancel if the user verifier has been reset.
[Test Case]
- Reproduce Bug [1]:
On the first login screen (or log out - not lock), click "Sign In?", then before doing anything else click "Sign In", if the button allows you to press it and is not greyed out, then you have successfully reproduced this bug.
- Reproduce Bug [2]:
On the locked screen click "Sign In?", then before doing anything else press "Cancel". If nothing happens, you have successfully reproduced this bug.
- Reproduce Bug [3]:
On the locked screen click "Sign In?", then in the username field, start entering your username (or any text), then instead of pressing "Next", press "Cancel", if nothing happens then you have successfully reproduced this bug.
- Reproduce Bug [4]:
Go to the login screen (or locked screen), reset the authentication prompt before you have reached "VERIFICATION_SUCCEEDED", and if you see that the prompt does not fade back in, then you have successfully reproduced this bug.
- Reproduce Bug [5]:
After you have logged in, go back to the login screen, if the user session crashes, then you have successfully reproduced this bug.
- Reproduce Bug [6]:
On the login screen go to the "Not Listed" section, and then attempt to cancel. If it does not let you, then you have successfully reproduced this bug.
[Regression Potential]
As these patches have already been put to practical use in the upstream version, and the patches which have been put to use in this version, have originated from those patches, I would say that the risk of regression is minimal. |
|
| 2015-09-16 13:00:02 |
Wise Melon |
attachment removed |
lp1479014_vivid_v1.debdiff https://bugs.launchpad.net/ubuntu/vivid/+source/gnome-shell/+bug/1479014/+attachment/4437034/+files/lp1479014_vivid_v1.debdiff |
|
|
| 2015-09-16 13:00:16 |
Wise Melon |
attachment removed |
lp1479014_vivid_v2.debdiff https://bugs.launchpad.net/ubuntu/vivid/+source/gnome-shell/+bug/1479014/+attachment/4443022/+files/lp1479014_vivid_v2.debdiff |
|
|
| 2015-10-17 21:54:27 |
Tim Lunn |
nominated for series |
|
Ubuntu Wily |
|
| 2015-10-17 21:54:27 |
Tim Lunn |
bug task added |
|
gnome-shell (Ubuntu Wily) |
|
| 2015-10-19 13:32:40 |
Launchpad Janitor |
gnome-shell (Ubuntu Wily): status |
Triaged |
Fix Released |
|
| 2015-10-28 07:02:18 |
Tim Lunn |
gnome-shell (Ubuntu Vivid): status |
Triaged |
Won't Fix |
|
| 2015-10-28 07:02:37 |
Tim Lunn |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2015-12-06 10:43:53 |
Bruce Pieterse |
ubuntu-gnome: status |
Triaged |
Fix Released |
|
