UPDATE 1: Drupal.ajax.element should be a HTMLElement. @see #6
-------
The Drupal.ajax.expired
function in core/misc/ajax.js
is not sufficiently defensive: Namely, it loops through object members calling a contains()
without first checking that said method exists; with the result, that if custom code adds unexpected members it causes AJAX requests to fail with a message like this:
In Chrome:
Uncaught TypeError: Failed to execute 'contains' on 'Node': parameter 1 is not of type 'Node'.
In Firefox:
TypeError: Argument 1 of Node.contains does not implement interface Node.
Possibly related to #2673824: Views JS passing wrong type of object to Drupal.ajax
Comment | File | Size | Author |
---|---|---|---|
#8 | use_HTMLElement.patch | 808 bytes | droplet |
|
Comments
Comment #2
TravisCarden CreditAttribution: TravisCarden at Acquia commentedHere's a patch that tests that adds the missing conditional test.
Comment #3
droplet CreditAttribution: droplet commentedtypeof document.body === Node
always returns `false`, doesn't it ?
Comment #4
TravisCarden CreditAttribution: TravisCarden at Acquia commentedOops. I think I meant this:
document.body instanceof Node
If that still doesn't look right, please propose a correction. JavaScript isn't my strong suit, so I'm kind of mucking about past my depth here. :)
Comment #5
droplet CreditAttribution: droplet commentedSeems like similar to #2705327: Failed to execute 'contains' on 'Node'.
Can you share any code example / steps to help me dig into it quickly ? Thanks.
Comment #6
nod_Our docs are pretty clear: ajax.element should be a HTMLElement, which inherits from Element which inherits from Node.
Curious to know what triggers this issue for you.
Comment #7
TravisCarden CreditAttribution: TravisCarden at Acquia commentedHey, @nod_! Long time no see. :)
My team encountered this with Automated Logout 8.x-1.0-rc1. See autlogout.js.. The offending code seems readily apparent, if I understand it properly.
I was also having a problem with Entity Browser AJAX that this patch seems to fix, though I've taken no time whatsoever to identify the actual source.
Since the code already has a couple of defensive checks, it doesn't seem inappropriate to go the rest of the way to preventing problems from misuse. If the docs are thus clear, perhaps we should go ahead and test that it's an
HTMLElement
. Or if the point is to prevent developer error, perhaps some kind of error should be thrown.Comment #8
droplet CreditAttribution: droplet commentedComment #9
TravisCarden CreditAttribution: TravisCarden at Acquia commentedComment #11
AjitSTested the patch, and it resolved a couple of other bugs too :)
Committed and pushed to 8.x-1.x