-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Fix #12074: Preserve container when opening View Page Source #12086
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
base: dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR fixes an issue where "View Page Source" (Ctrl+U / Cmd+U or right-click context menu) opens in the default "No Container" tab instead of preserving the container from the originating tab. This is problematic for users who need to view the source of pages while logged into different accounts across different containers.
Changes:
- Modified the
addTabfunction intabbrowser-js.patchto detect view-source URLs and inherit the container ID from the currently selected tab when no explicituserContextIdis provided
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| + // inherit the container from the currently selected tab | ||
| + if (userContextId === undefined && aURI?.spec?.startsWith("view-source:") && this.selectedTab) { | ||
| + const selectedUserContextId = this.selectedTab.getAttribute("usercontextid"); | ||
| + if (selectedUserContextId) { |
Copilot
AI
Jan 27, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The truthiness check if (selectedUserContextId) will skip inheritance when the selected tab has usercontextid="0" (No Container), because the string "0" is falsy in JavaScript. This means view-source will not inherit "No Container" explicitly set on a tab, which may or may not be intentional. Consider using if (selectedUserContextId !== null) to handle the "0" case explicitly, or document why "No Container" should not be inherited.
| + if (selectedUserContextId) { | |
| + if (selectedUserContextId !== null) { |
| + // Fix for issue #12074: Inherit container from current tab for view-source | ||
| + // If no userContextId is provided and we're opening a view-source URL, | ||
| + // inherit the container from the currently selected tab | ||
| + if (userContextId === undefined && aURI?.spec?.startsWith("view-source:") && this.selectedTab) { | ||
| + const selectedUserContextId = this.selectedTab.getAttribute("usercontextid"); | ||
| + if (selectedUserContextId) { | ||
| + userContextId = parseInt(selectedUserContextId, 10); | ||
| + } | ||
| + } |
Copilot
AI
Jan 27, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change lacks test coverage. Consider adding a test to verify that view-source URLs inherit the container from the selected tab. The test should cover scenarios like: opening view-source in a tab with a specific container, opening view-source from a tab with no container, and ensuring the container is properly preserved in the source view tab.
|
I apreciate you taking on my issue. However, your solution seems to be to use AI. Which is fine as long as you check it yourself. But you put the burden of testing on maintainers. Such behaviour is closing down open source. You can see this rant of a YouTube video, for example: https://youtu.be/uZy1M_s-8zs |
You are right about it but when I said about the testing issue on me that did not mean I did not try when building the entire project it was taking a lot of time only then I asked it anyone else who has the firefox engine already downloaded can test or sometimes the test is automated via the gh actions only then I pushed it. I am still on process building it. I am very aware about your concern, will keep this is mind. Apologies for it. |
|
There is no rush. Take your time. Download, compile, test, fix etc. |
When 'View Page Source' is triggered from a container tab, the view-source tab now inherits the userContextId from the originating tab. This ensures that the source view maintains the same authentication/session context as the original page. The fix checks if a view-source URL is being opened without an explicit userContextId parameter and automatically inherits it from the currently selected tab before processing through Zen's workspace/container logic.
Description
Fixes #12074
This PR addresses the issue where "View Page Source" was opening in the default container (No Container) instead of preserving the container from the originating tab.
Changes Made
Modified
src/browser/components/tabbrowser/content/tabbrowser-js.patchto detect when a view-source URL is being opened without an explicituserContextIdand inherit it from the currently selected tab.The fix adds a check before
getContextIdIfNeeded()to ensure proper container propagation:Testing
Note: I was unable to build and test this locally due to setup constraints (30GB+ disk space and long compile time).
Suggested test steps:
Open a tab in any container (Personal, Work, etc.)
Navigate to a website
Press Ctrl+U / Cmd+U, or right-click → View Page Source
Verify the source tab shows the same container as the original tab
Additional testing:
Test with different container types
Verify normal tab creation is unaffected
Confirm tabs without containers still work correctly
Checklist
Would appreciate if someone with a local build could verify this works as expected. Happy to make any adjustments if needed!