fix: use step class name if exist in favor of a glbal (tour) classname #2109
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Size Change: +23 B (+0.04%) Total Size: 51.6 kB
|
binrysearch
approved these changes
Jul 12, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
This PR addresses the tooltipClass override issue discussed in #2105. In version 8.2.0-beta.1, individual step tooltipClass options fail to apply and override the global tour tooltipClass setting.
Solution
Partially fixes #2105
Fixed the tooltipClass precedence logic to ensure step-level options properly override tour-level settings.
Testing
Confirmed individual step tooltipClass options now take precedence over global tour settings
Verified HTML content renders correctly in Safari (resolving the 7.2.0 Safari issue)
Tested cross-browser compatibility
Additional Context
While this fix is targeted at 8.2.0-beta.1, it also provides a relatively working alternative to the broken 7.2.0 version. Version 7.2.0 has a Safari-specific bug where users cannot see steps beyond the first one when using HTML content, but in 8.2.0-beta.1 steps with HTML content are working correctly.
Question for Maintainers
Since v8 is still in beta and many users are likely still on the stable 7.2.0 release, would it make sense to create a patch release (7.2.1) specifically for the Safari HTML content rendering bug? This would allow production users to get a stable fix without having to adopt a beta version. I'd be happy to prepare a separate PR targeting the 7.2.x branch if you think this approach would be valuable for the community. But i am unsure how to make aa PR from a 7.2.0 version since master branch is at 8,2,0-beta-1