Conversation
WalkthroughAdded a new Chromium launch argument Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/next-wxt/wxt.config.ts`:
- Around line 16-19: The shared config currently forces '--disable-web-security'
in runner.chromiumArgs which is unsafe; change this to be opt-in by checking an
environment variable (e.g., WXT_DISABLE_WEB_SECURITY) before adding the flag to
chromiumArgs in wxt.config (reference runner.chromiumArgs and chromiumArgs
array), defaulting to not include the flag; also add a short inline comment
explaining the opt-in and update any local README or dev docs to mention how to
enable WXT_DISABLE_WEB_SECURITY for individual developers and why it should not
be enabled globally.
| chromiumArgs: [ | ||
| '--disable-web-security', // 禁用 Web 安全策略 | ||
| '--user-data-dir=./.wxt/chrome-data' // 设置用户数据目录 | ||
| ] |
There was a problem hiding this comment.
Unconditionally disabling web security for all developers is risky — consider making it opt-in.
Even though runner.chromiumArgs only affects wxt dev, committing --disable-web-security to the shared config means:
- Masked production bugs: CORS and same-origin violations that would surface in real browsers will be silently suppressed during development, leading to surprises at release time.
- Developer exposure: Any dev browsing untrusted sites in the same Chromium instance is vulnerable to cross-origin attacks.
- No stated rationale: The PR description doesn't explain which specific scenario requires disabling web security. If it's for a specific API/CORS workaround, that context should be documented.
Consider gating this behind an environment variable so individual developers can opt in when needed:
🛡️ Suggested opt-in approach
runner: {
- chromiumArgs: [
- '--disable-web-security', // 禁用 Web 安全策略
- '--user-data-dir=./.wxt/chrome-data' // 设置用户数据目录
- ]
+ chromiumArgs: [
+ // 需要禁用 Web 安全策略时，设置环境变量 DISABLE_WEB_SECURITY=true
+ ...(process.env.DISABLE_WEB_SECURITY === 'true' ? ['--disable-web-security'] : []),
+ '--user-data-dir=./.wxt/chrome-data' // 设置用户数据目录
+ ]
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| chromiumArgs: [ | |
| '--disable-web-security', // 禁用 Web 安全策略 | |
| '--user-data-dir=./.wxt/chrome-data' // 设置用户数据目录 | |
| ] | |
| chromiumArgs: [ | |
| // 需要禁用 Web 安全策略时，设置环境变量 DISABLE_WEB_SECURITY=true | |
| ...(process.env.DISABLE_WEB_SECURITY === 'true' ? ['--disable-web-security'] : []), | |
| '--user-data-dir=./.wxt/chrome-data' // 设置用户数据目录 | |
| ] |
🤖 Prompt for AI Agents
In `@packages/next-wxt/wxt.config.ts` around lines 16 - 19, The shared config
currently forces '--disable-web-security' in runner.chromiumArgs which is
unsafe; change this to be opt-in by checking an environment variable (e.g.,
WXT_DISABLE_WEB_SECURITY) before adding the flag to chromiumArgs in wxt.config
(reference runner.chromiumArgs and chromiumArgs array), defaulting to not
include the flag; also add a short inline comment explaining the opt-in and
update any local README or dev docs to mention how to enable
WXT_DISABLE_WEB_SECURITY for individual developers and why it should not be
enabled globally.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@packages/next-wxt/entrypoints/sidepanel/App.vue`:
- Around line 214-222: The operations and welcome slots currently contain
placeholder markup; replace the dead <button> placeholders in the template
`#operations` with real handlers or remove them: either wire the buttons to the
existing methods (e.g., add `@click` handlers that call exportConversation() or
customOperation()) or guard them behind a feature flag so they don't render in
production; and replace the raw <h1> in the `#welcome` slot with the imported
Welcome component (use <Welcome />) so the actual component is rendered instead
of static text; locate the slots named "operations" and "welcome" in App.vue and
update them accordingly.
- Line 8: The import list includes Welcome but the component isn't used; either
remove Welcome from the import statement that currently lists
TrSuggestionPillButton, TrDropdownMenu, Welcome, or actually use it in the
template (for example replace the plain <h1> inside the `#welcome` slot with the
<Welcome/> component) and update any component registrations if necessary;
modify the import/usage for Welcome accordingly so there are no unused imports.
| import TinyUser from '@opentiny/vue-user' | ||
| import { useCustomMarketMcpServers } from './composable/useCustomMarketMcpServers' | ||
| import { TrSuggestionPillButton, TrDropdownMenu } from '@opentiny/tiny-robot' | ||
| import { TrSuggestionPillButton, TrDropdownMenu, Welcome } from '@opentiny/tiny-robot' |
There was a problem hiding this comment.
Welcome is imported but never used.
The Welcome component is added to the import but is not referenced anywhere in the template or script. If the #welcome slot (line 220) was intended to use this component, it currently renders a plain <h1> instead.
Proposed fix: remove unused import
-import { TrSuggestionPillButton, TrDropdownMenu, Welcome } from '@opentiny/tiny-robot'
+import { TrSuggestionPillButton, TrDropdownMenu } from '@opentiny/tiny-robot'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import { TrSuggestionPillButton, TrDropdownMenu, Welcome } from '@opentiny/tiny-robot' | |
| import { TrSuggestionPillButton, TrDropdownMenu } from '@opentiny/tiny-robot' |
🤖 Prompt for AI Agents
In `@packages/next-wxt/entrypoints/sidepanel/App.vue` at line 8, The import list
includes Welcome but the component isn't used; either remove Welcome from the
import statement that currently lists TrSuggestionPillButton, TrDropdownMenu,
Welcome, or actually use it in the template (for example replace the plain <h1>
inside the `#welcome` slot with the <Welcome/> component) and update any component
registrations if necessary; modify the import/usage for Welcome accordingly so
there are no unused imports.
| <template #operations> | ||
| <!-- 自定义头部操作按钮 --> | ||
| <button>自定义操作</button> | ||
| <!-- 或者保留默认功能，添加额外按钮 --> | ||
| <button>导出对话</button> | ||
| </template> | ||
| <template #welcome> | ||
| <h1>欢迎使用</h1> | ||
| </template> |
There was a problem hiding this comment.
Placeholder slots with non-functional buttons — not ready for merge.
These slots look like scaffolding/example code rather than a production implementation:
- Lines 216 & 218: Both
<button>elements lack@clickhandlers, meaning they render but do nothing. The inline comments (lines 215, 217) read like developer notes ("自定义头部操作按钮", "或者保留默认功能，添加额外按钮"). - Line 221: The
#welcomeslot renders a bare<h1>instead of using the importedWelcomecomponent.
If these are intentional examples for a WIP branch, consider guarding them behind a feature flag or removing them until the functionality is implemented. Shipping dead buttons degrades the user experience.
🤖 Prompt for AI Agents
In `@packages/next-wxt/entrypoints/sidepanel/App.vue` around lines 214 - 222, The
operations and welcome slots currently contain placeholder markup; replace the
dead <button> placeholders in the template `#operations` with real handlers or
remove them: either wire the buttons to the existing methods (e.g., add `@click`
handlers that call exportConversation() or customOperation()) or guard them
behind a feature flag so they don't render in production; and replace the raw
<h1> in the `#welcome` slot with the imported Welcome component (use <Welcome />)
so the actual component is rendered instead of static text; locate the slots
named "operations" and "welcome" in App.vue and update them accordingly.
1 participant
Pull Request (OpenTiny NEXT-SDKs)
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit
New Features
Chores