fix(runtime-dom): preserve option modifier event names#8338
Conversation
|
👀 |
Size ReportBundles
Usages
|
CodSpeed Performance ReportMerging #8338 will not alter performanceComparing Summary
|
7fd6b0c to
59d7d1f
Compare
❌ Deploy Preview for vue-next-template-explorer failed.
|
@vue/compiler-core
@vue/compiler-dom
@vue/compiler-sfc
@vue/compiler-ssr
@vue/reactivity
@vue/runtime-core
@vue/runtime-dom
@vue/server-renderer
@vue/shared
vue
@vue/compat
commit: |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
💤 Files with no reviewable changes (2)
📝 WalkthroughWalkthroughEvent prop parsing now strips modifier suffixes in a loop while preserving ChangesCustom element modifier events
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/runtime-dom/__tests__/patchEvents.spec.ts`:
- Line 228: The custom element registration in patchEvents.spec.ts can collide
with prior test runs because hello-world may already be defined. Update the
TestCustomElement registration near customElements.define to guard against
re-definition, e.g. only define it when the tag is not already present or use a
setup helper that safely registers once. Keep the change localized to the test
setup around TestCustomElement so the suite remains order-independent.
- Around line 230-232: The custom element creation in patchEvents.spec.ts is
using the wrong creation form for an autonomous custom element. Update the test
to call document.createElement('hello-world') directly and remove the
unnecessary second-argument options object with is, since that form is only for
customized built-ins. Keep the change localized to the customElement setup in
the test.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 22cee3b8-f5a0-4f68-abca-e51f82bab4b5
📒 Files selected for processing (2)
packages/runtime-dom/__tests__/patchEvents.spec.tspackages/runtime-dom/src/modules/events.ts
|
/ecosystem-ci run |
|
📝 Ran ecosystem CI: Open
|
fixed #8334
Summary by CodeRabbit
once,passive, andcapturecombinations behave consistently.on:Once/on:Passive/on:Capture) more reliably, including for custom elements.oncebehavior).oncebehavior, custom elements, and modifier name casing to prevent regressions.