| 2019-07-30 02:45:10 |
Matthew Ruffell |
bug |
|
|
added bug |
| 2019-07-30 02:45:20 |
Matthew Ruffell |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-07-30 02:45:20 |
Matthew Ruffell |
bug task added |
|
ibus (Ubuntu Bionic) |
|
| 2019-07-30 02:45:37 |
Matthew Ruffell |
ibus (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-07-30 02:45:43 |
Matthew Ruffell |
ibus (Ubuntu Bionic): assignee |
|
Matthew Ruffell (mruffell) |
|
| 2019-07-30 02:45:47 |
Matthew Ruffell |
ibus (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2019-07-30 02:47:08 |
Matthew Ruffell |
description |
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell and Firefox
both freeze and the system becomes unusable. If you ssh into the system and
terminate Firefox, gnome-shell unfreezes.
This only happens when the environment variable GTK_IM_MODULE is set to "ibus".
If you unset the variable, or change it to GTK_IM_MODULE=gtk-im-context-simple
and then start Firefox, everything works as intended.
This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
1.5.17-3ubuntu4 and Firefox versions starting with 68.0+build3-0ubuntu0.18.04.1
Note: Chrome[ium] and other applications do not trigger it, and it cannot be
reproduced in other desktop environments.
This seems to be an interaction issue between ibus and gnome-shell.
[Fix]
When ibus is built with the patch ibus-xx-f19-password.patch which was dropped
in ibus-1.5.17-2, the problem is solved.
ibus-xx-f19-password.patch checks to see if the GTK version is at or above 3.6,
and if it is, checks to see if the input purpose is for a password field. If it
is, then no further action is taken by ibus.
[Testcase]
Launch firefox from within a gnome-session, making sure the GTK_IM_MODULE is set
to "ibus". Note, this is the default value.
$ env GTK_IM_MODULE="ibus" firefox
Navigate to any website which has a password field. Wikipedia or Reddit will do.
Click a password field and attempt to enter text. Firefox and gnome-shell both
lock up and stay frozen for an extended period of time.
With the test package which includes ibus-xx-f19-password.patch, gnome-shell
and Firefox do not lock up and everything works as intended.
Test package is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test
[Regression Potential]
This has a low to medium risk of regression, and is limited to inputs to
password fields in all applications, including the gnome-shell lock screen.
This patch has been extensively tested and it is present in the following Ubuntu
releases:
artful: 1.5.14-2ubuntu1
zesty: 1.5.14-2ubuntu1
yakkety: 1.5.11-1ubuntu3
xenial: 1.5.11-1ubuntu2
wily: 1.5.10-1ubuntu1
vivid: 1.5.9-1ubuntu3
utopic: 1.5.8-2ubuntu2
trusty: 1.5.5-1ubuntu3.2
The patch was introduced in trusty, and removed in bionic. I feel that the risk
of reintroducing the patch is low, since the use case of the software is the
same as previous releases in regards to input software and input language
selection.
I still acknowledge a potential risk of regression when users change their
input engines to non defaults and pair it with non default input languages.
In the event of regression ibus can be temporarily be disabled via an environment
variable and the patch dropped in any subsequent packages.
[Notes]
This patch will not be needed in newer versions of ibus as an official
workaround has been implemented as of ibus-1.5.19.
https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
If problems arise with password input fields in ibus versions 1.5.19 or later,
which are found in cosmic onward, environment variables can be set that have
the same effect as ibus-xx-f19-password.patch.
env IBUS_DISCARD_PASSWORD=1 firefox
or
export IBUS_DISCARD_PASSWORD_APPS='firefox,.*chrome.*' |
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell and Firefox both freeze and the system becomes unusable. If you ssh into the system and terminate Firefox, gnome-shell unfreezes.
This only happens when the environment variable GTK_IM_MODULE is set to "ibus". If you unset the variable, or change it to
GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works as intended.
This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
1.5.17-3ubuntu4 and Firefox versions starting with 68.0+build3-0ubuntu0.18.04.1
Note: Chrome[ium] and other applications do not trigger it, and it cannot be
reproduced in other desktop environments.
This seems to be an interaction issue between ibus and gnome-shell.
[Fix]
When ibus is built with the patch ibus-xx-f19-password.patch which was dropped in ibus-1.5.17-2, the problem is solved.
ibus-xx-f19-password.patch checks to see if the GTK version is at or above 3.6, and if it is, checks to see if the input purpose is for a password field. If it is, then no further action is taken by ibus.
[Testcase]
Launch firefox from within a gnome-session, making sure the GTK_IM_MODULE is set to "ibus". Note, this is the default value.
$ env GTK_IM_MODULE="ibus" firefox
Navigate to any website which has a password field. Wikipedia or Reddit will do.
Click a password field and attempt to enter text. Firefox and gnome-shell both lock up and stay frozen for an extended period of time.
With the test package which includes ibus-xx-f19-password.patch, gnome-shell
and Firefox do not lock up and everything works as intended.
Test package is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test
[Regression Potential]
This has a low to medium risk of regression, and is limited to inputs to
password fields in all applications, including the gnome-shell lock screen.
This patch has been extensively tested and it is present in the following Ubuntu releases:
artful: 1.5.14-2ubuntu1
zesty: 1.5.14-2ubuntu1
yakkety: 1.5.11-1ubuntu3
xenial: 1.5.11-1ubuntu2
wily: 1.5.10-1ubuntu1
vivid: 1.5.9-1ubuntu3
utopic: 1.5.8-2ubuntu2
trusty: 1.5.5-1ubuntu3.2
The patch was introduced in trusty, and removed in bionic. I feel that the risk of reintroducing the patch is low, since the use case of the software is the same as previous releases in regards to input software and input language
selection.
I still acknowledge a potential risk of regression when users change their
input engines to non defaults and pair it with non default input languages.
In the event of regression ibus can be temporarily be disabled via an environment variable and the patch dropped in any subsequent packages.
[Notes]
This patch will not be needed in newer versions of ibus as an official
workaround has been implemented as of ibus-1.5.19.
https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
If problems arise with password input fields in ibus versions 1.5.19 or later, which are found in cosmic onward, environment variables can be set that have the same effect as ibus-xx-f19-password.patch.
env IBUS_DISCARD_PASSWORD=1 firefox
or
export IBUS_DISCARD_PASSWORD_APPS='firefox,.*chrome.*' |
|
| 2019-07-30 02:47:17 |
Matthew Ruffell |
tags |
|
sts |
|
| 2019-07-30 03:03:16 |
Matthew Ruffell |
attachment added |
|
ibus debdiff for bionic https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1838358/+attachment/5279953/+files/lp1838358_bionic.debdiff |
|
| 2019-07-30 03:07:52 |
Matthew Ruffell |
tags |
sts |
sts sts-sponsor |
|
| 2019-07-30 03:27:20 |
Launchpad Janitor |
ibus (Ubuntu): status |
New |
Confirmed |
|
| 2019-07-30 04:29:33 |
Ubuntu Foundations Team Bug Bot |
tags |
sts sts-sponsor |
patch sts sts-sponsor |
|
| 2019-07-30 04:29:41 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2019-08-01 04:33:07 |
Matthew Ruffell |
description |
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell and Firefox both freeze and the system becomes unusable. If you ssh into the system and terminate Firefox, gnome-shell unfreezes.
This only happens when the environment variable GTK_IM_MODULE is set to "ibus". If you unset the variable, or change it to
GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works as intended.
This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
1.5.17-3ubuntu4 and Firefox versions starting with 68.0+build3-0ubuntu0.18.04.1
Note: Chrome[ium] and other applications do not trigger it, and it cannot be
reproduced in other desktop environments.
This seems to be an interaction issue between ibus and gnome-shell.
[Fix]
When ibus is built with the patch ibus-xx-f19-password.patch which was dropped in ibus-1.5.17-2, the problem is solved.
ibus-xx-f19-password.patch checks to see if the GTK version is at or above 3.6, and if it is, checks to see if the input purpose is for a password field. If it is, then no further action is taken by ibus.
[Testcase]
Launch firefox from within a gnome-session, making sure the GTK_IM_MODULE is set to "ibus". Note, this is the default value.
$ env GTK_IM_MODULE="ibus" firefox
Navigate to any website which has a password field. Wikipedia or Reddit will do.
Click a password field and attempt to enter text. Firefox and gnome-shell both lock up and stay frozen for an extended period of time.
With the test package which includes ibus-xx-f19-password.patch, gnome-shell
and Firefox do not lock up and everything works as intended.
Test package is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test
[Regression Potential]
This has a low to medium risk of regression, and is limited to inputs to
password fields in all applications, including the gnome-shell lock screen.
This patch has been extensively tested and it is present in the following Ubuntu releases:
artful: 1.5.14-2ubuntu1
zesty: 1.5.14-2ubuntu1
yakkety: 1.5.11-1ubuntu3
xenial: 1.5.11-1ubuntu2
wily: 1.5.10-1ubuntu1
vivid: 1.5.9-1ubuntu3
utopic: 1.5.8-2ubuntu2
trusty: 1.5.5-1ubuntu3.2
The patch was introduced in trusty, and removed in bionic. I feel that the risk of reintroducing the patch is low, since the use case of the software is the same as previous releases in regards to input software and input language
selection.
I still acknowledge a potential risk of regression when users change their
input engines to non defaults and pair it with non default input languages.
In the event of regression ibus can be temporarily be disabled via an environment variable and the patch dropped in any subsequent packages.
[Notes]
This patch will not be needed in newer versions of ibus as an official
workaround has been implemented as of ibus-1.5.19.
https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
If problems arise with password input fields in ibus versions 1.5.19 or later, which are found in cosmic onward, environment variables can be set that have the same effect as ibus-xx-f19-password.patch.
env IBUS_DISCARD_PASSWORD=1 firefox
or
export IBUS_DISCARD_PASSWORD_APPS='firefox,.*chrome.*' |
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell and Firefox both freeze and the system becomes unusable. If you ssh into the system and terminate Firefox, gnome-shell unfreezes.
This only happens when the environment variable GTK_IM_MODULE is set to "ibus". If you unset the variable, or change it to
GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works as intended.
This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
1.5.17-3ubuntu4 and Firefox versions starting with 68.0+build3-0ubuntu0.18.04.1
Note: Chrome[ium] and other applications do not trigger it, and it cannot be
reproduced in other desktop environments.
This seems to be an interaction issue between ibus and gnome-shell.
[Fix]
When ibus is built with the patch ibus-xx-f19-password.patch which was dropped in ibus-1.5.17-2, the problem is solved.
Instead of using ibus-xx-f19-password.patch, we will instead fix it with
upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:
https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome
Author: fujiwarat <takao.fujiwara1@gmail.com>
This implements the password discard functionality found in
ibus-xx-f19-password.patch and places it behind two environment variables,
IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS.
IBUS_DISCARD_PASSWORD is for a single process, and IBUS_DISCARD_PASSWORD_APPS
lets you set a regex of process names to filter and enable the fix for.
If IBUS_DISCARD_PASSWORD is set or IBUS_DISCARD_PASSWORD_APPS is set with the
process name which input is being placed into password fields, ibus will pass
through the input to the application without any processing.
[Testcase]
Launch firefox from within a gnome-session, making sure the GTK_IM_MODULE is set to "ibus". Note, this is the default value.
$ env GTK_IM_MODULE="ibus" firefox
Navigate to any website which has a password field. Wikipedia or Reddit will do.
Click a password field and attempt to enter text. Firefox and gnome-shell both lock up and stay frozen for an extended period of time.
Now, try it with the fix by enabling:
$ env IBUS_DISCARD_PASSWORD=1 firefox
When you enter text into a password field, ibus should directly pass through
the text and the problem will be solved.
We can also ask it to always apply for a specific application with:
$ export IBUS_DISCARD_PASSWORD_APPS="firefox"
$ firefox
Again, when you enter text into a password input field, the problem will be
solved.
Test package is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test
Please test with the revised version, 1.5.17-3ubuntu4+sf235370v20190731b1.
[Regression Potential]
This change has a low risk of regression, because the default behaviour is
unchanged. To be able to use the password input field discard functionality,
a user has to explicitly set an environment variable for the specific process, or set a regex that matches a process name.
This means the fix is not enabled by default on any machines, and will only be utilised by those suffering problems and go and manually set environment variables or have their system administrator enable the environment variables permanently.
This commit is present in upstream ibus from version ibus-1.5.19 onward, and
is currently present in cosmic, disco and eoan.
If a regression occurs, users can ensure that the environment variables are
unset and continue working.
[Notes]
This patch is functionally the same as ibus-xx-f19-password.patch, but just
hides the features behind environment variables. |
|
| 2019-08-01 04:51:41 |
Matthew Ruffell |
attachment added |
|
revised debdiff for bionic https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1838358/+attachment/5280261/+files/lp1838358_bionic_revised.debdiff |
|
| 2019-08-01 05:07:00 |
Mathew Hodson |
ibus (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-08-01 13:00:01 |
Eric Desrochers |
bug |
|
|
added subscriber STS Sponsors |
| 2019-08-01 13:05:47 |
Eric Desrochers |
description |
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell and Firefox both freeze and the system becomes unusable. If you ssh into the system and terminate Firefox, gnome-shell unfreezes.
This only happens when the environment variable GTK_IM_MODULE is set to "ibus". If you unset the variable, or change it to
GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works as intended.
This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
1.5.17-3ubuntu4 and Firefox versions starting with 68.0+build3-0ubuntu0.18.04.1
Note: Chrome[ium] and other applications do not trigger it, and it cannot be
reproduced in other desktop environments.
This seems to be an interaction issue between ibus and gnome-shell.
[Fix]
When ibus is built with the patch ibus-xx-f19-password.patch which was dropped in ibus-1.5.17-2, the problem is solved.
Instead of using ibus-xx-f19-password.patch, we will instead fix it with
upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:
https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome
Author: fujiwarat <takao.fujiwara1@gmail.com>
This implements the password discard functionality found in
ibus-xx-f19-password.patch and places it behind two environment variables,
IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS.
IBUS_DISCARD_PASSWORD is for a single process, and IBUS_DISCARD_PASSWORD_APPS
lets you set a regex of process names to filter and enable the fix for.
If IBUS_DISCARD_PASSWORD is set or IBUS_DISCARD_PASSWORD_APPS is set with the
process name which input is being placed into password fields, ibus will pass
through the input to the application without any processing.
[Testcase]
Launch firefox from within a gnome-session, making sure the GTK_IM_MODULE is set to "ibus". Note, this is the default value.
$ env GTK_IM_MODULE="ibus" firefox
Navigate to any website which has a password field. Wikipedia or Reddit will do.
Click a password field and attempt to enter text. Firefox and gnome-shell both lock up and stay frozen for an extended period of time.
Now, try it with the fix by enabling:
$ env IBUS_DISCARD_PASSWORD=1 firefox
When you enter text into a password field, ibus should directly pass through
the text and the problem will be solved.
We can also ask it to always apply for a specific application with:
$ export IBUS_DISCARD_PASSWORD_APPS="firefox"
$ firefox
Again, when you enter text into a password input field, the problem will be
solved.
Test package is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test
Please test with the revised version, 1.5.17-3ubuntu4+sf235370v20190731b1.
[Regression Potential]
This change has a low risk of regression, because the default behaviour is
unchanged. To be able to use the password input field discard functionality,
a user has to explicitly set an environment variable for the specific process, or set a regex that matches a process name.
This means the fix is not enabled by default on any machines, and will only be utilised by those suffering problems and go and manually set environment variables or have their system administrator enable the environment variables permanently.
This commit is present in upstream ibus from version ibus-1.5.19 onward, and
is currently present in cosmic, disco and eoan.
If a regression occurs, users can ensure that the environment variables are
unset and continue working.
[Notes]
This patch is functionally the same as ibus-xx-f19-password.patch, but just
hides the features behind environment variables. |
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell and Firefox both freeze and the system becomes unusable. If you ssh into the system and terminate Firefox, gnome-shell unfreezes.
This only happens when the environment variable GTK_IM_MODULE is set to "ibus". If you unset the variable, or change it to
GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works as intended.
This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
1.5.17-3ubuntu4 and Firefox versions starting with 68.0+build3-0ubuntu0.18.04.1
Note: Chrome[ium] and other applications do not trigger it, and it cannot be
reproduced in other desktop environments.
This seems to be an interaction issue between ibus and gnome-shell.
[Test Case]
Launch firefox from within a gnome-session, making sure the GTK_IM_MODULE is set to "ibus". Note, this is the default value.
$ env GTK_IM_MODULE="ibus" firefox
Navigate to any website which has a password field. Wikipedia or Reddit will do.
Click a password field and attempt to enter text. Firefox and gnome-shell both lock up and stay frozen for an extended period of time.
Now, try it with the fix by enabling:
$ env IBUS_DISCARD_PASSWORD=1 firefox
When you enter text into a password field, ibus should directly pass through
the text and the problem will be solved.
We can also ask it to always apply for a specific application with:
$ export IBUS_DISCARD_PASSWORD_APPS="firefox"
$ firefox
Again, when you enter text into a password input field, the problem will be
solved.
Test package is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test
Please test with the revised version, 1.5.17-3ubuntu4+sf235370v20190731b1.
[Regression Potential]
This change has a low risk of regression, because the default behaviour is
unchanged. To be able to use the password input field discard functionality, a user has to explicitly set an environment variable for the specific process, or set a regex that matches a process name.
This means the fix is not enabled by default on any machines, and will only be utilised by those suffering problems and go and manually set environment variables or have their system administrator enable the environment variables permanently.
This commit is present in upstream ibus from version ibus-1.5.19 onward, and is currently present in cosmic, disco and eoan.
If a regression occurs, users can ensure that the environment variables are unset and continue working.
[Other info]
* This patch is functionally the same as ibus-xx-f19-password.patch, but just hides the features behind environment variables.
* When ibus is built with the patch ibus-xx-f19-password.patch which was dropped in ibus-1.5.17-2, the problem is solved.
Instead of using ibus-xx-f19-password.patch, we will instead fix it with
upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:
https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome
Author: fujiwarat <takao.fujiwara1@gmail.com>
This implements the password discard functionality found in
ibus-xx-f19-password.patch and places it behind two environment variables,
IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS.
IBUS_DISCARD_PASSWORD is for a single process, and IBUS_DISCARD_PASSWORD_APPS
lets you set a regex of process names to filter and enable the fix for.
If IBUS_DISCARD_PASSWORD is set or IBUS_DISCARD_PASSWORD_APPS is set with the process name which input is being placed into password fields, ibus will pass through the input to the application without any processing.
* This only affect Bionic
- Upstream first introduction:
$ git describe --contains f328fd67f479faa46ca87bf3c85eed7080ec5ec0
1.5.19~7
- Ubuntu ibus current version found in the archive:
$ rmadison ibus
==> ibus | 1.5.17-3ubuntu4 | bionic
ibus | 1.5.19-1ubuntu1 | cosmic
ibus | 1.5.19-1ubuntu2 | disco
ibus | 1.5.19-4ubuntu2 | eoan |
|
| 2019-08-01 13:05:51 |
Eric Desrochers |
ibus (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2019-08-01 13:06:03 |
Eric Desrochers |
tags |
patch sts sts-sponsor |
patch sts |
|
| 2019-08-01 14:47:07 |
Eric Desrochers |
bug watch added |
|
https://github.com/ibus/ibus/issues/2002 |
|
| 2019-08-01 14:52:49 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2019-08-01 14:52:52 |
Eric Desrochers |
removed subscriber STS Sponsors |
|
|
|
| 2019-08-08 08:05:03 |
Łukasz Zemczak |
ibus (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-08-08 08:05:04 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-08-08 08:05:08 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2019-08-08 08:05:11 |
Łukasz Zemczak |
tags |
patch sts |
patch sts verification-needed verification-needed-bionic |
|
| 2019-08-08 22:07:29 |
Matthew Ruffell |
tags |
patch sts verification-needed verification-needed-bionic |
patch sts verification-done-bionic |
|
| 2019-08-19 17:51:37 |
Launchpad Janitor |
ibus (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-08-19 17:51:45 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
