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

Filter popover position is incorrect when its selector moves #117093

Open
lucasfcosta opened this issue Nov 2, 2021 · 4 comments
Open

Filter popover position is incorrect when its selector moves #117093

lucasfcosta opened this issue Nov 2, 2021 · 4 comments
Labels
bug Fixes for quality problems that affect the customer experience Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v7.16.0 v8.0.0

Comments

@lucasfcosta
Copy link
Contributor

Kibana version: 7.16 (SHA c5228354e5fdaf66f8466693f23f3d46d5632b88)

Elasticsearch version: 7.16

Server OS version: MacOS Big Sur 11.6

Browser version: Google Chrome Version 95.0.4638.69 (Official Build) (x86_64)

Browser OS version: MacOS Big Sur 11.6

Original install method (e.g. download page, yum, from source, etc.): I'm running Kibana from source, and connecting it to a 7.16-snapshot container from docker.elastic.co.

Describe the bug: When you open a filter popover, its position doesn't remain relative to the select it popped over from.

As you can see in the GIF below, as the popover source moves (because the modal is resized) the popover itself position changes incorrectly.

Steps to reproduce:

  1. Within Observability > Cases, create two or more cases using different reporters for each
  2. Access Uptime > Analyze Data (Exploratory View)
  3. Create a visualisation and click "Add to case"
  4. Change the "reporter" filter multiple times so that the modal also changes size and you'll see the popover position becomes incorrect.

Expected behavior: The popover position should remain where the selector which triggered it is.

Screenshots (if relevant):

moving-checkbox-selector

Errors in browser console (if relevant): None.

Provide logs and/or server output (if relevant): None.

Any additional context: This was found as I was testing elastic/uptime#322.

@shahzad31 mentioned this issue should not receive the Team:uptime label as this is not the team that maintains this component, so I'd appreciate further guidance on proper labeling here.

@lucasfcosta lucasfcosta added bug Fixes for quality problems that affect the customer experience v7.16.0 labels Nov 2, 2021
@botelastic botelastic bot added the needs-team Issues missing a team label label Nov 2, 2021
@nickpeihl nickpeihl added the Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability label Dec 8, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/uptime (Team:uptime)

@botelastic botelastic bot removed the needs-team Issues missing a team label label Dec 8, 2021
@shahzad31
Copy link
Contributor

This component isn't owned by us.

@shahzad31 shahzad31 added the Team:Security Solution Platform Security Solution Platform Team label Jan 14, 2022
@shahzad31
Copy link
Contributor

Tagging security solution, i think they work on cases plugin,

@shahzad31 shahzad31 removed the Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability label Jan 14, 2022
@yctercero yctercero added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) and removed Team:Security Solution Platform Security Solution Platform Team labels May 26, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v7.16.0 v8.0.0
Projects
None yet
Development

No branches or pull requests

5 participants