Oh, actually, we probably started throwing when the patch for bug 407359 landed. That patch assumes that mInput is a autocomplete.xml-implemented nsIAutocompleteInput, which isn't always the case (e.g. for content autocomplete, where we get the impl from nsFormFillController instead). The patch for bug 419725 just changed the error.
I suppose there a couple of ways to fix this - we could detect the underlying nsIAutocompleteInput implementation in that popuphiding handler somehow and behave differently based on that, or have content and chrome autocomplete use different popup implementations.
Oh, actually, we probably started throwing when the patch for bug 407359 landed. That patch assumes that mInput is a autocomplete. xml-implemented nsIAutocomplete Input, which isn't always the case (e.g. for content autocomplete, where we get the impl from nsFormFillContr oller instead). The patch for bug 419725 just changed the error.
I suppose there a couple of ways to fix this - we could detect the underlying nsIAutocomplete Input implementation in that popuphiding handler somehow and behave differently based on that, or have content and chrome autocomplete use different popup implementations.