Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiple "1 Item(s) selected" #5056

Open
tectumopticum opened this issue Jul 6, 2023 · 1 comment · May be fixed by #5057
Open

multiple "1 Item(s) selected" #5056

tectumopticum opened this issue Jul 6, 2023 · 1 comment · May be fixed by #5057
Assignees
Labels
area/javascript Affects the javascript framework bug Something isn't working

Comments

@tectumopticum
Copy link

Describe the bug

In Firefox a selected item leads to multiple "1 Item(s) selected"-messages at the bottom of the view (1+n times)

To Reproduce

  1. open icingaweb in Firefox 102.12.0esr
  2. Menu "Icinga DB" -> Hosts
  3. klick in the search-field, choose "Host Name (CI)", add a host and search
  4. select the host-event and wait a few moments
  5. each automatic refresh adds a "1 Item(s) selected"-message at the bottom of the window

Expected behavior

Only one message should appear if only one line is selected

Screenshots

image

Your Environment

  • Icinga DB Web version (System - About): 1.0.2
  • Icinga Web 2 version (System - About): 2.11.4
  • Web browser: Firefox 102.12.0esr (64-Bit)
  • Icinga 2 version (icinga2 --version): 2.13.7-1
  • Icinga DB version (icingadb --version): 1.1.0
  • PHP version used (php --version): 8.0.29
  • Server operating system and version: SLES 15 SP4

Additional context

Not reproducible in Chrome

@carraroj
Copy link

carraroj commented Jul 6, 2023

ref/NC/788597

@nilmerg nilmerg transferred this issue from Icinga/icingadb-web Jul 7, 2023
@nilmerg nilmerg self-assigned this Jul 7, 2023
@nilmerg nilmerg added area/javascript Affects the javascript framework bug Something isn't working labels Jul 7, 2023
nilmerg added a commit that referenced this issue Jul 7, 2023
A listener for `rendered` should not need to check if the content
really changed. Though, if such a listener is not triggered anymore,
`beforerender` listeners also must not be triggered, as they might
assume that the content is really being updated and their accompanied
`rendered` listener is triggered. (e.g. input-enrichment.js)

This might be breaking change and any `Behavior.renderHook` implementation
needs to be checked against it. Potentially also in third party modules.
As if such an implementation updates the container on its own,
`beforerender` listeners only have access to the updated container after
this change, while they had access to the original beforehand.

`rendered` listeners should not be that much affected, as for them the
change results in the same behavior as if no update has ever been
scheduled for the container.

fixes #5056
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/javascript Affects the javascript framework bug Something isn't working
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants