Allow new_content JS event listeners access to the actual new content

Created on 29 September 2020, over 4 years ago
Updated 23 June 2023, almost 2 years ago

Problem/Motivation

Currently a cloned element is given to the event listeners of the views_infinite_scroll.new_content event. This unnecessarily restricts them from only running code on the newly added content.

Or in my use case, I wanted to move focus to the first new element if the pager had keyboard focus.

Steps to reproduce

Proposed resolution

Instead of exposing a cloned element, just expose the actual dom element.

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Postponed: needs info

Version

1.0

Component

Code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Is this still an issue with 2.0.x? If yes, please update the version and set the status active again with clear steps or (best) with a test showing what's broken.

    2.0.x is the active development branch.

    If nobody replies, we should assume this is fixed and close this issue outdated.

    Thanks!

  • πŸ‡ΊπŸ‡ΈUnited States t_stallmann

    Hi, yes this is still an issue on version 2.0 without the patch. To reproduce:

    Create a view with views infinite scroll but without the autoscroll behavior. Using the keyboard, focus the "Load more" button and hit enter.

    Desired behavior: More rows load and focus jumps to the first focusable item in the first new row.

    Actual behavior: More rows load and focus stays on the "Load more" button.

  • Status changed to Active almost 2 years ago
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Does anyone know why clone() was used before?

    -      .trigger('views_infinite_scroll.new_content', $newRows.clone())
    +      .trigger('views_infinite_scroll.new_content', $newRows)

    Doesn't really make sense to me...

    Could someone look up the issue via GitLab blame and see if there was a reason given?

  • Status changed to Needs work almost 2 years ago
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica
  • πŸ‡ΊπŸ‡ΈUnited States kentr Durango, CO

    @anybody

    Could someone look up the issue via GitLab blame and see if there was a reason given?

    I don't see a reason. Looks like it was added in commit 95af31da for #3068579: Add a jQuery event when new content is loaded β†’ .

    Since the second argument of .trigger() is used to pass data to event handlers, the .clone() might have been to prevent mutation of the $newRows object by buggy event handlers.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Thanks, someone should please create a MR from the patches.

  • πŸ‡ΊπŸ‡ΈUnited States kentr Durango, CO

    I'll do it.

  • Pipeline finished with Success
    7 months ago
    Total: 298s
    #341008
  • Pipeline finished with Success
    7 months ago
    Total: 166s
    #342588
  • Pipeline finished with Success
    7 months ago
    Total: 161s
    #342703
  • πŸ‡ΊπŸ‡ΈUnited States kentr Durango, CO

    There's an MR for review.

    I kept the .clone() because the other changes solved the OP issue of focusing the first new content item and it's unknown why the .clone() was used.

    I added tests and fixed some issues with the preexisting test. There are details in the commit messages. I'm happy to revert anything that's problematic.

    As a separate issue, the call to .trigger() looks incorrect to me for the current version of jQuery. As it is, event handlers receive the new content items as individual arguments instead of as a single jQuery collection object. jQuery docs say to pass the data wrapped in an array or a plain object, but that would break BC.

Production build 0.71.5 2024