Feature #9706

Jessie: applications menu handling in the test suite is fragile

Added by intrigeri 2015-07-08 04:29:22 . Updated 2015-11-02 04:02:03 .

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 2015-07-08 04:33:37

#2 Updated by intrigeri 2015-08-02 09:06:27

  • Due date set to 2016-01-15

#3 Updated by intrigeri 2015-08-02 09:06:44

  • blocks #8668 added

#4 Updated by intrigeri 2015-08-26 05:55:53

  • Deliverable for set to 268

#5 Updated by anonym 2015-10-21 01:00:40

  • Status changed from Confirmed to In Progress

Applied in changeset commit:e1e57ce298da275124cb607b7b731bb67b94d2a9.

#6 Updated by anonym 2015-10-21 01:04:08

  • 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 2015-11-02 02:21:16

  • 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 2015-11-02 03:20:39

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 2015-11-02 04:02:03

>> 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.