There is a bug (seemingly unreported) in Yomichan where an Anki card
will not contain any audio if the JapanesePod101 audio source trumps
a secondary audio source (e.g. JapanesePod101-alternate) where
the jpod101 source can't find the word requested.
For example, そして has an audio entry in the alternate source but not
the standard source.
(Alternatively, there may be a bug in the jpod101 audioUrlBuilder,
because I've only noticed this problem with hiragana-only expressions.
JPod101 may not host those on the same url scheme any more. I'm not
sure how to fix that, though, and the bug I'm addressing here does
still persist).
The reason this happens is that audioGetFromUrl uses downloaded audio
to effectively check for a 404 (by examining the audio duration), but
that check doesn't happen when an Anki card is being created (i.e.
"download" is set, which I've changed to "willDownload" here).
This change removes that check, but retains the will-download intent
information to prevent attempts to download tts data, which AnkiConnect
cannot do. I've also added a short explanation as to why the download
check happens where it does.
I think the unused audio object will get garbage collected since it's
not referenced again, but I've explicitly unset it as well.
The issue was that scanning on search page introduced a way to lose
focus of the query input, and the new feature that the search page
hotkey focuses an existing search page instead of opening a new one made
it more obvious.
Now every key that isn't a hotkey focuses the query input, and typing
text into the box scrolls it into view in case it wasn't there when
searching.
There is an accessibility issue that this can cause, because now tab
also focuses the query input before it focuses the next element. I
didn't implement a workaround for that because it would have been more
complicated than this simple fix.
Fixes#263
