Project

General

Profile

Bug #10467

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

"I open the address" step is fragile on Jessie

Added by intrigeri about 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Test suite
Target version:
Start date:
11/02/2015
Due date:
% Done:

100%

Feature Branch:
feature/jessie
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

See attached screenshot, that I got via "Importing an OpenPGP key from a website" in current feature/jessie. I'm triaging this as Jessie-specific, since I've never seen it elsewhere. Feel free to reclassify if I guessed wrong.

00_06_33_Importing_an_OpenPGP_key_from_a_website.png View (111 KB) intrigeri, 11/02/2015 02:34 AM

Associated revisions

Revision 5052b4c6 (diff)
Added by anonym about 4 years ago

Work around issue with lost key presses in the browser.

When entering an address like"http(s)" we sometime end up with
"htp(s)", so either the second or third character is lost. My guess is
the second; once the first character is entered, the Tor Browser
immediately starts showing the list of suggestions, and it seems if
the second character is timed at some particular point when this list
is being shown, it's lost.

This is worked around by just pasting the whole address in one go, via
the clipboard.

Will-fix: #10467

History

#3 Updated by anonym about 4 years ago

I've seen this very frequently now. :/

So we type "http(s)" but end up with "htp(s)", so either the second or third character is lost. My guess is the second; once the first character is entered, the Tor Browser immediately starts showing the list of suggestions, and it seems if the second character is timed at some particular point when this list is being shown, it's lost.

The easiest fix would be to send the URL to the clipboard via the remote shell and paste it via Sikuli (Ctrl+V). I tried this:

$vm.execute_successfully("echo -n '#{address}' | xclip -in -selection clipboard")
@screen.type("v", Sikuli::KeyModifier.CTRL)

but xclip doesn't exit (although it does succeed in setting the clipboard, which I verified by taking over the VM) and so blocks the remote shell forever, and hence the test suite too. It's not the usage of pipe that causes it, because I've tried having xclip take a file argument instead and it still hangs. Actually, it seems to be a bug with xclip that prevents it from exiting when run in a subshell (or something). Look for yourself in your favorite environment:
( echo -n 'xclip is buggy' | xclip -in -selection clipboard )
pgrep xclip
xclip -out -selection clipboard

So, no wonder, the remote shell hangs at p.communicate().

Ah, working with the automated test suite is bliss, truly. :)

#4 Updated by intrigeri about 4 years ago

anonym wrote:

but xclip doesn't exit

This seems to be exactly its intended behaviour, see the manpage (-loops) and run it with -verbose to check. Try with xsel instead?

#5 Updated by anonym about 4 years ago

  • Status changed from Confirmed to In Progress

#6 Updated by anonym about 4 years ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to feature/jessie

intrigeri wrote:

anonym wrote:

but xclip doesn't exit

This seems to be exactly its intended behaviour, see the manpage (-loops) and run it with -verbose to check.

Indeed, how odd. Thanks for the clarification!

Try with xsel instead?

That seems to work much better. What do you think of these commits:

5052b4c Work around issue with lost key presses in the browser.
6c16f71 Add method used to set the Xorg clipboard.
169beea Install xsel.

#7 Updated by intrigeri about 4 years ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 50 to 80
  • QA Check changed from Ready for QA to Info Needed

Pushed 1a7e225 on top.

Shouldn't we use echo -n in set_clipboard? It feels wrong to set the clipboard to something slightly different from what is passed to this method.

Looks good otherwise, untested though (I assume you did test it since it allowed you to update tons of scenarios later on).

#8 Updated by anonym about 4 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 80 to 100
  • QA Check changed from Info Needed to Pass

intrigeri wrote:

Pushed 1a7e225 on top.

Shouldn't we use echo -n in set_clipboard? It feels wrong to set the clipboard to something slightly different from what is passed to this method.

The -n option was intended (as you can see in my earlier example); thanks for noticing! Fixed in 5f400c8.

Looks good otherwise, untested though (I assume you did test it since it allowed you to update tons of scenarios later on).

Yeah. I re-ran one of the torified_browser.feature scenarios ~ten times without error, which I was never even close to before this fix. Closing!

Also available in: Atom PDF