Browse Source
Browser directory picking can be intercepted by embedded automation environments, which raises before the user can choose a folder. The project setup browse flow now treats that specific interception as a signal to use the existing server browse-directory fallback, while preserving normal browser picker behavior and cancellation semantics. Constraint: In-app browser automation may install Page.setInterceptFileChooserDialog and break showDirectoryPicker Constraint: Browser File System Access selection should still be preferred when it works Rejected: Always fall back after any browser picker error | permission and unsupported errors should remain visible instead of silently choosing a server path Confidence: high Scope-risk: narrow Directive: Do not broaden fallback errors without checking browser local-project semantics Tested: npm run test:run -- src/components/__tests__/ProjectSetupModal.test.tsx --testNamePattern "fall back to browse-directory API" Tested: npm run test:run -- src/components/__tests__/ProjectSetupModal.test.tsx --testNamePattern "Browse Button" Tested: npm run test:run -- src/components/__tests__/ProjectSetupModal.test.tsx --testNamePattern "fall back to browse-directory API|should call browse-directory API|should keep selected parent path|should handle cancelled browse dialog" Tested: npm run build Not-tested: npm run lint | existing Next 16 next lint script resolves to nonexistent /lint directory Not-tested: Full ProjectSetupModal test file | existing Provider tab assertions expect API key inputs hidden by current Popi modefeature/gateway
2 changed files with 72 additions and 4 deletions
Loading…
Reference in new issue