8000 Unexpected behavior with downs-only · Issue #532 · crosshare-org/crosshare · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Unexpected behavior with downs-only #532

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
revuluri opened this issue Jun 21, 2024 · 4 comments
Closed

Unexpected behavior with downs-only #532

revuluri opened this issue Jun 21, 2024 · 4 comments
Labels

Comments

@revuluri
Copy link

When an across clue is referenced in the Constructor's Note (which is visible pre-solve), as it is in this puzzle, the clue is visible even if one is in Downs-Only mode. Not a big deal, but seemed like unexpected behavior so wanted to mention it here.

@mdirolf mdirolf added bug Something isn't working good first issue labels Jun 22, 2024
@mdirolf
Copy link
Member
mdirolf commented Jun 22, 2024

Thanks for the heads up!

@Fargrim
Copy link
Fargrim commented May 3, 2025

I have a good idea of what the problem is here. The puzzleView in Puzzle.tsx is wrapped in the DownsOnlyContext.Provider but the PuzzleOverlay component, also rendered in Puzzle.tsx, is not. However, PuzzleOverlay does receive a prop for downsOnly but it doesn't pass it along to PuzzleHeading and, while it does pass it to Comments, it is not leveraged for obscuring clue tooltips for Across clues mentioned in comments.

I can't fully verify this just yet because I'm having some trouble with Firestore locally so I don't think changes to the Downs Only flag in user settings is sticking but I should be able to once that is working again.

I think the best solution is to promote the DownsOnlyContext.Provider so that it covers all of the components rendered within Puzzle.tsx. Then we can pull the value out of context where needed and stop drilling it down where it is currently used. That should also make the ClueReference just work because it is already attempting to useContext(DownsOnlyContext).

@mdirolf
Copy link
Member
mdirolf commented May 3, 2025

That sounds exactly right to me

@mdirolf
Copy link
Member
mdirolf commented May 4, 2025

Fixed in #543 - awaiting deploy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants
0