mdAutocomplete: Creates a lot of empty ul.md-autocomplete-suggestions tags

[avocadowastaken]

mdAutocomplete doesn't remove child suggestions dropdown on $destroy.

And also this will fix problem when autocomplete dropdown keeps being visible afterautcomoplete removed from DOM, (Can`t dublicate it in codepen, but this problem occures in my project)

[uriva]

+1

[Londovir]

Possibly related to this is that autocomplete can pile up numerous duplicated entries in the aria-status element as well. Use the demo site, go to the "Basic Usage" demo, and type in 'a', backspace, 'a' again, backspace, etc, multiple times, then look at the developer console. There will be a number of <p> children that keep piling up.

They appear to get destroyed if you attempt to make an autocomplete entry which has no match, as this probably resets the collection $mdAutocompleteCtrl.messages, but I would expect that every time you type (or delete) a character into the autocomplete linked box it would clear that collection to only contain the most recent appropriate message.

[Londovir]

Followup: I might have duplicated something similar to what you are describing, at least in terms of ul element still on the screen. Under IE11, a basic autocomplete is, for me, breaking badly as opposed to Chrome. I am baffled at what IE11 is doing to it at the moment. See this CodePen: http://codepen.io/londovir/pen/GJpmmr

When viewing that CodePen in Chrome, the autocomplete essentially works as I'd expect: Type or click in the box and it expands the list, click on an item and it selects that item into the input box. Although you have to click out to move the focus off and then click back in to pop open the list a second time, I'm okay with that for now and it works.

In IE11, though, it's broken beyond measure. If you click within the box, the list appears, but clicking an item does an odd flash, redraws the list again farther to the left, and nothing is selected. If you double click the item, it appears to get selected as expected. I have debugged this in IE11 vs. Chrome as being an order mismatch on events being fired. In Chrome, the focus() method of mdAutocompleteCtrl is hit first when clicking on an item in the list, followed by the handleQuery() method, and lastly the select() method. This leads to correct behavior of the self.hidden variable. In IE11, though, the order is different: select() first, then focus(), and then handleResults(), which appears to be causing the list to essentially re-open itself, potentially explaining the blinking (and the weird shift to the left).

Furthermore, at random times (but happening often), even when the list appears to disappear, if I click in the empty whitespace below the input box, the list will open once again. It's as though the list is still there in the rendered page (albeit invisible) and accepting mouse events. The culprit seems to be the bottom:auto that is getting set by the directive on the ul helper, which in IE11 results in a layout height of -0.01. If that bottom: auto is disabled, the ul collapses in IE11. I believe in Chrome that is resulting in a layout height of 0, not -0.01. Due to this issue, I believe that IE11 gets stuck in not drawing the item visually, but still listening for mouse events in these cases. The workaround I've found for this which appears to generally work is to add an ng-hide attribute to the ul element in the template for mdAutocomplete, much like the li elements have. In IE11, that appears to solve this problem.

You can replicate this with the Material demo page for autocomplete in IE11 as well. Go to the "Basic Usage" demo, click once in the box to expand the list of states, and then click to the right in empty whitespace on the page. The list of options empties of all text, but the background frame that held the options expands in height to cover everything below it. See picture below:

I feel like this is all related to the ul issue(s) you noted above in some way.