Q7

Tooltip disappears too quickly after hover-ruler command

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.2.18, 1.3.1
  • Fix Version/s: 1.3.7
  • Component/s: Runtime
  • Labels:
  • Test Mode:
    Manual

Description

Create a java class with autogenerated 'main' method and try to assert a tooltip of todo item in ruler. This script fails to be replayed:

get-editor "Program.java" | get-left-ruler | hover-ruler -line 9
get-window -from "Information Window" | get-editbox | get-property text | equals "TODO Auto-generated method stub" 
    | verify-true

Activity

Hide
komaz added a comment - 26/Apr/13 6:09 PM

This sounds weird, but it looks like that workaround for hover-ruler is to insert a dummy 'hover-text' command.
When executing command like this alone, the tooltip appears for a few milliseconds and then hides, so assertion fails:

get-editor "Program.java" | get-left-ruler | hover-ruler -line 9
get-window -from "Information Window" | get-editbox | get-property text | equals "TODO Auto-generated method stub" | verify-true

But when I add simple hover-text command as a first line of script, the test passes:

get-editor "Program.java" | get-text-viewer | hover-text 1 1
get-editor "Program.java" | get-left-ruler | hover-ruler -line 9
get-window -from "Information Window" | get-editbox | get-property text | equals "TODO Auto-generated method stub" | verify-true
Show
komaz added a comment - 26/Apr/13 6:09 PM This sounds weird, but it looks like that workaround for hover-ruler is to insert a dummy 'hover-text' command. When executing command like this alone, the tooltip appears for a few milliseconds and then hides, so assertion fails:
get-editor "Program.java" | get-left-ruler | hover-ruler -line 9
get-window -from "Information Window" | get-editbox | get-property text | equals "TODO Auto-generated method stub" | verify-true
But when I add simple hover-text command as a first line of script, the test passes:
get-editor "Program.java" | get-text-viewer | hover-text 1 1
get-editor "Program.java" | get-left-ruler | hover-ruler -line 9
get-window -from "Information Window" | get-editbox | get-property text | equals "TODO Auto-generated method stub" | verify-true
Hide
komaz added a comment - 26/Apr/13 7:56 PM

Need to publish a kb article

Show
komaz added a comment - 26/Apr/13 7:56 PM Need to publish a kb article
Hide
komaz added a comment - 09/Sep/13 11:11 AM

It looks like I've fixed this issue, though not fully understood.

AbstractHoverInformationControlManager has a Closer associated with displayed information control. This Closer was closing information control because of receiving SWT.Activate event from Shell#windowDidBecomeKey (on Mac OS X), but something similar seems to happen on Windows.

Looks like the workaround above with hovering text was causing that these activation events from OS were already processed.

Putting this snippet before sending MouseMove and MouseHover events to ruler solved the issue both on Windows and Mac OS X:

shell.forceActive();
while (display.readAndDispatch()) { /* do nothing */ }
Show
komaz added a comment - 09/Sep/13 11:11 AM It looks like I've fixed this issue, though not fully understood. AbstractHoverInformationControlManager has a Closer associated with displayed information control. This Closer was closing information control because of receiving SWT.Activate event from Shell#windowDidBecomeKey (on Mac OS X), but something similar seems to happen on Windows. Looks like the workaround above with hovering text was causing that these activation events from OS were already processed. Putting this snippet before sending MouseMove and MouseHover events to ruler solved the issue both on Windows and Mac OS X:
shell.forceActive();
while (display.readAndDispatch()) { /* do nothing */ }

People

  • Assignee:
    komaz
    Reporter:
    komaz
Vote (0)
Watch (0)

Dates

  • Created:
    26/Apr/13 5:34 PM
    Updated:
    09/Sep/13 11:15 AM
    Resolved:
    09/Sep/13 11:15 AM