Project

General

Profile

Feature #9706

Feature #7563: Update the automated test suite for Jessie ISO images

Jessie: applications menu handling in the test suite is fragile

Added by intrigeri almost 4 years ago. Updated over 3 years ago.

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

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

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?

Associated revisions

Revision e1e57ce2 (diff)
Added by anonym over 3 years ago

Fix gnome_app_menu_click_helper() in Jessie.

Will-fix: #9706

History

#1 Updated by intrigeri almost 4 years ago

  • Parent task set to #7563

#2 Updated by intrigeri almost 4 years ago

  • Due date set to 01/15/2016

#5 Updated by anonym over 3 years ago

  • Status changed from Confirmed to In Progress

#6 Updated by anonym over 3 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 over 3 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 over 3 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 over 3 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.

Also available in: Atom PDF