Clicking on an anchor link within a WYSIWYG navigates to anchor

I have not been able to reproduce the issue in any of their demos, actually. You can try it for yourself: https://ckeditor.com/ckeditor-5/demo/feature-rich/

That is the reason I have not reported it upstream and instead reported it here. Happy to open a ticket, though, if we’re able to reproduce it in a non-Drupal setting.

Removing the [upstream] badge until we can confirm that this is reproducible upstream.

I found the culprit. It actually does not have to do with the CKEditor module at all, but rather form.js. This file (found at core/misc/form.js) adds a click event listener to all anchor links on the page which will trigger a fragment interaction event, causing the browser to navigate to the anchor target. It targets all anchor links indiscriminately, without regard to where it might be located:

  /**
   * Binds a listener to handle clicks on fragment links and absolute URL links
   * containing a fragment, this is needed next to the hash change listener
   * because clicking such links doesn't trigger a hash change when the fragment
   * is already in the URL.
   */
  $(document).on(
    'click.form-fragment',
    'a[href*="#"]',
    debouncedHandleFragmentLinkClickOrHashChange,
  );

I believe the solution here is to amend the selector passed in the second argument to $().on() so that links found inside a WYSIWYG editor are excluded from the query. I will be submitting merge requests for Drupal 9.5.x-dev and 10.1.x-dev shortly.

Since this doesn’t actually have anything to do with the CKEditor core module, I changed the Component field on this issue to “javascript”, though perhaps there is a more appropriate selection?

I could use some guidance on the proper way to submit MRs against multiple branches. Should I create a child issue for the 10.1.x-dev branch and create an MR from there?

Kind friends showed me the way. I’m closing my MR, changing the target version on this issue, and submitting a new MR that targets 10.1.x.

Thank you for the review @sonam.chaturvedi.

Oh wow — so it's a regression on the Drupal core side simply because CKEditor 4 used

s, and CKEditor 5 doesn't! 🤯

What a magnificently obscure bug, and epic work shepherding this in the right direction, @agarzola! 👏

I did some digging in an attempt to find alternative ways to limit the selector’s scope, but I found that what is proposed in the MR is not only adequate, but the correct solution.

My original concern (and I believe it’s @wimleers’s concern as well) was that perhaps other text which may potentially include one or more legitimate anchor links might get included inside of .form-textarea-wrapper (as a sibling of the textarea element and WYSIWYG editor). I can only think of one such element that might be included and that is helper text, so I did a test locally and it turns out that helper text is not injected into the .form-textarea-wrapper container element, so it is not at risk of getting left out of form.js’s purview with the query selector in my merge request. I have attached a new video showing this in action. The video shows my fix preventing the anchor link within the CKEditor UI from working (as intended). The field has helper text that includes an anchor link. Clicking on the anchor link correctly navigates to the anchor, as intended.

Respectfully, I am marking this back as Needs review and marking the conversation as resolved, as I believe that the solution in the MR is adequate. Please let me know if this is not proper procedure to get more eyes on this.

Thanks!

This is still active, as I'm working getting my test to pass.