Autocomplete panel should base width on input-container, not input

[willshowell]

Bug, feature request, or proposal:

Bug

Expected

The autocomplete panel does not change its width when the input resizes, only when the input container does.

Current

The autocomplete panel resizes when an mdSuffix is rendered, thus changing the size of the actual input.

Reproduction

https://plnkr.co/edit/VrcrcUBKbwuoOoxc8byM?p=preview

Motivation

Using a "clear input" button on an autocomplete input

Proposed change

/** Returns the width of the input element, so the panel width can match it. */
private _getHostWidth(): number {
-  return this._element.nativeElement.getBoundingClientRect().width;
+  return this._inputContainer
+    ? this._inputContainer._elementRef.nativeElement.getBoundingClientRect().width
+    : this._element.nativeElement.getBoundingClientRect().width;
}

[crisbeto]

I think this needs to be thought through a bit better. Apart from taking the width from the container, the autocomplete would also have to position itself relative to it, otherwise it'll be off if there's a prefix. This complicates things, because the container has some padding at the bottom, which will cause the panel to float ~10px below where it should be.

[willshowell]

@crisbeto what if it were instead attached to the container's underlineRef like datepicker is doing

[crisbeto]

That should work, I wasn't aware that we were even exporting that reference. I'll update my PR.

[crisbeto]

Thinking about it again, the underline isn't ideal either: if we use it as a reference, the panel will end up overlapping the input when it goes into the above position. This also happens on the datepicker and has been on my list of things to investigate.

[willshowell]

Oh true. You could do what autocomplete is doing with its negative margin when above, but I realize that's not an ideal solution.

[crisbeto]

Not really, we shouldn't know or have to measure the height of the input.

[willshowell]

Do you suppose the position strategy could be more flexible to support something like

• connect to bottom of underlineRef
• fallback to top of inputContainer

.connectedTo(
    this._inputContainer.underlineRef,
    {originX: 'start', originY: 'bottom'}, {overlayX: 'start', overlayY: 'top'})
  .withFallbackPosition(
    this._inputContainer,
    {originX: 'start', originY: 'top'}, {overlayX: 'start', overlayY: 'bottom'});

[crisbeto]

I can see how adding that to the API could be useful, but I'm not sure that it would help here either. Positioning it to the top of the container would still add a lot of space to the panel offset due to the space that is reserved for the floating label.