Skip to content
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

chore(html): anchor by attachment index, not by attachment type #33295

Closed

Conversation

Skn0tt
Copy link
Member

@Skn0tt Skn0tt commented Oct 25, 2024

This PR changes how we link to an attachment element. Right now, we have &anchor=video and &anchor=diff to navigate to certain kinds of attachments. By changing this into &anchor=<attachment index>, we can make it navigate all attachments. For elements like the diff view that display data from multiple attachments, we use the smallest display attachment index as a representant.

Came out of #33267 (comment).

Copy link
Contributor

Test results for "tests 1"

1 failed
❌ [playwright-test] › runner.spec.ts:118:5 › should ignore subprocess creation error because of SIGINT @macos-latest-node18-1

2 flaky ⚠️ [installation tests] › playwright-electron-should-work.spec.ts:44:5 › should work when wrapped inside @playwright/test and trace is enabled @package-installations-macos-latest @playwright/test
⚠️ [chromium-page] › page/page-event-popup.spec.ts:149:3 › should not treat navigations as new popups @ubuntu-20.04-chromium-tip-of-tree

36675 passed, 626 skipped
✔️✔️✔️

Merge workflow run.

@pavelfeldman
Copy link
Member

Neither old nor new code makes much sense to me, so I might be missing something. Would it make sense to generate attachment hashes and use regular fragment navigation to reveal them?

@Skn0tt
Copy link
Member Author

Skn0tt commented Oct 30, 2024

Would it make sense to generate attachment hashes and use regular fragment navigation to reveal them?

That was my first approach, but Dima wasn't super happy about it. Let's discuss this with the entire team.

@pavelfeldman
Copy link
Member

Note that I changed code under your feet. As a drive-by I fixed a fairly fundamental problem where search params were not a part of the react state. Maybe it affects your implementation.

@Skn0tt
Copy link
Member Author

Skn0tt commented Nov 11, 2024

closing in favour of #33537

@Skn0tt Skn0tt closed this Nov 11, 2024
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.

2 participants