Closed BenSpencer closed 10 years ago
If we modify clickInput to move the button by 100px (using targetElement.evaluateJavaScript("this.style.marginLeft = '100px';");
) then the coordinates returned by targetElement.geometry().center();
are the same as usual afterwards, (468,445).
Also, doing a run with this modification leads to a different set of traces being mis-clicked and different ones being explored, so I think this is certainly a bug in the UI interaction due to the moving button.
On the page http://www.underwoods.co.uk/search.cfm depending on which option is selected in the first select box, the width of the two boxes changes and the button position moves.
This seems to be causing some traces (in particular, those which select an option from the first box like "Care" which does not use the second box). to miss the button and click on the page background, doing nothing. These traces just end in TraceEndUnknown with no further execution.
If I use the built-in button finding instead of --concolic-button then there is code which gets explored on these traces, so the problem is certainly related to XPath button locations and ClickInput.
ClickInput is supposed to calculate the coordinates to click just before the click to avoid this type of issue. In the run I watched, this was always chosen as (468, 445) [in the 640x480 viewport] regardless of any previous injection.