Clicking elements with children in Javascript tests throws a GastonJS exception

As we continue to write Javascript tests, we're going to run into this more and more, so instead of waiting for the GastonJS fix we should implement a temporary fix in JavascriptTestBase which protects test-writers from running into this problem.

Well, did someone tried to create a PR for gastonJS actually? When you have PRs on upstream projects they are usually orders of magnitude faster fixed than anything in Drupal.

@samuel.mortenson
I didn't tried to sound harsh, sorry for that!

+++ b/core/modules/simpletest/tests/src/FunctionalJavascript/BrowserWithJavascriptTest.php
@@ -62,4 +62,29 @@ public function testCreateScreenshot() {
 
+  /**
+   * Tests behaviors related to clicking on elements with nested elements.
+   */
+  public function testNestedClick() {
+    $this->drupalGet('<front>');
+    $session = $this->getSession();
+
+    // Create an anchor element with a nested <div>.
+    $javascript = <<<JS
+    (function(){
+      var anchor = document.createElement('A');
+      anchor.href = '#my-anchor';
...
+    $this->click('#anchor-with-children');

It is so nice to see that someone actually cares about tests of test functionality! Thanks a lot!

Awesome work, @samuel.mortenson! :)

Discussed with @catch, @xjm, @effulgentsia, and @cottser we decided this is eligible for 8.1.x.

+++ b/core/tests/Drupal/FunctionalJavascriptTests/JavascriptTestBase.php
@@ -52,6 +53,22 @@ protected function tearDown() {
+      $css_selector = addcslashes($css_selector, "'");
+      $this->getSession()->executeScript("document.querySelectorAll('" . $css_selector . "')[0].click()");

Discussed with @xjm who pointed out that this means tests can inject javascript using this method. Is there anyway to use xpath and the existing browser methods to do this.

+++ b/core/modules/simpletest/tests/src/FunctionalJavascript/BrowserWithJavascriptTest.php
@@ -62,4 +62,29 @@ public function testCreateScreenshot() {
+      var anchor = document.createElement('A');
+      anchor.href = '#my-anchor';
+      anchor.id = 'anchor-with-children';
+      var div = document.createElement('DIV');
+      anchor.appendChild(div);
+      document.body.appendChild(anchor);

you can dramatically simplify this bit by using document.innerHTML = '<a id="my-anchor"><div></div></a>'

Anchor with the empty tag has no dimension that should be invisible and NOT clickable. We shouldn't click it via JavaScript for Browser tests IMO. We should consider to create a new API instead.

Another ideal solution is looking into Behat (Selenium2 driver) and use Behat API to select it.

Just curious, why don't Drupal using Selenium2? Shouldn't Druapl test in real Chrome/Firefox/iOS..etc ?
Selenium2 + webDriver, it can run Phantomjs also.

Anchor with the empty tag has no dimension that should be invisible and NOT clickable. We shouldn't click it via JavaScript for Browser tests IMO. We should consider to create a new API instead.

Well, we can easily put something in those divs and call it a day. This is a detail, IMHO.

@droplet
Just getting phantomjs to run on the testbots for example was a challenge. Using phantomjs also gives us more control over things. Whether its the best situation, I don't know.
Regarding behat, I believe that you are abusing behat for something its not meant to be used for, see https://docs.google.com/document/d/17raktxD51MP0WUvqtNQFsCzevYgDNkvl7jOu...

Also as an update to people following this issue but not the GastonJS bug on GitHub - the maintainer got back to me today and said they would debug the issue. I'll update again if I hear anything concrete on that end.

Great to know!

Well, we can easily put something in those divs and call it a day. This is a detail, IMHO.

To test invisible (display:none) element, we will get a false result.

@droplet
Just getting phantomjs to run on the testbots for example was a challenge. Using phantomjs also gives us more control over things. Whether its the best situation, I don't know.
Regarding behat, I believe that you are abusing behat for something its not meant to be used for, see https://docs.google.com/document/d/17raktxD51MP0WUvqtNQFsCzevYgDNkvl7jOu...

Thanks for the information. I was wonder if "./vendor/jcalderonzumba/gastonjs/src/Client/main.js" provided extra report info for Drupal testbots. I will look into it when I have free time (will not have much within these one or two months. If someone interested, please help to diva into it.)

I started a quick test here: #2775653: JavascriptTests with webDriver and it's worked.

When you say "Create a new API", what do you have in mind?

Don't override default click? and a new API called hackedClick, JSClick? It's used for the special case only.

(By the way, I don't know if there're any architecture difference but it has no issue in webDriver.)

Testing testbot. I expected only testBrokenImageClick will be failed.

(the uploaded patch has wrong code on testNestedEmptyClick. But it doesn't matter, it has been tested in Patch #5.)

#25 failing as expected.

Nested with Empty element: Zero dimension
Nested with Broken image: Zero dimension

Both should be not clickable.

According to #25, the better workaround is mute the error on the clickable element with zero dimension.

So that for this issue: #2421427: Improve the UX of Quick Editing single-valued image fields
I bet we should drop a timer there to wait for image loading.
this article may help: http://docs.behat.org/en/v2.5/cookbook/using_spin_functions.html

Cool. I fixed the Quick Editing issue.

IMO, we need not fix this issue, or say no rush for a fixing.

About the fixes, we should make it same behavior as SENDKEY to click on white space. We could report it to GastonJS to mute the error message, it seems not a bug.

Marked #2789381: Submitting an ajax dialog form in Javascript test throws a GastonJS error as a duplicate of this.

And this is now blocking #2785589: Fix js and jsdoc of outside-in module.

Removing the blocker, see my comments in https://www.drupal.org/node/2789381#comment-11642125

It's very good to keep this issue alive until we run into the real limitations. We should not always try JS to fake the testing engine before real debugging.

@droplet adding back the blocker tag
I think @Wim Leers added that in relation to #2785589: Fix js and jsdoc of outside-in module not #2789381: Submitting an ajax dialog form in Javascript test throws a GastonJS error
#2785589: Fix js and jsdoc of outside-in module has both problems. You can't write a JS test that use a click, this issue AND you can't submit a form via JS test.

The patch needed re-roll for 8.2.x.

I can tested #2785589: Fix js and jsdoc of outside-in module with the patch and it allows testing Outside In for both the clicking a link and submitting a form.

IMO, we need not fix this issue, or say no rush for a fixing.

It seems like this important because it stops people writing JS tests. We have no idea how many people hit this error trying to write test for core or contrib but never make it to this issue.

That's GREEN in #2785589: Fix js and jsdoc of outside-in module without patching. Remove `blocker` tag again :)

It seems like this important because it stops people writing JS tests. We have no idea how many people hit this error trying to write test for core or contrib but never make it to this issue.

I still think it's not an issue and you will agree now? (It hints you writing wrong testcases)

For edge cases (we didn't find any yet?), the best workaround still is a new helper: `JSClick()`

No visual debugging is the real reason that stops people writing JS tests. Remember that the testbot running with system base theme, and we can't active it from UI right? Even no simple way from setting file?

For example this issue: #2789381: Submitting an ajax dialog form in Javascript test throws a GastonJS error
It's really not clickable from browsers. Not a test engine bug, instead of a JS lib & theme bug.

the right person should kick it into experiment module also: #2775653: JavascriptTests with webDriver
Even not using in d.org. It will help developers to write tests.

Also drupal missing an interactive console to write test:
http://codeception.com/docs/reference/Commands#Console

and unable to use Psysh :( We waste a lot of time on test reboot. Even I can't attach Xdebug to do it. Maybe someone able to give me some hints?

@droplet
Before continuing please read xjmdrupal.org/blog/someone-worked-hard-on-it ... people work on stuff, try to improve stuff, be part of it instead of just providing negative thoughts.

I updated the issue summary on #2775653: JavascriptTests with webDriver, so let's collaborate there.

Maybe someone able to give me some hints?

This is my xdebug config, and yes I'm often quite lazy :)

[xdebug]
zend_extension="/usr/local/opt/php56-xdebug/xdebug.so"
xdebug.remote_enable=1
xdebug.max_nesting_level=256
xdebug.remote_autostart=1

@dawehner,

Sorry if my word makes you feel sad. I didn't try to make anyone unhappy. :) I'm thinking in both minds all time.

Positive thoughts are good. Sometimes negative thoughts also good. It helps gather the same feeling people to work on the same topic. OpenSource still has its own rule, not the single person able to "work on stuff, try to improve stuff". We needed supporting from those right person.

I updated the issue summary on #2775653: JavascriptTests with webDriver, so let's collaborate there.

Thanks!!! will do.

This is my xdebug config, and yes I'm often quite lazy :)

Thanks. I was trying to execute code in real time but it has limitations on PHPUnit:
https://www.jetbrains.com/help/phpstorm/2016.2/evaluating-expressions.ht...

Psysh is my new hope but it simply crashed in Drupal tests. Seems not easy to find out the problem.

Sorry if my word makes you feel sad. I didn't try to make anyone unhappy. :) I'm thinking in both minds all time.

I'm not talking about myself. This is really just about your general behaviour. Thank about what you write :)

Psysh is my new hope but it simply crashed in Drupal tests. Seems not easy to find out the problem.

Seems unrelated. Do you think about allowing to open up a psysh instance out of testing?

Maybe I should start a new issue to discuss it. Very last unrelated comment on this issue thread :)

Do you think about allowing to open up a psysh instance out of testing?

Yup! @see GIF

** This isn't a Codeception feature. I dropped `\Psy\Shell::debug(get_defined_vars());` into my tests directly.

OK. Here're my new thoughts & summary:

Using https://github.com/jquery/jquery-simulate for special cases. It sends a MouseEvents.

In gastonjs, there's similar API (non-behat-mink standard API):

 public function clickCoordinates($coordX, $coordY) {
    return $this->command('click_coordinates', $coordX, $coordY);
  }

(however, we unable to find the element X & Y coords in PHP testcases)

My assumption on GastonJS & PhantomJS:
Success:
`click()` -> ELEMENT CLICK -> CLICKABLE -> return TRUE.

Failure:
`click()` -> ELEMENT CLICK -> NOT CLICKABLE -> return FALSE.

When will the element not clickable?
E1. HIDDEN
E2. ZERO dimension
E3. PointerEvent: none
E4. Clicking the link or buttons in nested layers (topmost DIV blocking the clicking)
E5. (UNCONFIRMED) Rendered outside the browser windows (viewports)

Why `jQuery.trigger('click')` works?
A1. It triggers a JS event on target elements instead MouseEvents.

Why don't use `jQuery.trigger('click')`
B1. `jQuery.trigger('click')` able to click elements that Human can't do it with mouse devices.

Why don't hack `click()` directly?
C1. Prevent we make mistakes on test cases. And it converted our test cases to PHP-BROWSER like behaviors

Why use `jquery-simulate`?
D1. Mute the exceptions on "E3"

When to use `jquery-simulate`?
F1. So far until this moment, I think only the E3.

Hoping you have a Happy Weekend!!

OFFTOPIC:
About `\Psy\Shell` on #39. I think we able to write a bootstrap script to init test (or empty test env) inside `\Psy\Shell`, instead of a breakpoint in tests.

When will the element not clickable?
E1. HIDDEN
E2. ZERO dimension
E3. PointerEvent: none
E4. Clicking the link or buttons in nested layers (topmost DIV blocking the clicking)
E5. (UNCONFIRMED) Rendered outside the browser windows (viewports)

Also, there is a bug that does not correspond to any of these conditions within phantom, which is the original bug report that I filed. I looked at it again today (my original report was an angular.js front end and behat/mink/phantomjs running against it).

Checking in Firefox, I confirmed that E1, E2, E3 and E5 do not apply in my original case. I added a z-index to the anchor element and still ran into the issue so I think that E4 does not apply as well. There is some other case with an anchor element wrapping an image element.

@mradcliffe,

I guess you ran into E2. @see #25 & #27

From your github reports:

I think a work-around would be to change the image markup to use CSS background instead.

Used as background, it has to apply dimension value to A tag. (now with dimension)
one of above reports is clicking "an anchor element wrapping an image element." and it passed: @see: https://www.drupal.org/node/2785589

(**I think it will not, but checking if network res with slow downloading is an issue)

Possibly related: #2936535-2: Modal dialog errors in stark theme

Is this relevant any more now that we're moving to nightwatch instead of phantom?

Not using gastonjs anymore.