Attribution pop-up does not stay closed

[demiankatz]

UV version:

 universalviewer@4.1.0

I'm submitting a:

• bug report => please fork one of these codesandbox examples with a repro of your issue and include a link to it below
• feature request => please use the user stories repo
• support request => Please do not submit support requests here, use stackoverflow

Current behavior:

When a manifest has attribution information, it pops up an attribution box (assuming the UV does not have the feature disabled). The user can dismiss this box. However, after the box is dismissed, moving to the next page of the manifest causes the box to reopen. This can be quite intrusive, especially on mobile devices.

Expected behavior:

Once dismissed, the attribution box should stay closed until a new manifest is loaded. This is the behavior as of version 4.0.0, so the current behavior seems likely to be a bug introduced between 4.0 and 4.1.

Steps to reproduce:

1. Go to this manifest: https://www.universalviewer.dev/#?xywh=-2985%2C-546%2C10395%2C7888&iiifManifestId=https%3A%2F%2Fdigital.library.villanova.edu%2FItem%2Fvudl%3A60609%2FManifest&cv=5

2. Dismiss the attribution box.

3. Go to another page, either by clicking a thumbnail or using next/previous navigation. The box will return.

[demiankatz]

The relevant code can be found in this file:

https://github.com/UniversalViewer/universalviewer/blob/dev/src/content-handlers/iiif/modules/uv-shared-module/CenterPanel.ts#L128

It appears that we're setting a property called isAttributionOpen to track the state of the box, but that property is not being properly checked to keep it closed at appropriate times. However, it's not obvious to me from looking at change history when/why this stopped working. It's probably worth attempting a git bisect to see if we can narrow that down. I'm not sure if I'll have time for that today, but maybe later in the week if nobody else has a brilliant idea sooner!

[demiankatz]

I'm currently working on a git bisect to track down the cause of the problem. It was good as of commit 40f8e76 and bad as of commit c0fda72, so the problem lies somewhere in between. I'll follow up once the process is complete (it's going to take a while due to build times).

[demiankatz]

Git bisect reports that the problem comes from one of these three commits:

820b914
bf0f2a3
ef4a732

[demiankatz]

...so it looks like the issue was introduced in release 4.0.25 as part of the config type refactoring.

[demiankatz]

I've looked at the problem commits and don't really understand how they are responsible for the bug being introduced. I've proposed a solution in #1328, but it's not directly inspired by my research here, so maybe there's a better/different way forward. Interested in everyone's opinions!