"Dictionary data is updating [...]" doesn't go away after update is complete, if popup is left open

[StarScape]

I noticed this while developing. Not a critical issue by any means, but would be nice to fix at some point. If you do a fresh install, mouse over some word, get the "Dictionary data is updating, incomplete results shown." notice in the bottom, it won't go away when the download is finished, nor will the kanji and names tabs become available, until you force the popup to re-render by either mousing another word or closing and reopening it. It would be ideal if it re-rendered itself automatically once the download was complete.

[birtles]

Excellent idea. I can look at this at some point but if anyone else wants to take it, I think the implementation would probably include the following parts:

1. We need a way to send a message to all the content scripts. For config changes we do this via tab managers. We have two tab managers: active-tab-manager.ts (Safari only) and all-tab-manager.ts (all other platforms).

   This is really unfortunate and one of my long-term goals to fix. The background is that when we implemented for Safari we made it use activeTab mode since Apple seemed to be pushing that. It's better for preserving privacy but less convenient. We really want to make all platforms start in activeTab mode and let the user add permanent permission for various sites or all sites as they see fit.

   Anyway, for now we probably would add a method to both tab managers for something like notifyDbStatusChange or whatever.

   We'll need to add a suitable message to the top part of background-message.ts for this.

2. In background.ts in somewhere like onDbStatusUpdated we'd look for a change where jpdictState.words.state was 'unavailable' or 'empty', or jpdictState.updateState.type is 'updating' to a state where none of those things were true. On such a transition we'd call our notifyDbStatusChange-like function from above.

3. In content.ts in onMessage we'd pick up this new message and call a message on the ContentHandler.

4. In the ContentHandler we'd need to re-run the lookup. We do something similar when the showRomaji config setting changes so we'd basically be shadowing that (or, more likely, extracting a method we can use in both cases).

I think that would probably do it.

An alternative approach would be to try and use the DB-listener setup in the background page from each content script (the setup we currently use for synchronizing the options pages with the database state). That might be less code but it's probably a bit more risky since we'd have to check we do port management correctly when using the all tab manager.