Wp-calypso: Tooltip: register a z-index at or below 179

[rickybanister]

The tooltip's z-index (popover is currently z-index: 1000) is placing it in front of the notifications panel (z-index: 180).

It should be properly registered with the z-index mix-in thing (if it's not already) and should be at or below z-index: 179. We should test a number of places to make sure this doesn't cause any further regression. It's possible the tooltip only needs to be z 2 or something very low.

To reproduce, test out adding an invalid email address to the people invite form and then open the notification browser panel with your screen narrow enough for the error to overlap.

cc @ebinnion

[BrookeDot]

Still valid, although the message text has changed making it a bit harder to get the message to overlay at least for invites.

[hoverduck]

Another signature of this is that on the mobile width layout the tooltip remains visible even when the field it comes from is out of view:

[hoverduck]

bug-scrub

Confirmed this is still a problem, but I'm going to go ahead and close it for inactivity. Feel free to re-open if there are any user complaints about it.

[rickybanister]

If this is still broken, why would we close it?

@ebinnion the field mentioned above is for the invites form, do you think we could take a look at fixing the z-index there, or perhaps triggering a hide on the tooltip if something else is clicked?

[hoverduck]

We're doing weekly bug scrubs to try and clean out the large backlog of open issues. The thinking is that if nobody's commented on it in months, it's probably not important enough to warrant somebody taking the time to fix it.

And closing it also serves as a ping to everyone involved in the ticket, so it can be re-opened if there's any disagreement.

[ebinnion]

I can take a look at it some time, but I'm still pretty busy with JP 4.2 cleanup.

[hoverduck]

Re-opening

[designsimply]

bug-scrub

If this is still broken, why would we close it?

Closing an issue that is not tied to a milestone and that has not been fixed for an inordinate amount of time is essentially a vote for a wontfix, and you can always re-open if you think it shouldn't be closed.

I think this issue, which was opened 283 days ago and has not had any activity for 97 days and appears to be low priority, is unlikely to be fixed and should be closed unless it is deemed important enough to be placed into a milestone where it can get reviewed and resolved. An upcoming maintenance sprint would be perfect for an issue like this!

[BrookeDot]

An upcoming maintenance sprint would be perfect for an issue like this!

Agreed, but if we are closing these issues how would they be found during a sprint? Perhaps we should create a new label for things that are closed due to inactivity but are still issues.

Another idea would be to label them "Good first fix" (if they fit that label like this one dose) and see if that helps them gain traction.

[rickybanister]

This issue kind of kills me, it would take a dev with any knowledge of the z-index stuff approximately 90 seconds to fix, much less than the meta conversation here around whether to close it or not.

@ebinnion I'll buy you whatever you want if we can just get this closed out today, it really shouldn't be hard to change the tooltip's z-index.

[designsimply]

Agreed, but if we are closing these issues how would they be found during a sprint?

Good question! We should aim to fix the highest impact, most severe issues first. Once that happens (!) then the other smaller issues can either be reopened or will resurface naturally if they weren't already made obsolete by other updates.

The minutia can really weigh things down. It can be hard to see the bigger picture in that sometimes. It is great to fix small issues when possible, and as long as it's done in a way that doesn't detract from agreed upon goals, then taking time out to fix them is okay—maintenance sprints are fabulous for this! BTW, if you setup a maintenance milestone with a date on it, then it will be less likely to be closed by the Flow Patrol team sooner because it's part of planned work. When normal to low priority issues that aren't part of any milestone linger for a long time, then they are not helpful to have around because the main goal is to raise the quality level in a more efficient way that helps the largest number of people the fastest.

[designsimply]

This issue kind of kills me, it would take a dev with any knowledge of the z-index stuff approximately 90 seconds to fix, much less than the meta conversation here around whether to close it or not.

I try not to make assumptions like that, and devs should not always be pulled off of other work to fix small issues because it can be disruptive to project work, especially if it happens a lot. Planning an issue into a maintenance sprint would be a better option. Let me see if I can help get that sorted!

Aside: I don't mind the discussion around this issue in this case because it doesn't happen often and because sometimes it's nice to work things out and get everyone on the same page. 😊

[alisterscott]

I've had an attempt at fixing this bug in #9887, any help with testing this is most welcome.

I've split out the navigating away behaviour mentioned by @hoverduck above into #9888 since this isn't related to z-index, it looks like there needs to be an event added for navigating away that hides the tooltip

[ebinnion]

For what it's worth, it took me closer to 30-45 minutes and a dive through z-index stacking contexts and our z-index helper works.

I've split out the navigating away behaviour mentioned by @hoverduck above into #9888 since this isn't related to z-index

I would suggest that the core issue is still z-index, that the tooltip is stacked higher than the sidebar.

[alisterscott]

Reopening since #9891 was reverted by #9972

[stale[bot]]

This issue has been marked as stale because it hasn't been updated in a while. It will be closed in a week.
If you would like it to remain open, can you please you comment below and see what you can do to get things moving with this issue?
Thanks! 🙏