Skip to content

Conversation

@crhallberg
Copy link
Contributor

Text limit was trying to measure the height on elements that weren't rendering in the DOM yet (always 0). A slight pause (100ms) seems to resolve this.

Was built off of #1463 for ease - can likely be cherry-picked. Resolves #1464.

@vercel
Copy link

vercel bot commented Jun 26, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
universalviewer ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 26, 2025 3:41pm

@crhallberg crhallberg changed the title fix: add short delay so elements can render. Fix textLimit issues in MoreInfo Jun 26, 2025
@crhallberg crhallberg requested a review from demiankatz June 26, 2025 15:41
Copy link
Contributor

@demiankatz demiankatz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @crhallberg, this fixes the problem for me. I also poked around with config settings a bit to see if I could find a way to get a "flash of unstyled content" type of problem, but I was unable to do so. Maybe there are edge cases where a problem could occur if there's long text near the top of the sidebar, but I think generally the loading and animations take more than 100ms, so things are as they should be by the time they are visible to the user.

Now we're left with a dilemma about how and when to fix this bug, since the fix seems to depend on changes to the metadata component. I believe this leaves us with three options:

1.) Fix the metadata component, issue a new release, and upgrade the component in UV's release-4.2 branch.

2.) Backport the whole component reintegration work from #1463 to the release-4.2 branch and apply the fix there.

3.) Apply the fix to #1463, leave release-4.2 broken, and prioritize getting release 4.3 out more quickly so the bug fix becomes available.

Option 1 is probably the most conservative, while still getting us a release in a timely fashion.

Option 2 is similar to option 1 with the advantage of being less work to implement but the disadvantage of being a larger change for a patch release.

I don't really like Option 3 very much because I think it leaves us with a broken 4.2.x line and will take longer to get out the door... but in some ways it's the path of least resistance.

Opinions, anyone?

@Geoffsc
Copy link
Contributor

Geoffsc commented Jun 26, 2025

Nice catch, I am good with the code as written and tend to favor Option 1 fix-wise. Only other thing I thought would be worth mentioning is the commit that Demian believes broke this, for historical purposes.

@demiankatz
Copy link
Contributor

Thanks, @Geoffsc, and full credit to @crhallberg for doing the git bisect work to identify that problem commit. :-)

@LanieOkorodudu
Copy link
Collaborator

Thanks @crhallberg , for taking the time to fix the issue, really appreciate it. And of course, thanks to you too, @demiankatz, for spotting the bug in the first place. Nice work, both of you! Seems like Option 1 might be the best way to go, but I’ll leave it to you guys, you’re the experts here. Thanks again!

@demiankatz
Copy link
Contributor

I have gone through option 1 as recommended by @Geoffsc and @LanieOkorodudu. I am merging this PR now so that #1463 reflects the latest release of iiif-metadata-component. The fix to address #1464 for earlier UV versions can be found in #1471.

@demiankatz demiankatz merged commit d88f22b into UniversalViewer:issue-1399-dependency-consolidation-iiif-metadata-component Jun 30, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants