[extensions] Remove the expired force-install re-enable workaround

ExtensionService::CheckManagementPolicy()에 남아 있던 일회성 보정 코드를 제거했습니다. 이 코드는 정책으로 강제 설치된 확장이 예전 버전에서 잘못 꺼진 채 남은 프로필을 고치려고 2022년(M104)에 들어왔고, 작성자가 «M107에 지워도 안전하다»고 적어 둔 블록입니다. 테스트가 이 블록에 기대고 있어서, 실제 제품 경로를 타도록 테스트를 다시 썼습니다. 2파일 +16/−14. 2026-09-26에 머지됐습니다(fbf799a217dba).

문제 설명

issue url: https://crbug.com/40144051 (접근 제한)
원 CL 3665201이 두 군데를 고쳤습니다. 정상 경로는 ExternalProviderManager::OnExternalExtensionUpdateUrlFound()로, 정책 provider가 더 높은 우선순위 위치로 확장을 보고하면 비활성화 이유를 지우고 켭니다. CheckManagementPolicy()의 블록은 «이미 깨진 프로필» 용 보정이었습니다.
트리가 M155였던 시점에 48개 마일스톤이 지나, 영향받던 프로필은 모두 시작 시 이 보정을 한 번 이상 거쳤습니다.
그런데 ExtensionServiceTest.ExternalExtensionBecomesEnabledIfForceInstalled가 정책 pref만 바꾸고 이 블록에 기대고 있었습니다. 블록만 지우면 이 테스트가 깨집니다(첫 빌드에서 실패를 확인).

해결 내용

extension_service.cc의 CheckManagementPolicy()에서 12줄 블록과 주석을 지웠습니다.
테스트는 PS1에서 OnExternalExtensionUpdateUrlFound()를 직접 부르도록 고쳤는데, 리뷰어 rdevlin.cronin@가 «내부를 직접 부르면 재활성화가 저절로 일어나는지 믿을 수 없다»고 지적했습니다.
PS2에서는 정책 위치(kExternalPolicyDownload)에 두 번째 MockExternalProvider를 등록해 확장을 update-URL 항목으로 보고하게 하고, CheckForExternalUpdates()로 실제 provider → ExternalProviderManager → 재활성화 경로를 타게 했습니다.
이 과정에서 Mac/Windows에는 «비관리 기기에서 오프스토어 확장의 정책 강제 설치를 막는» 규칙이 있어 테스트 확장이 꺼진 채 남는 것을 발견했습니다. 같은 파일의 다른 정책 테스트들처럼 policy::ScopedDomainEnterpriseManagement로 관리 기기임을 표시했습니다.

+  // Mark as enterprise managed, so the off-store policy install isn't blocked.
+  policy::ScopedDomainEnterpriseManagement scoped_domain;
 ...
+  MockExternalProvider* policy_external_provider =
+      AddMockExternalProvider(ManifestLocation::kExternalPolicyDownload);
+  policy_external_provider->UpdateOrAddExtension(
+      std::make_unique<ExternalInstallInfoUpdateUrl>(...));
+  WaitForExternalExtensionInstalled(kGoodCrx);

발굴 과정

«Remove … in M» 만료 주석 스윕에서 나온 자체 발굴 항목입니다. 호출처를 따라가 정상 경로가 따로 있다는 것을 확인한 뒤 착수했고, OSSCA #443으로 등록했습니다.

테스트 방법

PS1(리눅스): 블록만 지우고 기존 테스트를 돌려 대상 테스트가 실패하는 것을 먼저 확인, 테스트 재작성 뒤 ExtensionServiceTest.* 191/191
PS2(Mac): unit_tests 빌드 2시간 48분. 재작성 테스트의 첫 실행이 실패해, 제품 코드에 임시 로그를 넣어 ChromeExtensionRegistrarDelegate::CanEnableExtension() → MustRemainDisabled(DISABLE_NOT_VERIFIED)가 원인임을 좁혔습니다. PS1의 직접 호출판도 Mac에서는 같은 이유로 실패한다는 것도 이때 알았습니다(PS1은 리눅스에서만 검증했었음).
수정 뒤 대상 테스트 통과, ExtensionServiceTest.* 193/193. provider 단계를 빼면 실패하는 것까지 확인해, 테스트가 실제 경로에 의존함을 검증했습니다.
presubmit 0 경고. rdevlin.cronin@(«LGTM»)와 andreaorru@의 +1을 받았고, 제출 요청 뒤 andreaorru@가 CQ를 돌려 한 번에 통과했습니다.

배운 점

한 플랫폼에서만 검증한 테스트는 다른 플랫폼의 정책 규칙에 걸려 깨질 수 있습니다. Mac/Windows 전용 분기(#if BUILDFLAG(IS_WIN) || BUILDFLAG(IS_MAC))가 있는 영역은 두 쪽 모두에서 돌려 봅니다.
테스트가 원인 모르게 실패하면 제품 코드에 임시 로그를 넣어 거부하는 지점을 좁히는 게 빠릅니다. 원인을 찾은 뒤 로그는 모두 되돌립니다.
테스트용 도우미를 쓸 때는 그 도우미를 처음 도입한 CL이 기존 테스트에 어떻게 적용했는지 확인하면 «이렇게 써도 되는가»의 근거가 됩니다(ScopedDomainEnterpriseManagement는 CL 5053386이 같은 방식으로 추가).