Firefox के लिए Puppeteer के आधिकारिक सपोर्ट की घोषणा

• Puppeteer वर्ज़न 23 से Firefox के लिए आधिकारिक सपोर्ट उपलब्ध है, जिससे अब Chrome और Firefox में automation और end-to-end testing आसानी से की जा सकती है
  • const browser = await puppeteer.launch({browser: "firefox"});
• Chrome की तरह, Puppeteer Firefox का नवीनतम stable version डाउनलोड करके चला सकता है
• Firefox सपोर्ट, Firefox-विशेष automation protocol पर नहीं बल्कि WebDriver BiDi पर आधारित है, जो एक cross-browser protocol है और फिलहाल Gecko और Chromium में implemented है
  • cross-browser protocol इस्तेमाल करने से भविष्य में और अधिक browsers को आसानी से support किया जा सकेगा

तकनीकी पृष्ठभूमि

• हाल तक, browser automation चाहने वालों के पास दो प्रमुख विकल्प थे
  • W3C WebDriver API का उपयोग
  • browser-विशेष dedicated API का उपयोग (Chrome DevTools Protocol, Firefox Remote Debugging Protocol आदि)
• दोनों विकल्पों में काफ़ी trade-offs हैं
  • पारंपरिक WebDriver API HTTP-आधारित है और browser को command भेजकर response का इंतज़ार करने वाले मॉडल पर काम करता है
  • यह page load करने और element दिखाई दे रहा है या नहीं, जैसी automation scenarios में अच्छी तरह काम करता है, लेकिन browser से events प्राप्त करने या कई commands को एक साथ चलाने जैसे advanced use cases के लिए उपयुक्त नहीं है
  • browser-विशेष APIs आमतौर पर browser के अंदर developer tools के जटिल use cases को support करने के लिए डिज़ाइन की जाती हैं, इसलिए वे WebDriver की तुलना में कहीं अधिक उन्नत feature set देती हैं
• इसलिए browser automation clients को या तो एक single protocol का उपयोग करके कई browsers को support करते हुए सीमित feature set देना पड़ता था, या फिर अधिक समृद्ध feature set देना पड़ता था लेकिन हर supported browser के लिए features अलग-अलग implement करने पड़ते थे
• इससे बेहतर cross-browser automation बनाने की लागत और जटिलता बढ़ जाती थी
• LSP(Language Server Protocol) के विकसित होने से पहले स्थिति कुछ ऐसी ही थी
• WebDriver BiDi, browser-विशेष protocols तक सीमित automation feature set को standardized protocol में लाता है, ताकि उसे सभी browsers और automation tools में इस्तेमाल किया जा सके

Firefox के experimental CDP(Chrome DevTools Protocol) सपोर्ट को हटाना

• शुरुआती cross-browser testing सुधार कार्य के हिस्से के रूप में, CDP का एक partial implementation दिया गया था, जो testing use cases के लिए आवश्यक कुछ commands और events तक सीमित था
• लेकिन जैसे-जैसे यह स्पष्ट हुआ कि cross-browser automation की प्रगति की दिशा यह नहीं है, इस पर काम रोक दिया गया
• नतीजतन, इसका maintenance नहीं हुआ और यह site isolation जैसे आधुनिक Firefox features के साथ compatible नहीं है
• इसलिए 2024 के अंत में इसका सपोर्ट हटा दिया जाएगा

आगे की योजना

• अभी भी कुछ APIs हैं जिन्हें support नहीं किया गया है
  • केवल CDP-विशेष APIs
  • वे APIs जिनके लिए अतिरिक्त standardization work की आवश्यकता है
  • वे APIs जिनके standards मौजूद हैं, लेकिन अभी implement नहीं हुए हैं
• users के feedback के आधार पर प्राथमिकताएँ तय की जाएँगी

[xguru]

Hacker News की राय

• Puppeteer टीम का Google छोड़कर Microsoft जाना और वहाँ Playwright का विकास जारी रखना, Google के लिए बड़ा झटका था

  • Google यह समझ नहीं पाया कि browser automation tools उसकी AI agent strategy के लिए कितने महत्वपूर्ण हैं
  • Google को या तो Puppeteer छोड़कर MS/Playwright पर निर्भर होना था, या Puppeteer के लिए नया रास्ता खोजना था
  • WebDriver BiDi, Chrome DevTools Protocol(CDP) के फ़ायदों को एक standard तरीके से आगे बढ़ाता है

• WebDriver BiDi protocol browser बनाने वाला protocol तो नहीं है, लेकिन लगता है कि यह लगभग 90% तक वह भूमिका निभा सकता है

  • Gecko, Servo के बाद से काफ़ी आगे बढ़ा है, और आजकल इसकी performance भी काफ़ी अच्छी है
  • Chromium-आधारित browser बनाना, Gecko-आधारित browser बनाने की तुलना में कहीं ज़्यादा आसान है
  • API का इस्तेमाल करके navigation, request interception, console पढ़ना, JS चलाना आदि किया जा सकता है
  • अगर browser chrome हटाकर एक custom browser बनाया जा सके, तो अच्छा होगा

• Playwright सभी modern rendering engines (Chromium, WebKit, Firefox) को support करता है

• accessibility tree को लेकर जिज्ञासा है

  • Playwright में accessibility tree हटाए जाने की वजह यह थी कि वह engine-विशिष्ट internal data structures का dump था
  • accessibility tree, page के सभी semantic elements का सार होता है, इसलिए snapshot testing या BDD testing के लिए यह बेहतरीन है
  • उम्मीद है कि accessibility tree प्रमुख browser engines में standardize हो
  • web development के नज़रिए से, CSS और DOM जैसी दूसरी layers में भी इसकी पहुँच हो तो अच्छा रहेगा