Per eng meeting, this investigation focuses on solutions regarding state management and accessibility will be resolved in the parent task.

without doing additional research, imo the easiest thing to do would be to pass a parameter like ?openInfobox=true in the url and prioritize that over the user preference. Since the user won't click open/close the infobox (theoretically), we won't update any preferences. We could also explicitly ignore those clicks if the parameter exists. If we do want to save the user preference to open, we could do it in the same check for the openInfobox parameter to expand the infobox. Whether or not we want to sounds like a design question? @Prtksxna? Should navigating to a Special:Contributions page from the popup save the user preference for keeping the infobox open as true? (sorry if this has been answered elsewhere)

Given that there's nothing to indicate to the user that we're saving their open/close preference, I think there's something a bit odd about conditionals on top of our hidden conditional. For instance:

• a user clicks on the popup to go to the special:contributions page (infobox open on load)
• they navigate to another ip (infobox is closed on load) and they open it
• the next time they navigate to an ip it's open on load

I don't really know what to say about that besides it's something that could happen. I suppose eventually the user will figure it out?

Okay I came up with a bunch of bad ideas so yes, I think a parameter is the most non-invasive way to pass a one-off flag and it should be prioritized over the user preference if the parameter is set. It can be hardcoded as part of the href in the popup as part of T293723: Clicking the popup should take you to Special:Contributions/$ip. If the user interacts with the infobox after load (closing and then expanding it again), we should continue to watch for that and record the preference like we currently do.

Some bad ideas:
tl;dr - most of these are too persistent or invasive for what should be a one-off setting.
Set the user preference: imo too persistent but also setting this would be afaik asynchronous and couldn't be guaranteed by the time the user loaded the next page
Set the (temporary) user preference: bloats the user prefs table and again, imo too persistent
Set a cookie: We don't really set cookies when we don't have to and it would also last too long for what we want

In T296695#7543361, @STran wrote:

@Prtksxna? Should navigating to a Special:Contributions page from the popup save the user preference for keeping the infobox open as true? (sorry if this has been answered elsewhere)

We don't want to update the user setting unless they manually open/close the accordion

This LGTM. Being bold and moving this to Done: Q2 2021-22. @STran: Please could you make sure that the parent task is up to date. Thanks!