Page MenuHomePhabricator

Notifications Popup is underlying Hovercards, should be on top
Closed, InvalidPublic


When Hovercards are enabled, the popup has a higher z-index than the Notifcation (Notices) popup, which it shouldn't have.

giphy.gif (336×480 px, 441 KB)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

if we understand the issue, this doesn't seem like it's necessarily incorrect behavior.

Wait, isn't Notices for the user more important than a Page Preview?

Reopening this but still not convinced that this is an issue requiring our attention. What I'm seeing is that if I leave my Notifications Panel open for some reason (why?) then go and hover over something to get the hovercard, what I arguably want is to see the hovercard. Which I do. I'm happy. What's the problem?

@Pginer-WMF, what do you think?

Some thoughts:

  1. I don't think that we need to decide what is shown on top based on the general importance for the user for those elements. As Joe pointed in the case of hovering a link the specific context is the user being interested in that particular piece of information. So getting it may be expected. It would be more problematic if hovercards remain open and the notification panel opened behind them when the user tries to open it. Fortunatelly, thanks to the transient nature of hovercards, this is not possible.
  2. In general terms of layout consistency it is true that intuitively the "chrome" is often considered to be above the content. According to this, any part of the content (paragraphs of text or hovercards) should be below the more persistent controls in the "chrome" such as the notifications panel. We need also to consider that if the notification panel had links for which hovercards are shown, those would appear on top of the notification panel. So the change would be about making the hovercards to be one step higher than the link they point to. Therefore, it seems the change is about Hovercards and not the notification panel.
  3. In practical terms hovercards are shown below the link when there is room for it, so the overlap case is even more of an edge case.

Given the above considerations I'm ok with either:

  • Define more consistent guidelines on how to define the depth of UI layers as part of our design guidelines, and Hovercards to be adjusted to follow that (even if that involves showing it behind the notification panel in the example).
  • Let hovercards to be a clarification layer on top of everything until we find a more practical issue and start a wider consistency process then.
ovasileva added a subscriber: ovasileva.

@Nirzar - any thought on this? I'm okay with allowing hovercards to be on top for such cases.

Let hovercards to be a clarification layer on top of everything until we find a more practical issue and start a wider consistency process then.

this works for me. page previews are reactions to the last action, it chronologically precedes notification popup. current behavior is valid until we have layer hierarchy guidelines.

for now considering this expected behavior