[JENKINS-72745] "Manage Jenkins" nested context menu can stay open when parent menu closes

[ridemountainpig]

See JENKINS-72745.

Testing done

CleanShot.2025-02-10.at.09.50.14.mp4

Proposed changelog entries

• Fix "Manage Jenkins" nested context menu can stay open when parent menu closes

Proposed upgrade guidelines

N/A

Submitter checklist

Preview Give feedback

1. The Jira issue, if it exists, is well-described.
2. The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

Preview Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[daniel-beck]

Used in

jenkins/src/main/js/components/dropdowns/autocomplete.js

Line 96 in e34bdcf

e.dataset["hideOnClick"] = "false";

originally introduced in 3c67676.

I was unable to identify a difference in behavior as a result of this PR (e.g., in the "Copy From" textfield on the new item dialog), so perhaps I'm just missing how this is supposed to work? If it's not needed anymore or compensated for somehow by this new code, the data- attribute should not longer be set.

Pinging @zbynek as the original author who might be able to help with this question.

[zbynek]

If we no longer read the data- attribute, we can indeed remove the assignment 👍

[daniel-beck]

@zbynek Thanks for confirmation.

Can you think of a widget that would be affected by the attribute, where this change may change behavior? The autocomplete popup of the "Copy from" text field doesn't seem to change behavior when I edit the data- attribute in the DOM. I feel like I'm missing something.

[zbynek]

My PR disables Tippy's default hideOnClick only for autocomplete, this PR disables it for all other dropdowns. So PR won't change behavior of autocomplete. It'ts the dropdowns that are not autocomplete that changed behavior in this PR:

For context menus clicking the chevron (downward triangle) the second time no longer closes the context menu. If that's still a desired behavior, the data- attribute is still needed (and should be read in the click handler to decide how to handle clicks in reference element).

[daniel-beck]

@zbynek Thanks for clarifying. That seems like a problem.

open.mov

[ridemountainpig]

@daniel-beck I have updated the code to fix this problem. Thank you.

jenkins.mp4

[daniel-beck]

@ridemountainpig Thanks. Unfortunately now the fields where this was previously left open close when they shouldn't:

close.mov

That's what the hideOnClick was used for. Could this behavior be retained, or does the fix for this require that we change one of the previous behaviors (stay open on autocomplete / close in other cases)?

[ridemountainpig]

@daniel-beck I have updated it. Could you please check it again? Thank you.

jenkins.mp4

[daniel-beck]

Appears to work great, thanks! 👍

[krisstern]

I like this logic

[krisstern]

Looks like there is some formatting issues with prettier. From the logs we have:

[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.15.1:corepack (prettier) on project jenkins-parent: Failed to run task: 'corepack yarn exec prettier --check .' failed. org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

[zbynek]

Looks good. One potential performance issue is that each instance adds a new event listener to document that never gets removed, but probably with the expected number of tooltips this won't cause visible slowdown.

[zbynek]

Why check for click on visible dropdowns and not all of them? I think something like

isClickInAnyDropdown = !!event.target().closest('[data-tippy-root]')

should be enough (?)

[ridemountainpig]

I have updated the code, and it works great. Thank you.

[daniel-beck]

probably with the expected number of tooltips this won't cause visible slowdown

Does this interact poorly with widget refreshes every few seconds?

[zbynek]

Does this interact poorly with widget refreshes every few seconds?

The instances are created when you hover over the chevron, so if you keep the mouse cusor over the specific area and let the page reload a N times, you'll get N additional event handlers.

Stale