[HtmlUnit] [htmlunit:bugs] #1967 Clicking button has stopped working and returns same web page

[RBRi <rb...@us...>]

Can you please

* check if the latest snapshot makes any diffrence
* before calling element.click() check if the element is dislayed (element.isDisplayed())
* call element.click(false, false, false, true, true, false) instead of element.click()


---

** [bugs:#1967] Clicking button has stopped working and returns same web page**

**Status:** accepted
**Group:** 2.31
**Created:** Mon Jun 11, 2018 09:45 AM UTC by Martin Strange
**Last Updated:** Fri Jul 20, 2018 01:02 PM UTC
**Owner:** RBRi


Until recently, I have been running HtmlUnit 2.25. It was throwing up rhino errors but still allowed my code to click the edit button in a Google Sites web page to bring up the editable version of the page. My code has recently stopped working. Now when I call click() to click the edit button, the same web page is returned (easy to verify since the returned web page still contains the edit button and not the save button of the editable web page).

I have switched to HmtlUnit 2.31. The good news is the rhino errors have gone. But click() is still not advancing to the editable web page.

The problem doesn't seem likely to be a Javascript error, since once the right element is obtained I don't think Javascript is involved in the actual click() process. 

Here is my code:

~~~
:::java
// Set up the web client.
WebClient webClient = new WebClient(BrowserVersion.CHROME);

// Read in cookies file so that the Google Sites server will recognise
// me as logged in and return the logged in web page in the following 
// getPage call (code not shown here as this all works fine).

// Get logged in web page.
HtmlPage loggedInPage= webClient.getPage("https://sites.google.com/site/[my-web-page-at-google-sites]");

// Wait 2 secs just in case time is needed to execute Javascript.
 webClient.waitForBackgroundJavaScriptStartingBefore(2000);

// Get the element (edit button) to click.
HtmlElement element loggedInPage.getElementById("edit-start-btn");

// Check that element obtained is the correct edit button and all is
// looking good for clicking it.
System.out.println("Element about to be clicked is: +  element);  

// Click the edit button to get the editable web page.
HtmlPage editablePage = element.click();

// Have a look at the returned web page to see if it is the editable page.
System.out.println(editablePage.asXml());
~~~

Here is the web page code snippet containing the button I want to click:

~~~html
                  <div role="button" id="edit-start-btn" class="goog-inline-block jfk-button jfk-button-standard jfk-button-disabled" aria-disabled="true">
                    <span id="sites-collaborator-bar-edit-page-icon" class="sites-camelot-icon">                      
                    </span>
                  </div>
~~~


My code finds the element on the web page OK since the println that outputs details about the element about to be clicked corresponds correctly with the edit button shown in this web page code snippet above:

~~~
Element about to be clicked is: HtmlDivision[<div role="button" id="edit-start-btn" class="goog-inline-block jfk-button jfk-button-standard jfk-button-collapse-right collaborator-btn-collapse-right" aria-disabled="false" aria-label="Edit page" tabindex="0">]
~~~

Why does my code fail, and why should it have previously worked OK in HtmlUnit 2.25 and then suddenly stopped working?

I notice that the time now taken to perform the click() is at most a second or apparently instantaneous. When the code was working, it took a second or two. Could this indicate that HtmlUnit is not even going to the Google Sites server, perhaps returning the cached version of the same page instead? One thought I had but probably not relevant: could it be a focus issue? I know HtmlUnit has changed for text input in forms, now requiring the focus to be shifted to the form which wasn't the case before. Does the focus have to be shifted to a button before clicking it will work?

Many thanks if you can help.

I find HtmlUnit really useful in the work I do. It's an awesome tool and you guys do a fantastic job in developing and supporting it.


---

Sent from sourceforge.net because htm...@li... is subscribed to https://sourceforge.net/p/htmlunit/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/htmlunit/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.