| 2012-07-16 15:02:16 |
Daniel d'Andrada |
bug |
|
|
added bug |
| 2012-07-16 15:02:37 |
Daniel d'Andrada |
description |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
Steps to reproduce the issue:
1 - touch 1 begins and get ownership
2 - touch 2 begins and get ownership
3 - touch 3 begins and get ownership
4 - touch 4 begins and get ownership
5 - touch 4 ends
6 - touch 5 begins
7 - frame client accepts touch 4
Expected outcome:
frame lib accepts the touch on the XInput backend.
Actual outcome:
Nothing happens. frame lib never accepts that touch. |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 2 begins and gets ownership
3 - touch 3 begins and gets ownership
4 - touch 4 begins and gets ownership
5 - touch 4 ends
6 - touch 5 begins
7 - frame client accepts touch 4
Expected outcome:
frame lib accepts the touch on the XInput backend.
Actual outcome:
Nothing happens. frame lib never accepts that touch. |
|
| 2012-07-16 15:02:41 |
Daniel d'Andrada |
utouch-frame: assignee |
|
Daniel d'Andrada (dandrader) |
|
| 2012-07-16 15:02:43 |
Daniel d'Andrada |
utouch-frame: importance |
Undecided |
High |
|
| 2012-07-16 15:02:47 |
Daniel d'Andrada |
utouch-frame: status |
New |
In Progress |
|
| 2012-07-17 14:25:31 |
Daniel d'Andrada |
description |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 2 begins and gets ownership
3 - touch 3 begins and gets ownership
4 - touch 4 begins and gets ownership
5 - touch 4 ends
6 - touch 5 begins
7 - frame client accepts touch 4
Expected outcome:
frame lib accepts the touch on the XInput backend.
Actual outcome:
Nothing happens. frame lib never accepts that touch. |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 1 ends
3 - touch 2 begins and gets ownership
4 - frame client accepts touch 1
Expected outcome:
frame lib accepts the touch on the XInput backend.
Actual outcome:
Nothing happens. frame lib never accepts that touch. |
|
| 2012-07-17 14:30:53 |
Launchpad Janitor |
branch linked |
|
lp:~dandrader/utouch-frame/lp1025297 |
|
| 2012-07-18 15:55:36 |
Launchpad Janitor |
branch linked |
|
lp:utouch-frame |
|
| 2012-07-18 15:56:19 |
Daniel d'Andrada |
utouch-frame: status |
In Progress |
Fix Committed |
|
| 2012-07-25 22:55:54 |
Chase Douglas |
utouch-frame: milestone |
|
utouch-frame-2.2.4 |
|
| 2012-07-25 22:55:58 |
Chase Douglas |
utouch-frame: status |
Fix Committed |
Fix Released |
|
| 2012-07-26 18:58:51 |
Launchpad Janitor |
branch linked |
|
lp:frame/ubuntu |
|
| 2012-07-29 12:12:19 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/quantal/frame/quantal |
|
| 2012-08-08 20:56:07 |
Launchpad Janitor |
branch linked |
|
lp:~fginther/frame/frame-2.2.4-precise |
|
| 2012-08-09 15:32:58 |
Francis Ginther |
description |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 1 ends
3 - touch 2 begins and gets ownership
4 - frame client accepts touch 1
Expected outcome:
frame lib accepts the touch on the XInput backend.
Actual outcome:
Nothing happens. frame lib never accepts that touch. |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
[Test Case]
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 1 ends
3 - touch 2 begins and gets ownership
4 - frame client accepts touch 1
Expected outcome:
frame lib accepts the touch on the XInput backend.
Actual outcome:
Nothing happens. frame lib never accepts that touch.
[Regression Potential]
TBD |
|
| 2012-08-09 17:47:43 |
Chase Douglas |
nominated for series |
|
frame/precise |
|
| 2012-08-09 17:47:43 |
Chase Douglas |
bug task added |
|
frame/precise |
|
| 2012-08-09 17:47:51 |
Chase Douglas |
frame/precise: status |
New |
In Progress |
|
| 2012-08-09 17:47:57 |
Chase Douglas |
frame/precise: importance |
Undecided |
High |
|
| 2012-08-09 17:48:05 |
Chase Douglas |
frame/precise: assignee |
|
Francis Ginther (fginther) |
|
| 2012-08-09 17:55:48 |
Chase Douglas |
description |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
[Test Case]
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 1 ends
3 - touch 2 begins and gets ownership
4 - frame client accepts touch 1
Expected outcome:
frame lib accepts the touch on the XInput backend.
Actual outcome:
Nothing happens. frame lib never accepts that touch.
[Regression Potential]
TBD |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
[Test Case]
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 1 ends
3 - touch 2 begins and gets ownership
4 - frame client accepts touch 1
An example of when this happens in normal usage is performing a three-touch tap on a touchscreen in unity where the first touch to hit the screen is over a menu item that opens a drop-down menu.
Expected outcome:
Frame lib accepts the touch on the XInput backend. All further input events continue as normal.
Actual outcome:
Nothing happens. Frame lib never accepts the touch. This causes the touchscreen to behave as though it has "locked up". Touches no longer cause emulated button press/release events, so it is hard to interact with the desktop.
[Regression Potential]
Small.
The actual code change involves removing logic that waits for a touch to end before it is accepted or rejected. This was required in the initial XInput multitouch protocol, but because unnecessary upon protocol finalization. Now, frame simply forwards accept and reject when they occur. This simplifies the code considerably.
A new regression test case has been added for this issue. All previous functional and regression test cases continue to pass. |
|
| 2012-08-09 17:57:23 |
Chase Douglas |
description |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
[Test Case]
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 1 ends
3 - touch 2 begins and gets ownership
4 - frame client accepts touch 1
An example of when this happens in normal usage is performing a three-touch tap on a touchscreen in unity where the first touch to hit the screen is over a menu item that opens a drop-down menu.
Expected outcome:
Frame lib accepts the touch on the XInput backend. All further input events continue as normal.
Actual outcome:
Nothing happens. Frame lib never accepts the touch. This causes the touchscreen to behave as though it has "locked up". Touches no longer cause emulated button press/release events, so it is hard to interact with the desktop.
[Regression Potential]
Small.
The actual code change involves removing logic that waits for a touch to end before it is accepted or rejected. This was required in the initial XInput multitouch protocol, but because unnecessary upon protocol finalization. Now, frame simply forwards accept and reject when they occur. This simplifies the code considerably.
A new regression test case has been added for this issue. All previous functional and regression test cases continue to pass. |
frame lib fails to forward the accept/reject command to xserver for an owned touch if it has already ended.
[Test Case]
Steps to reproduce the issue:
1 - touch 1 begins and gets ownership
2 - touch 1 ends
3 - touch 2 begins and gets ownership
4 - frame client accepts touch 1
An example of when this happens in normal usage is performing a three-touch tap on a touchscreen in unity where the first touch to hit the screen is over a menu item that opens a drop-down menu.
Expected outcome:
Frame lib accepts the touch on the XInput backend. All further input events continue as normal.
Actual outcome:
Nothing happens. Frame lib never accepts the touch. This causes the touchscreen to behave as though it has "locked up". Touches no longer cause emulated button press/release events, so it is hard to interact with the desktop.
[Regression Potential]
Small. Look for issues when using unity gestures on a trackpad or when using a touchscreen for any type of interactions in unity.
The actual code change involves removing logic that waits for a touch to end before it is accepted or rejected. This was required in the initial XInput multitouch protocol, but because unnecessary upon protocol finalization. Now, frame simply forwards accept and reject when they occur. This simplifies the code considerably.
A new regression test case has been added for this issue. All previous functional and regression test cases continue to pass. |
|
| 2012-08-27 19:32:37 |
Chase Douglas |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2012-08-30 19:19:39 |
Adam Conrad |
bug |
|
|
added subscriber SRU Verification |
| 2012-08-30 19:19:41 |
Adam Conrad |
tags |
|
verification-needed |
|
| 2012-09-02 07:42:19 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/precise/frame/precise-proposed |
|
| 2012-09-05 21:45:26 |
Chase Douglas |
tags |
verification-needed |
verification-done |
|
| 2012-09-10 13:55:20 |
Scott Kitterman |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2013-06-12 21:38:53 |
Francis Ginther |
frame/precise: status |
In Progress |
Fix Released |
|
