Repository navigation
feat(web): open pull request links in the integrated browser - #208
Merged
Merged
Conversation
Pull request links opened T3's native pull request view, which the team does not use. A new experimental setting, "Native pull request view" (off by default), controls this. While it is off, a pull request link opens its GitHub page in the in-app browser beside the thread. That covers chat links, the sidebar, the branch toolbar, the thread PR list and the header's View PR button. Turning it on restores upstream behaviour. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…o its first message A message sent while a thread's history was still loading replaced the remembered history with a timeline that held only the pending message. The list collapsed to one row, the scroll position reset to the top, and the history then loaded above the reader, leaving them at the first message of the session. While the history loads, the pending rows are now added after the remembered history instead of replacing it. When loading finishes under a send the reader has not scrolled away from, the chat moves to the latest message. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Links went to the system browser unless Settings → Integrations said otherwise, and several surfaces ignored that setting altogether, such as the sidebar's Linear, pull request and Mattermost tags and plain target=_blank anchors. A new experimental setting, "Open links in the integrated browser", is on by default. While it is on: - the "Open links in" preference resolves to the in-app browser, so chat markdown, useOpenLink callers and the terminal follow it - a document-level click handler opens any remaining external anchor beside the open thread, after React's own handlers have had their turn - the lifecycle sidebar's link chips use the same opener Cmd/Ctrl-click still opens the system browser. With no open thread, a link behaves as before. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Every session redeemed from a member's own pairing lived seven days, and nothing renews a session. The expiry is signed into the token, and desktop and mobile store the expires_in they receive and drop the credential at that moment. So a device in daily use was cut off on day seven. The next reconnect failed with "credentials are invalid", and the device had to be paired again. bkt3's auth_sessions show every desktop and phone re-pairing on that weekly cycle. Sessions from any pairing, whether self-issued or administrator-minted, over a cookie, a bearer token or DPoP, now carry a century-long lifetime. A paired device stays paired until it is revoked in Settings → Connections. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Clicking a row's Linear, pull request or Mattermost link opened the page in the integrated browser beside whichever thread was already open. So it landed in a panel the reader was not looking at. A plain click now navigates to that row's thread and opens the page beside it. Cmd/Ctrl-click stays where it is and opens the system browser. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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
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
Clicking a GitHub pull request link opened T3's native pull request view (the right-panel PR surface or the /pull-requests page). The team does not use that view, and wants the GitHub page instead.
Fix
A new experimental setting, Settings → Experiments → Native pull request view, is off by default. While it is off, a pull request link opens its GitHub page in the integrated browser beside the thread. Turning it on restores upstream behaviour. Cmd/Ctrl-click still opens the system browser either way. With no thread to open beside (for example on the /pull-requests page), the link opens like any other link.
This covers every PR-link entry point that goes through
useOpenChangeRequestLink: chat markdown links and their hover preview, the sidebar PR badge, the branch toolbar, and the thread PR list. It also covers the header's View PR button inGitActionsControl.Fork footprint:
apps/web/src/fork/pullRequestBrowserLinks.ts, with its test.openPullRequestLink.ts(one hook plus two lines) andGitActionsControl.tsx.The /pull-requests page itself is still reachable from the nav. This PR changes only where links land.
Also: sending right after opening a long thread no longer jumps to its first message
Requested in the same review so it ships with this PR.
Cause.
resolveThreadSwitchTimeline(upstream pingdotgg#11169) paints a thread's remembered timeline only while the live timeline is empty. A message sent while the history is still loading makes the live timeline non-empty, with nothing in it but the pending message. So the long history collapsed to one row and the scroll position reset to the top. The history then loaded above the reader, who ended up at the session's first message. This is most likely on a long thread just after opening it, and on desktop, where loading takes longer.Fix (
apps/web/src/fork/threadSwitchPendingTimeline.ts, one marked seam inChatView.tsx):Verification: 9 new focused tests, the 157 existing
ChatView.logictests, the web typecheck and the marker check all pass. This was found by reading the code, not reproduced; it will be checked on expbkt3.Verification
vp test run src/fork/pullRequestBrowserLinks.test.ts: 5/5 pass.apps/webtypecheck: no errors.scripts/check-fork-markers.ts: pass.Model and harness: Claude Opus 5.5 in Claude Code (via T3 Code).
🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.