▲

Firefox에 대한 Puppeteer 공식 지원 발표

 (hacks.mozilla.org)
6P by xguru 4달전 | favorite | 댓글 1개
  • Puppeteer 버전 23부터 Firefox를 정식으로 지원하게 되어, 이제 Chrome과 Firefox에서 자동화 및 엔드 투 엔드 테스팅을 쉽게 수행할 수 있음
    • const browser = await puppeteer.launch({browser: "firefox"});
  • Chrome과 마찬가지로 Puppeteer는 최신 안정 버전의 Firefox를 다운로드하고 실행 가능
  • Firefox 지원은 Firefox 전용 자동화 프로토콜이 아닌 현재 Gecko와 Chromium에 구현되어 있는 크로스 브라우저 프로토콜인 WebDriver BiDi를 기반으로 함
    • 크로스 브라우저 프로토콜을 사용하면 향후 더 많은 브라우저를 쉽게 지원할 수 있음

기술적 배경

  • 최근까지 브라우저 자동화를 원하는 사람들에게는 두 가지 주요 선택지가 있었음
    • W3C WebDriver API 사용
    • 브라우저별 전용 API 사용 (Chrome DevTools Protocol, Firefox Remote Debugging Protocol 등)
  • 두 선택지 모두 상당한 트레이드오프가 있음
    • 고전적 WebDriver API는 HTTP 기반이며, 브라우저에 명령을 보내고 응답을 기다리는 모델을 가짐
    • 이는 페이지를 로드하고 요소가 표시되는지 확인하는 등의 자동화 시나리오에는 잘 작동하지만, 브라우저에서 이벤트를 받거나 여러 명령을 동시에 실행하는 등의 고급 사용 사례에는 적합하지 않음
    • 브라우저별 API는 일반적으로 브라우저 내 개발자 도구의 복잡한 사용 사례를 지원하도록 설계되었기 때문에 WebDriver보다 훨씬 앞선 기능 세트를 제공함
  • 따라서 브라우저 자동화 클라이언트는 단일 프로토콜을 사용하여 여러 브라우저를 지원하고 제한된 기능 세트를 제공하거나, 더 풍부한 기능 세트를 제공하지만 각 지원 브라우저에 대해 별도로 기능을 구현해야 하는 선택을 해야 했음
  • 이는 우수한 크로스 브라우저 자동화를 생성하는 데 드는 비용과 복잡성을 높였음
  • LSP(Language Server Protocol)이 개발되기 전에 상황이 이와 유사했음
  • WebDriver BiDi는 브라우저별 프로토콜로 제한되었던 자동화 기능 세트를 표준화된 프로토콜로 가져와 모든 브라우저와 자동화 툴에서 사용할 수 있도록 함

Firefox의 실험적인 CDP(Chrome DevTools Protocol) 지원 제거

  • 초기의 크로스 브라우저 테스트 개선 작업의 일환으로, 테스팅 사용 사례를 지원하는 데 필요한 몇 가지 명령과 이벤트로 제한된 CDP의 부분 구현을 제공함
  • 그러나 이것이 크로스 브라우저 자동화의 발전 방향이 아니라는 것이 분명해지면서 이에 대한 노력이 중단되었음
  • 그 결과 유지 관리되지 않고 사이트 격리와 같은 현대적 Firefox 기능과 호환되지 않음
  • 따라서 2024년 말에 지원이 제거될 예정임

앞으로의 계획

  • 여전히 지원되지 않는 일부 API가 있음
    • CDP 전용 API
    • 추가적인 표준화 작업이 필요한 API
    • 표준은 있지만 아직 구현되지 않은 API
  • 사용자의 피드백을 통해 우선순위를 정할 예정
▲
xguru 4달전  [-]

Hacker News 의견

  • Puppeteer 팀이 Google을 떠나 Microsoft로 가서 Playwright를 계속 개발한 것이 Google에 큰 타격이었음

    • Google은 브라우저 자동화 도구가 AI 에이전트 전략에 얼마나 중요한지 깨닫지 못했음
    • Google은 Puppeteer를 포기하고 MS/Playwright에 의존하거나 Puppeteer를 위한 새로운 길을 찾아야 했음
    • WebDriver BiDi는 Chrome DevTools Protocol(CDP)의 장점을 표준 방식으로 발전시킴

  • WebDriver BiDi 프로토콜이 브라우저를 생성하는 프로토콜은 아니지만, 거의 90%는 그 역할을 할 수 있을 것 같음

    • Gecko는 Servo 이후로 많이 발전했고, 요즘 꽤 성능이 좋음
    • Chromium 기반 브라우저를 만드는 것이 Gecko 기반 브라우저를 만드는 것보다 훨씬 쉬움
    • API를 사용해 탐색, 요청 가로채기, 콘솔 읽기, JS 실행 등을 할 수 있음
    • 브라우저 크롬을 제거하고 맞춤형 브라우저를 만들 수 있으면 좋겠음

  • Playwright는 모든 최신 렌더링 엔진(Chromium, WebKit, Firefox)을 지원함

  • 접근성 트리에 대해 궁금함

    • Playwright에서 접근성 트리가 제거된 이유는 엔진별 내부 데이터 구조의 덤프였기 때문임
    • 접근성 트리는 페이지의 모든 의미 요소를 요약한 것으로, 스냅샷 테스트나 BDD 테스트에 훌륭함
    • 접근성 트리가 주요 브라우저 엔진에서 표준화되기를 바람
    • 웹 개발 관점에서 CSS와 DOM 같은 다른 레이어에서도 접근 가능하면 좋겠음
답변달기