panel: mdPanelPosition.relativeTo.addPanelPosition does not work reliably/docs unclear

[oliversalzburg]

Bug

While working on debugging mdPanel-related issues, I ran into an issue with panel size/positioning.

CodePen and steps to reproduce the issue:

CodePen Demo which demonstrates the issue: https://codepen.io/oliversalzburg/pen/ExaqaRb

Detailed Reproduction Steps:

1. Open a panel that should be positioned relatively to another element.

What is the expected behavior?

Everything works as intended. Dialog opens at the desired position.

What is the current behavior?

In certain scenarios, the panel will open at an invalid location.

From my observations, in certain scenarios, mdPanel will attempt to calculate the position for the panel while the panel is still set to be hidden (via _md-panel-hidden). In those cases, getBoundingClientRect will return a rect with all 0. This negatively impacts the calculation whenever the size of the dialog must be taken into account.

https://github.com/angular/material/blob/master/src/components/panel/panel.js#L3117

The demo in the documentation actually sets a min-height for the dialog, which seems useless, until you realize it is the counter-measure against this behavior.

IMHO the correct solution would be to not rely on the bounding box calculations of invisible elements and instead show them before retrieving their bounds. The current approach is unreliable. However, if you hide a dialog (to later reuse it), you can not update the animation, because the panel is hidden and has a 0-rect bounding box. So the calculation is always wrong while the panel is in the hidden state and there is no way around that.

We currently believe this to also be the root cause for tooltips sometimes appearing off-screen and flying into position. For mdPanelAnimations, the bounding rect is also pulled for the openFrom argument. This can also potentially result in 0-rects and the tooltip will fly in from the origin.

Is there anything else we should know? Stack Traces, Screenshots, etc.

I'm still working through the specifics of this behavior and will add more details as they come up.

[Splaktar]

Thank you for investigating this. It's unfortunate that we didn't have the resources to complete addressing all of the edge cases and integrations with mdPanel. It would be helpful to have a demo reproduction, but I understand that you are still working on it and doing more investigation.

[oliversalzburg]

Here is something that might help illustrate the mdPanel-related issues I've been mentioning:

https://codepen.io/oliversalzburg/pen/ExaqaRb

The pen has 3 buttons. When you hover over a button, a panel should appear on the right side of the button. When you hover over another button, the panel should move to that button. The important aspect is that the panel is not re-created, but re-used and intended to be shown/hidden as required.

In this pen we can see two issues reliably:

1. When the pen is in its initial state and one hovers over the "Hello" button, the panel will be misaligned.

   

   This is because of the positioning issue I was talking about. While the panel is not visible, it is considered to have 0 bounds.

   Once you move to another button, the alignment is correct and it will also be correct for the "Hello" button if you hover over it a second time.

2. When you move the mouse out of the white backgrounded area, the panel is hidden. If you now move the mouse back into the area and hover over a button again, you clearly see panel: mdPanelRef.show() does not support re-opening a dialog w/ an animation #11291 happening.

   

   The panel still has the classes from the previous transition and is not shown. Line 85 has a comment with a workaround for this to allow easier inspection of case 1.