Behaviors are initialized with this function Drupal.attachBehaviors = function(context, settings) {}. And we call it on load with those parameters:

Drupal.attachBehaviors(document, drupalSettings);

The idea is to have a DOM element as the context parameter so that attach scripts can use DOM methods on this context directly. Including doing 

$(context).once('myonce');

The issue here is that document is not an actual DOM element, it's a Document and does not have all the methods and properties of an Element.

This is an issue with the new once script that expects an Element (so it can use setAttribute or getAttribute). The change here would pass the <html> element as the context for all behaviors. and make it possible to do 

once([context], 'myonce');
CommentFileSizeAuthor
#24 interdiff_18-22.txt4.43 KBVidushi Mehta
#23 3160052-22.patch4.43 KBVidushi Mehta
#18 core-3160052-18.patch4.01 KBnod_
#17 core-3160052-17.patch2.86 KBnod_
#14 3160052-14.patch1.42 KBandypost
#2 core-attach-3160052-2.patch2.36 KBnod_

Comments

nod_ created an issue. See original summary.

nod_’s picture

nod_
Primary language French
Location Lille
commented
Status: Active » Needs review
Related issues: +#2402103: Add once.js to core
StatusFileSize
new core-attach-3160052-2.patch2.36 KB
nod_’s picture

nod_
Primary language French
Location Lille
commented

The change shouldn't break anything because if you use context as document it would cause issues on ajax calls where the context is an actual dom element.

droplet’s picture

droplet commented

This change is harmful.
Since the new Once has been handled BC problems for old scripts, I will close the door.

No matter the Once support that or not, I also say the below usages are bad practice:

$('IF-YOU-CANNOT-PREDICT-WHAT-YOU-PASSED').once('myonce');
$(window).once('myonce');
$(document).once('myonce');

A. If your script has a target element, registered the once on that element.
B. If your script has no element, and `window|document` is your target (It's not common. If you have a good example, please share to me)

First,
do whatever you do to prevent the script from running twice outside the Drupal before the quick tool:

DO

$('html').once('myonce'); // hard-coded

DON'T

$(context).once('myonce'); // If context is `html`, hard-coded it. If not, go back to A.

Second,
Do NOT put the script inside `Drupal.behaviors.*.attach`, that meant never re-execute the script again. (, if Drupal CodeStandard allowed)

** Including the same script and has no intended to execute the script twice is a bug. Once is not help to prevent bug happens.

nod_’s picture

nod_
Primary language French
Location Lille
commented

To be clear, I'm not encouraging people to do once([context], 'myonce'). I'm just saying that it should be possible. There is no reason it should be broken. Code that works on ajax request and break on the page load is simply bad and should be fixed. People can't assume context will be document because it's true only on page load, not during ajax requests. I'd be surprised if anybody notices the change.

I agree about the bad practices you're mentioning. And yes, everyone should do A. I dont have a good use-case for B.

Having a behavior run only once could be useful (That's what I understood from hardcoding the 'html' in the selector) and we should open an issue for that because it could get rid of most behaviors on ajax calls, so performance would be better. It's not in this issue that we should.

It's a lot of text to say: 

# Before
context = document
# After
context = document.documentElement

I say nobody will see it because both Document and Element inherit from Node, so they share the same features also querySelector and querySelectorAll methods comes from the ParentNode mixin that is applied to both Document and Element.

nod_’s picture

nod_
Primary language French
Location Lille
commented
Related issues: +#2367655: Control the list of behaviors run by Drupal.attachBehaviors, +#2474019: Implement before and after behavior ordering
avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

The documentation doesn't say to use $(context), but (for example) $('input.myCustomBehavior', context).

(function ($, Drupal) {
  Drupal.behaviors.myModuleBehavior = {
    attach: function (context, settings) {
      $('input.myCustomBehavior', context).once('myCustomBehavior').each(function () {
        // Apply the myCustomBehaviour effect to the elements only once.
      });
    }
  };
})(jQuery, Drupal);

context is the same type of context $(selector, context) gets as second parameter.

This issue doesn't aim to remove context or suggest that context should never be used. It aims to simplify what object attach() gets.

Maybe few modules would get an error because they try to access a method that context doesn't have because they get Document in that parameter, but I think it's still a change that avoids issues, at least in some cases.
Moving away from jQuery, it's probable that more modules will get errors because what they get as context is really Document.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

Are there cases where converting $(selector, context) to plain JavaScript I need to check what exactly is context? If the answer is yes, that would be a reason more to make the change proposed here.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

andypost’s picture

andypost
he/him
Primary language Russian
commented
StatusFileSize
new 3160052-14.patch1.42 KB

quick re-roll, btw I think few other comments needs to be improved as well

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Issue tags: +Needs change record

This also needs a change record, it is not impossible that someone is relying on the existing behaviour somehow.

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented

Wouldn't this change be disruptive for any behaviors that are relying on the context being Document object? I understand that depending on Document is wrong because the type definition allows it to be either Document or Element. However, since attaching a behavior on a site tends to happen relatively consistently, it is possible for code that only expects a Document to continue working without adverse effects.

That said, I'm in favor of this change because it's making the API more consistent, and makes it even more explicit that behaviors should not expect the context to be solely the Document. It also simplifies the use of the Once library because the type of the context is consistent.

nod_’s picture

nod_
Primary language French
Location Lille
commented
StatusFileSize
new core-3160052-17.patch2.86 KB

updated the bigpipe call, and changed the default argument for detachBehaviors as well.

nod_’s picture

nod_
Primary language French
Location Lille
commented
StatusFileSize
new core-3160052-18.patch4.01 KB

missed a few spots

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative

Moving to NW for the change record.

This doesn't require any kind of test?

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Issue tags: +Needs tests

I think this could have a test that relies on the context being the <html> element, this will avoid us breaking this functionality again in the future.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented 
+++ b/core/misc/drupal.js
--- a/core/modules/big_pipe/js/big_pipe.js
+++ b/core/modules/big_pipe/js/big_pipe.js

+++ b/core/modules/big_pipe/js/big_pipe.js
@@ -115,7 +115,7 @@
   // Attach behaviors early, if possible.
-  Drupal.attachBehaviors(document.body);
+  Drupal.attachBehaviors(document.documentElement);
 
   // If loaded asynchronously there might already be replacement elements
   // in the DOM before the mutation observer is started.

Should we also change the observer to attach to document.documentElement for consistency?

Below this code we do...

  // Start observing the body element for new children.
  observer.observe(document.body, { childList: true });
longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

Re #21 will anything get added to <html> but outside of <body>?

Vidushi Mehta’s picture

Vidushi Mehta commented
Status: Needs work » Needs review
StatusFileSize
new 3160052-22.patch4.43 KB

#18 was not applying on big_pipe.js with the latest pull so rerolled the patch with #21 comment.

Vidushi Mehta’s picture

Vidushi Mehta commented
StatusFileSize
new interdiff_18-22.txt4.43 KB

Adding interdiff for the same.

Status: Needs review » Needs work

The last submitted patch, 23: 3160052-22.patch, failed testing. View results

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.