Use Frontend's options for Popup and DisplayFloat

[siikamiika]

The issue was first noted in #439 (comment), but it turns out that the issue is not limited to the Popup class and DisplayFloat should also be updated when the Frontend using it changes.

#417

[siikamiika]

In order to make #412 possible, there has to be a centralized place that determines which profile is used. I think this should be Frontend. This means that the pressed modifier is stored in Frontend until the popup closes.

In the case of #389, DisplayFloat would send a message to its Frontend that actually changes the profile when the button or hotkey is pressed, or dropdown item is selected.

Search page is an exception since it has no Frontend (search-frontend.js creates a new popup).

[siikamiika]

@toasted-nutbread Which one do you think is the best:

1. Broadcasting optionsContext from Frontend to everyone who shares the same Popup.id
2. Broadcasting options as-is without context, making Frontend the only place within popups that queries options from the backend
3. Broadcasting profile index or ID, similar to Switch matching profiles #389

Performance wise this could go either way. If a tab has lots of frames there will be lots of noise when using apiBroadcastTab. However, it's faster and more consistent than letting everyone query options (takes away one hop).

There's an issue that API functions like apiTermsFind use optionsContext to decide different things. If they should be that way and it's not viable to move their invocation to Frontend, option 2 is a no-go.

optionsContext is sometimes ambiguous. If some profile is explicitly chosen (#389), option 3 could be the way to go. It's not necessarily something to do in the scope of this issue. It's compatible with option 1 because optionsContext has index.

[siikamiika]

It also seems possible to use window messaging to propagate options from Frontend to DisplayFloat through Popup, improving the performance.

[toasted-nutbread]

Maybe the optimal choice might be a combination of 1 and 2. Frontend (or similar for search.html) could observe when changes to options and optionsContext occurs, and instruct the Display to update accordingly.

You're right that there are about 5 places where Display uses optionsContext, so I don't think that can be removed entirely. However, it can be made more up to date for values that change (URL, etc.), and Frontend would seem to be the place to do that.

It also seems possible to use window messaging to propagate options from Frontend to DisplayFloat through Popup, improving the performance.

This would definitely be the option we want to use, since it's already how the DisplayFloat instance is instructed what to display.

---

Another thing that I've noticed about the some of the codebase is that options is passed/used as a monolithic object for various classes and functions. This means that the implementation is somewhat dependent on the structure of the options object. This is not necessarily an issue, but I'm wondering, in general and where possible, if it's better to pass a subset of only the relevant options.

I kind of did this in #442, by changing options/optionsContext parameters to details. It does come with its own set of potential problems, such as needing to destructure/restructure the options into a different format, but on the other hand, the "details" convention. I can't find the comment, but I think I remember making one about how that's a common pattern in JS.

[siikamiika]

Maybe the optimal choice might be a combination of 1 and 2. Frontend (or similar for search.html) could observe when changes to options and optionsContext occurs, and instruct the Display to update accordingly.

Ok. Frontend currently sets the options directly to Popup, and they could also be set to DisplayFloat by the popup. The Popup.url getter should probably be removed in favor of data updates from Frontend.

Another thing that I've noticed about the some of the codebase is that options is passed/used as a monolithic object for various classes and functions. This means that the implementation is somewhat dependent on the structure of the options object. This is not necessarily an issue, but I'm wondering, in general and where possible, if it's better to pass a subset of only the relevant options.

I kind of did this in #442, by changing options/optionsContext parameters to details. It does come with its own set of potential problems, such as needing to destructure/restructure the options into a different format, but on the other hand, the "details" convention. I can't find the comment, but I think I remember making one about how that's a common pattern in JS.

I've noticed this development and I'll try to avoid passing it completely where possible. The problem is that it contains things that affect both frontend and backend logic. To avoid having the options object in places other than the backend, maybe there could be separate API functions or other mechanic to get frontend settings specific to some feature.