OSSCA Chromium

기여 목록 / 8473167

Include file systems in Clear site data

DevToolsfixdevtools/devtools-frontendMerged

Chromium DevTools의 Clear site data에 File System 삭제 항목을 추가했습니다. 체크박스 선택 여부가 삭제 요청에 반영되도록 수정하고, 자동 테스트와 실제 Chromium에서 동작을 검증했습니다. 해당 변경은 코드 리뷰와 CQ 검증을 거쳐 병합되었습니다.

문제 설명

DevTools의 Application → Storage에서 사이트 데이터를 삭제해도 OPFS(Origin Private File System)에 저장한 파일이 남는 문제가 있었습니다.

선택한 스토리지 타입을 백엔드에 전달하는 기능은 이미 구현되어 있었지만, 프런트엔드의 삭제 대상 목록인 AllStorageTypes에 File_systems가 누락되어 있었습니다. 사용자가 File System 삭제 여부를 선택할 체크박스도 없었습니다.

해결 내용

  1. StorageView.ts의 AllStorageTypes에 Protocol.Storage.StorageType.File_systems를 추가했습니다.
  2. 기존 문자열과 설정 바인딩을 활용해 File System 체크박스를 추가했습니다.
  3. 선택된 타입을 수집하는 기존 로직을 활용해, 체크된 경우 삭제 요청에 file_systems가 포함되도록 했습니다.
  4. KnownContextValues.ts에 clear-storage-file-systems를 추가해 새 체크박스의 시각적 로깅 컨텍스트를 등록했습니다.
this.appendSettingCheckbox(
    leftColumn, i18nString(UIStrings.fileSystem),
    Protocol.Storage.StorageType.File_systems, 'file-systems-checkbox');

기존 코드가 선택된 스토리지 타입을 쉼표로 연결해 Storage.clearDataForStorageKey로 전달하므로, 요청 함수나 C++ 백엔드를 변경하지 않고 프런트엔드의 누락된 연결을 보완했습니다.

DevTools 저장소에 처음 기여하면서 AUTHORS에도 이름과 이메일을 추가했습니다.

테스트 방법

체크박스 선택 상태에 따른 단위 테스트

StorageView.test.ts에 ON/OFF 두 가지 테스트를 추가했습니다.

  • 체크 ON: 삭제 요청의 storageTypes에 file_systems 포함
  • 체크 OFF: 삭제 요청의 storageTypes에서 file_systems 제외

삭제 함수를 직접 호출하는 대신 체크박스와 삭제 버튼을 조작했습니다. invoke_clearDataForStorageKey를 Sinon stub으로 대체해 요청 횟수, storage key, 삭제 타입을 확인했습니다.

const storageTypes = request.storageTypes.split(',');
if (checked) {
  assert.include(storageTypes, Protocol.Storage.StorageType.File_systems);
} else {
  assert.notInclude(storageTypes, Protocol.Storage.StorageType.File_systems);
}

이 방식으로 타입 전달뿐 아니라 UI와 설정의 연결까지 검증했습니다. 로컬에서 기존 테스트를 포함한 StorageView 테스트 9개가 통과했습니다.

실제 Chromium에서 OPFS 삭제 검증

수정한 DevTools 리소스를 빌드하고 --custom-devtools-frontend 옵션으로 Chromium에 연결했습니다.

localhost 페이지에서 OPFS 파일을 생성한 뒤, 체크박스 상태에 따른 결과를 확인했습니다.

조건 Clear selected 실행 후 파일 조회 결과
File System 체크 OFF 파일 유지
File System 체크 ON NotFoundError 발생

파일 조회 시 OPFS 루트 핸들을 새로 얻었으며, 삭제한 파일을 다시 생성하지 않도록 getFileHandle()에 create: true를 사용하지 않았습니다.

제출 및 병합 검증

로컬 단위 테스트와 실제 브라우저 검증을 수행한 뒤, 최신 main으로 rebase하고 충돌을 해결했습니다. 이후 포맷 및 presubmit 검사가 경고·오류 없이 통과했습니다.

리뷰 과정에서 dtf_linux_rel의 Storage 관련 E2E 테스트가 실패했습니다. 삭제 버튼의 동작과 저장소 사용량 표시를 검증하는 테스트에서 다음 오류가 기록됐습니다.

Error: Fatal errors logged.
Unknown VE context: 'clear-storage-file-systems'

새 체크박스가 사용하는 시각적 로깅 컨텍스트가 알려진 컨텍스트 목록에 등록되지 않은 것이 원인이었습니다. 로그에서도 front_end/ui/visual_logging/KnownContextValues.ts에 해당 값을 추가하도록 안내했습니다. 이 목록에 clear-storage-file-systems를 추가하여 UI와 설정 연결뿐 아니라 로깅 컨텍스트 등록까지 보완했습니다.

로컬 단위 테스트와 수동 기능 검증만으로 발견하지 못한 로깅 등록 누락을 CQ의 E2E 테스트에서 확인한 사례였습니다. 이후 CQ dry run 통과와 최종 제출 완료를 확인했으며, 변경은 2026년 10월 7일 DevTools main에 병합되었습니다.

배운 점

화면 상태와 내부 설정을 구분한 디버깅

초기 자동 테스트에서는 체크박스를 해제해도 요청에 file_systems가 남았습니다. 내부 input의 checked 값은 false였지만 삭제에 사용되는 설정 값은 바뀌지 않은 상황이었습니다.

체크박스 컴포넌트와 설정 바인딩 코드를 추적해, 설정이 change 이벤트를 통해 갱신되는 구조임을 확인했습니다. 내부 input 대신 체크박스 컴포넌트를 클릭하도록 바꾸는 것만으로는 해결되지 않았습니다.

실제 브라우저와 테스트 환경을 비교한 뒤, 테스트의 StorageView를 renderElementIntoDOM(view)로 문서에 연결하고 종료 시 view.detach()로 정리하도록 수정했습니다. 이후 테스트가 통과했습니다.

이를 통해 화면 요소의 값뿐 아니라 이벤트 전달과 내부 설정까지 이어지는 흐름을 확인해야 한다는 점을 배웠습니다.

자동 테스트와 실제 동작 검증의 역할

자동 테스트는 UI의 선택 상태가 삭제 요청에 반영되는지를 확인하고, 실제 Chromium에서는 파일 삭제 결과를 확인했습니다. 두 검증을 함께 수행해 요청 구성과 실제 동작을 각각 검증할 수 있었습니다.

visual logging context

UI 항목을 추가할 때 시각적 로깅 컨텍스트 등록도 함께 고려해야 한다는 점을 배웠습니다.

참고 자료

목록으로