Bug #10467
"I open the address" step is fragile on Jessie
100%
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.
Files
Subtasks
History
#1 Updated by intrigeri 2015-11-02 02:36:33
- Deliverable for set to 268
#2 Updated by intrigeri 2015-11-02 02:36:47
- blocks #8668 added
#3 Updated by anonym 2015-11-11 17:00:52
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 2015-11-17 09:48:48
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 2015-11-17 15:29:56
- Status changed from Confirmed to In Progress
Applied in changeset commit:5052b4c6b053a05c74ba3dc0634cf3eb883e3d27.
#6 Updated by anonym 2015-11-18 02:24:47
- 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 2015-11-18 09:02:34
- Assignee changed from intrigeri to anonym
- % Done changed from 50 to 80
- QA Check changed from Ready for QA to Info Needed
Pushed commit: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 2015-11-18 09:09:00
- 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 commit: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 commit: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!