Feature #9706

Jessie: applications menu handling in the test suite is fragile

Added by intrigeri about 10 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Test suite
Target version:
Tails_1.7
Start date:
2015-07-08
Due date:
2016-01-15
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:
268

Description

Quite often, e.g. when trying to start stuff from the “Internet” submenu, the “Graphics” one ends up being selected instead, and then of course the application can’t be started. Shall we just use the “Activities” view to start applications instead?

Subtasks

History

#1 Updated by intrigeri about 10 years ago

#2 Updated by intrigeri about 10 years ago

  • Due date set to 2016-01-15

#3 Updated by intrigeri about 10 years ago

  • blocks #8668 added

#4 Updated by intrigeri about 10 years ago

  • Deliverable for set to 268

#5 Updated by anonym about 9 years ago

  • Status changed from Confirmed to In Progress

Applied in changeset commit:e1e57ce298da275124cb607b7b731bb67b94d2a9.

#6 Updated by anonym about 9 years ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA

intrigeri wrote:
> Shall we just use the “Activities” view to start applications instead?

This is certainly worth considering further down the line. I’ve pushed a fix that I’m fairly sure will bring us back to at least Wheezy-level robustness for this step.

#7 Updated by intrigeri about 9 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • Target version changed from Tails_1.8 to Tails_1.7
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

The idea + code look sane. I’ve run one of the affected features (unsafe browser) and didn’t see the breakage again, so closing as resolved.

IMO screen.w is unclear and relies a lot on implicit assumptions, so it would probably deserve a comment (or to be replaced by “y coordinate of the mouse cursor” which would more clearly express the intent, perhaps?), but no big deal.

#8 Updated by anonym about 9 years ago

intrigeri wrote:
> The idea + code look sane. I’ve run one of the affected features (unsafe browser) and didn’t see the breakage again, so closing as resolved.

\o/

> IMO screen.w is unclear and relies a lot on implicit assumptions, so it would probably deserve a comment (or to be replaced by “y coordinate of the mouse cursor” which would more clearly express the intent, perhaps?), but no big deal.

Hm. screen.w = “the right screen edge”, and that is the intention. I explicitly want to move it to the screen right edge (at the appropriate height) to not interfere with the menu, which just moving it vertically would. Or am I misunderstanding you?

#9 Updated by intrigeri about 9 years ago

>> IMO screen.w is unclear and relies a lot on implicit assumptions, so it would probably deserve a comment (or to be replaced by “y coordinate of the mouse cursor” which would more clearly express the intent, perhaps?), but no big deal.

> Hm. screen.w = “the right screen edge”, and that is the intention.
> I explicitly want to move it to the screen right edge (at the appropriate height) to not interfere with the menu, which just moving it vertically would.

OK. So I didn’t get the intention correctly.