281859 - Autocomplete widget caches key event

Status: RESOLVED WONTFIX

(Toolkit :: Autocomplete, defect, P3)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

If the user is typing something in an autocomplete text box and hits the enter
key before the autocomplete search which was initiated by the beginning of text
input has finished, the enter key event is cached by the widget. 

Unfortunately the DOM event which is cached refers to a nsEvent which is stack
allocated, so that when event dispatch completes it goes away. This does not
appear to be a problem for most autocomplete implementations in Firefox at
present because all of them happen pretty much synchronously (e.g. history lookup). 

The problem comes when you use an async lookup that requires network activity
which will not lock the UI - e.g. LDAP or something like that - by the time the
search finishes the cached event now points to random bits. The effect is that
that event cannot be fired and expect reliable things to happen. 

The autocomplete widget needs to cache the metadata that describe the key event,
and then create a new key event when the search completes and dispatch it.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

...or we could make nsDOMEvent not suck at some point...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that this actually came up on www-svg recently; the point was made that an
event object doesn't really have defined behavior once event dispatch is
complete.  I agree that nsDOMEvent sucks, but why is this code caching
nsDOMEvents exactly?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Because nsDOMEvent::DuplicatePrivateData() is now implemented in 1.8.1 and
trunk, there is no need to change autocomplete widget.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

So I'd say WONTFIX