deleting all input quickly results in empty dropdown rendered

[missinglink]

when rapidly deleting the input I experience a dropdown rendered with no labels, this does not happen when deleting more slowly.

deleting slowly:

deleting quickly:

$ grep src example.html

    <script src="https://cdnjs.cloudflare.com/ajax/libs/modernizr/2.8.3/modernizr.min.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/leaflet/0.7.5/leaflet.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/leaflet-hash/0.2.1/leaflet-hash.min.js"></script>
    <script src="https://mapzen.com/tangram/tangram.min.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/leaflet-geocoder-mapzen/1.4.1/leaflet-geocoder-mapzen.js"></script>

[missinglink]

note: I am able to reproduce on the current version hosted at http://mapzen.github.io/leaflet-geocoder

[louh]

Thanks for the report! I've seen this a few times too but didn't figure out how to reliably reproduce the problem.

[louh]

Ok, I have an explanation and a proposed fix for this.

As you might suspect, there's a race condition that surfaces when deleting input very quickly while there is a queue of throttled autocomplete requests.

The dropdown with no labels is a side effect of the showResults method reading the current input value when highlighting the labels:

if (this._input.value.length > 0) {
    resultItem.innerHTML += this.highlight(feature.properties.label, this._input.value);
}

Since there's nothing in the input anymore by the time the last autocomplete query is returned, then no labels are displayed at all. Instead, a better alternative is not rely on state outside of the showResults function, by passing it the actual query as a second parameter:

// When response is returned
this.showResults(results.features, params.text);

// [...]
    showResults: function (features, input) {
        // [...]
        resultItem.innerHTML += this.highlight(feature.properties.label, input);
    }

This fixes the no-label problem, but now the last autocomplete results will still be displayed, even after you've fully deleted your text input.

This is an effect of the throttle:

1. When a keystroke occurs and there is input text, an autocomplete request is put into a queue. When each slot in the queue is executed, a timestamp of the request is recorded (to determine, later, if a stale request should be thrown away).
2. When a keystroke occurs but the effect is to delete the input, no requests are made, and the results are cleared instantly. Timestamps are not recorded when results are cleared.

If the results are cleared (item 2) before the autocomplete queue has time to finish processing (item 1), then we see the results list pop up again as described here. This is why it only happens if you delete each character in succession very quickly: you have to build up a queue of requests first.

Updating the maxReqTimestampRendered property when results are cleared does not fix the problem: because of the queue, it's still possible to delete characters so quickly that requests at the end of the queue are begun after the input is already empty, which overwrites the timestamp of when the results were cleared.

One possible solution is to record timestamps at each keystroke (instead of at each request made), and pass it all the way through to the end to determine how recent it is. But, this seemed easier:

// in callPelias()
// [...]
        if (results && results.features) {
          // Ignore requests if input is currently blank, it is stale
          if (this._input.value === '') {
            return;
          }
// [...] then check if response is stale, etc.

The changes proposed to fix this bug are in this PR: #96

But let me know if there might be better ways of addressing this that I might have overlooked.

[missinglink]

@louh looks good!

[louh]

👍 thanks!