আমরা ঘোষণা করতে পেরে আনন্দিত যে, সংস্করণ 23 হিসাবে, পুতুল ব্রাউজার অটোমেশন লাইব্রেরিতে এখন ফায়ারফক্সের জন্য প্রথম-শ্রেণীর সমর্থন রয়েছে। এর মানে হল যে এখন অটোমেশন লেখা এবং পাপেটিয়ার ব্যবহার করে এন্ড-টু-এন্ড টেস্টিং করা এবং ক্রোম এবং ফায়ারফক্স উভয়ের বিরুদ্ধে চালানো সহজ।
ফায়ারফক্সের সাথে পাপেটিয়ার কীভাবে ব্যবহার করবেন
শুরু করতে, কেবলমাত্র পণ্যটিকে “এ সেট করুনfirefox
“পাপেটিয়ার শুরু করার সময়:
import puppeteer from "puppeteer";
const browser = await puppeteer.launch({
browser: "firefox"
});
const page = await browser.newPage();
// ...
await browser.close();
ক্রোমের মতোই, Puppeteer Firefox-এর সর্বশেষ স্থিতিশীল সংস্করণ ডাউনলোড এবং লঞ্চ করতে সক্ষম, তাই যেকোনও ব্রাউজারের বিরুদ্ধে চললে একই বিকাশকারী অভিজ্ঞতা প্রদান করা উচিত যা Puppeteer ব্যবহারকারীরা আশা করেছিলেন।
যদিও Puppeteer দ্বারা অফার করা বৈশিষ্ট্যগুলি আশ্চর্যজনক হবে না, একাধিক ব্রাউজারে সমর্থন আনা একটি উল্লেখযোগ্য উদ্যোগ। ফায়ারফক্স সমর্থন ফায়ারফক্স-নির্দিষ্ট অটোমেশন প্রোটোকলের উপর ভিত্তি করে নয়, কিন্তু WebDriver BiDi-তে, একটি ক্রস ব্রাউজার প্রোটোকল যা W3C-তে মানসম্মতকরণের মধ্য দিয়ে চলছে এবং বর্তমানে Gecko এবং Chromium উভয় ক্ষেত্রেই এটির প্রয়োগ রয়েছে। একটি ক্রস-ব্রাউজার প্রোটোকলের এই ব্যবহারটি অনেকগুলি বিভিন্ন ব্রাউজারকে এগিয়ে যেতে সমর্থন করা আরও সহজ করে তুলবে৷
পরে এই পোস্টে আমরা WebDriver BiDi-এর পিছনে আরও কিছু প্রযুক্তিগত পটভূমিতে ডুব দেব। কিন্তু প্রথমেই আমরা বলতে চাই যে আজকের ঘোষণাটি কীভাবে উৎপাদনশীল সহযোগিতা ওয়েবে শিল্পের অবস্থাকে এগিয়ে নিতে পারে তার একটি দুর্দান্ত প্রদর্শনী। একটি নতুন ব্রাউজার অটোমেশন প্রোটোকল তৈরি করা অনেক কাজ, এবং Puppeteer টিম এবং W3C ব্রাউজার টেস্টিং এবং টুলস ওয়ার্কিং গ্রুপের অন্যান্য সদস্যদের, আমাদের এই অবস্থানে নিয়ে যাওয়ার জন্য তাদের সমস্ত প্রচেষ্টার জন্য মহান ধন্যবাদ।
আপনি Puppeteer দলের চেক আউট করতে পারেন পোস্ট WebDriver BiDi উৎপাদন প্রস্তুত করার বিষয়ে।
মূল বৈশিষ্ট্য
দীর্ঘ সময়ের Puppeteer ব্যবহারকারীদের জন্য, উপলব্ধ বৈশিষ্ট্যগুলি পরিচিত। তবে অন্যান্য অটোমেশন এবং টেস্টিং ইকোসিস্টেমের লোকেদের জন্য – বিশেষ করে যারা সম্প্রতি পর্যন্ত সম্পূর্ণরূপে HTTP-ভিত্তিক ওয়েবড্রাইভারের উপর নির্ভর করেছিল – এই বিভাগটি কিছু নতুন কার্যকারিতার রূপরেখা দেয় যা WebDriver BiDi একটি ক্রস-ব্রাউজার পদ্ধতিতে বাস্তবায়ন করা সম্ভব করে।
লগ বার্তা ক্যাপচারিং
ওয়েব অ্যাপ্লিকেশানগুলি পরীক্ষা করার সময় একটি সাধারণ প্রয়োজন হল কনসোলে রিপোর্ট করা কোনও অপ্রত্যাশিত ত্রুটি নেই তা নিশ্চিত করা৷ এটি এমন একটি ক্ষেত্রে যেখানে একটি ইভেন্ট-ভিত্তিক প্রোটোকল উজ্জ্বল হয়, যেহেতু এটি নতুন লগ বার্তাগুলির জন্য ব্রাউজারকে পোল করার প্রয়োজন এড়ায়।
import puppeteer from "puppeteer";
const browser = await puppeteer.launch({
browser: "firefox"
});
const page = await browser.newPage();
page.on('console', msg => {
console.log(`(console) ${msg.type()}: ${msg.text()}`);
});
await page.evaluate(() => console.debug('Some Info'));
await browser.close();
আউটপুট:
(console) debug: Some Info
ডিভাইস এমুলেশন
প্রায়শই একটি প্রতিক্রিয়াশীল লেআউট পরীক্ষা করার সময় লেআউটটি একাধিক স্ক্রীনের মাত্রা এবং ডিভাইস পিক্সেল অনুপাতগুলিতে ভালভাবে কাজ করে তা নিশ্চিত করতে সক্ষম হওয়া কার্যকর। এটি একটি বাস্তব মোবাইল ব্রাউজার ব্যবহার করে করা যেতে পারে, হয় একটি ডিভাইসে বা একটি এমুলেটরে। তবে সরলতার জন্য এটি একটি মোবাইল ডিভাইসের ভিউপোর্ট নকল করার জন্য একটি ডেস্কটপে সেট আপ করে পরীক্ষা করা কার্যকর হতে পারে। নিচের উদাহরণে একটি Pixel 5 ফোনের ভিউপোর্ট সাইজ এবং ডিভাইস পিক্সেল অনুপাত অনুকরণ করতে Firefox-এর সাথে একটি পৃষ্ঠা লোড করা দেখায়।
import puppeteer from "puppeteer";
const device = puppeteer.KnownDevices("Pixel 5");
const browser = await puppeteer.launch({
browser: "firefox"
});
const page = await browser.newPage();
await page.emulate(device);
const viewport = page.viewport();
console.log(
`(emulate) Pixel 5: ${viewport.width}x${viewport.height}` +
` (dpr=${viewport.deviceScaleFactor}, mobile=${viewport.isMobile})`
);
await page.goto("https://www.mozilla.org");
await browser.close();
আউটপুট:
(emulate) Pixel 5: 393x851 (dpr=3, mobile=true)
নেটওয়ার্ক ইন্টারসেপশন
পরীক্ষার জন্য একটি সাধারণ প্রয়োজন হল নেটওয়ার্ক অনুরোধগুলিকে ট্র্যাক করতে এবং বাধা দিতে সক্ষম হওয়া। পরীক্ষার সময় তৃতীয় পক্ষের পরিষেবাগুলির অনুরোধ এড়াতে এবং মক রেসপন্স ডেটা প্রদানের জন্য ইন্টারসেপশন বিশেষত কার্যকর। এটি HTTP প্রমাণীকরণ ডায়ালগগুলি পরিচালনা করতে এবং অনুরোধ এবং প্রতিক্রিয়ার অংশগুলিকে ওভাররাইড করতেও ব্যবহার করা যেতে পারে, উদাহরণস্বরূপ শিরোনাম যোগ করা বা সরানো। নীচের উদাহরণে আমরা একটি পৃষ্ঠায় ওয়েব ফন্টগুলির সমস্ত অনুরোধগুলিকে ব্লক করতে নেটওয়ার্ক অনুরোধ ইন্টারসেপশন ব্যবহার করি, যা এই ফন্টগুলি লোড করতে ব্যর্থ হওয়া সাইট বিন্যাসকে ভঙ্গ না করে তা নিশ্চিত করতে কার্যকর হতে পারে৷
import puppeteer from "puppeteer";
const browser = await puppeteer.launch({
browser: 'firefox'
});
const page = await browser.newPage();
await page.setRequestInterception(true);
page.on("request", request => {
if (request.url().includes(".woff2")) {
// Block requests to custom user fonts.
console.log(`(intercept) Request aborted: ${request.url()}`);
request.abort();
} else {
request.continue();
}
});
const response = await page.goto("https://support.mozilla.org");
console.log(
`(navigate) status=${response.status()} url=${response.url()}`
);
await browser.close();
আউটপুট:
(intercept) Request aborted: https://assets-prod.sumo.prod.webservices.mozgcp.net/static/Inter-Bold.3717db0be15085ac.woff2 (navigate) status=200 url=https://support.mozilla.org/en-US/
প্রিলোড স্ক্রিপ্ট
প্রায়শই অটোমেশন টুলিং কাস্টম কার্যকারিতা প্রদান করতে চায় যা জাভাস্ক্রিপ্টে প্রয়োগ করা যেতে পারে। যদিও WebDriver সবসময় স্ক্রিপ্ট ইনজেকশন করার অনুমতি দেয়, এটি নিশ্চিত করা সম্ভব ছিল না যে পৃষ্ঠাটি লোড হওয়া শুরু করার আগে একটি ইনজেকশন স্ক্রিপ্ট সর্বদা চালানো হয়েছে, যার ফলে পৃষ্ঠার স্ক্রিপ্ট এবং ইনজেকশন স্ক্রিপ্টের মধ্যে রেস এড়ানো অসম্ভব।
WebDriver BiDi “প্রিলোড” স্ক্রিপ্ট সরবরাহ করে যা একটি পৃষ্ঠা লোড হওয়ার আগে চালানো যেতে পারে। এটি স্ক্রিপ্ট থেকে কাস্টম ইভেন্টগুলি নির্গত করার একটি উপায়ও সরবরাহ করে। এটি ব্যবহার করা যেতে পারে, উদাহরণস্বরূপ, প্রত্যাশিত উপাদানগুলির জন্য পোলিং এড়াতে, তবে পরিবর্তে একটি মিউটেশন পর্যবেক্ষক ব্যবহার করা যেতে পারে যা উপাদানটি উপলব্ধ হওয়ার সাথে সাথে ফায়ার করে। নীচের উদাহরণে আমরা অপেক্ষা করি
import puppeteer from "puppeteer";
const browser = await puppeteer.launch({
browser: 'firefox',
});
const page = await browser.newPage();
const gotMessage = new Promise(resolve =>
page.exposeFunction("sendMessage", async message => {
console.log(`(script) Message from pre-load script: ${message}`);
resolve();
})
);
await page.evaluateOnNewDocument(() => {
const observer = new MutationObserver(mutationList => {
for (const mutation of mutationList) {
if (mutation.type === "childList") {
for (const node of mutation.addedNodes) {
if (node.tagName === "TITLE") {
sendMessage(node.textContent);
}
}
}
};
});
observer.observe(document.documentElement, {
subtree: true,
childList: true,
});
});
await page.goto("https://support.mozilla.org");
await gotMessage;
await browser.close();
আউটপুট:
(script) Message from pre-load script: Mozilla Support
প্রযুক্তিগত পটভূমি
সম্প্রতি পর্যন্ত যারা ব্রাউজার স্বয়ংক্রিয় করতে ইচ্ছুক তাদের দুটি প্রধান পছন্দ ছিল:
দুর্ভাগ্যবশত সেই দুটি বিকল্পই উল্লেখযোগ্য ট্রেডঅফের সাথে আসে। “ক্লাসিক” WebDriver API হল HTTP-ভিত্তিক, এবং এর মডেলটিতে ব্রাউজারে একটি কমান্ড পাঠানো এবং প্রতিক্রিয়ার জন্য অপেক্ষা করা অটোমেশন জড়িত। এটি অটোমেশন পরিস্থিতিগুলির জন্য ভাল কাজ করে যেখানে আপনি একটি পৃষ্ঠা লোড করেন এবং তারপর যাচাই করেন, উদাহরণস্বরূপ, কিছু উপাদান প্রদর্শিত হয়, তবে ইভেন্টগুলি পেতে অক্ষমতা — যেমন কনসোল লগ — ব্রাউজার থেকে ফিরে আসা, বা একসাথে একাধিক কমান্ড চালানো, এপিআইকে একটি করে তোলে আরো উন্নত ব্যবহারের ক্ষেত্রে দরিদ্র ফিট.
বিপরীতে, ব্রাউজার-নির্দিষ্ট এপিআইগুলি সাধারণত ইন-ব্রাউজার ডেভটুলগুলির জটিল ব্যবহারের ক্ষেত্রে সমর্থন করার জন্য ডিজাইন করা হয়েছে। এটি তাদের একটি বৈশিষ্ট্য দিয়েছে যা ওয়েবড্রাইভার ব্যবহার করে কী করা সম্ভব তার অনেক আগেই সেট করা হয়েছে, কারণ তাদের ব্যবহারের ক্ষেত্রে সমর্থন করতে হবে যেমন রেকর্ডিং কনসোল লগ, বা নেটওয়ার্ক অনুরোধগুলি।
অতএব, ব্রাউজার অটোমেশন ক্লায়েন্টরা একটি একক প্রোটোকল ব্যবহার করে অনেকগুলি ব্রাউজারকে সমর্থন করা এবং একটি সীমিত বৈশিষ্ট্য সেট প্রদান করা, অথবা একটি সমৃদ্ধ বৈশিষ্ট্য সেট প্রদান করা কিন্তু প্রতিটি সমর্থিত ব্রাউজারের জন্য আলাদাভাবে কার্যকারিতা প্রদানের জন্য একাধিক প্রোটোকল প্রয়োগ করতে বাধ্য করা হয়েছে। এটি স্পষ্টতই দুর্দান্ত ক্রস-ব্রাউজার অটোমেশন তৈরির খরচ এবং জটিলতা বাড়িয়েছে, যা একটি ভাল পরিস্থিতি নয়, বিশেষ করে যখন বিকাশকারীরা সাধারণত উদ্ধৃত ক্রস-ব্রাউজার টেস্টিং ওয়েবের জন্য বিকাশের প্রধান ব্যথা পয়েন্ট হিসাবে।
দীর্ঘ সময় ডেভেলপাররা এখানে সাদৃশ্য লক্ষ্য করতে পারে উন্নয়নের আগে সম্পাদকদের সাথে পরিস্থিতি ভাষা সার্ভার প্রোটোকল (এলএসপি)। সেই সময়ে প্রতিটি টেক্সট এডিটর বা আইডিইকে প্রতিটি আলাদা প্রোগ্রামিং ভাষার জন্য বেসপোক সমর্থন বাস্তবায়ন করতে হতো। এটি ডেভেলপারদের ব্যবহার করা সমস্ত সরঞ্জামগুলিতে একটি নতুন ভাষার জন্য সমর্থন পাওয়া কঠিন করে তুলেছে। এলএসপির আবির্ভাব একটি সাধারণ প্রোটোকল প্রদান করে যা সম্পাদক এবং প্রোগ্রামিং ভাষার যেকোনো সমন্বয় দ্বারা সমর্থিত হতে পারে। টাইপস্ক্রিপ্টের মতো একটি নতুন প্রোগ্রামিং ল্যাঙ্গুয়েজ সব এডিটর জুড়ে সমর্থিত হওয়ার জন্য একে একে একে সমর্থন যোগ করার প্রয়োজন নেই; এটি শুধুমাত্র একটি LSP সার্ভার প্রদান করতে হবে এবং এটি স্বয়ংক্রিয়ভাবে যেকোনো LSP-সমর্থক সম্পাদক জুড়ে সমর্থিত হবে। এই সাধারণ প্রোটোকলের আবির্ভাব এমন জিনিসগুলিকেও সক্ষম করেছে যা আগে কল্পনা করা কঠিন ছিল। যেমন Tailwind-এর মতো নির্দিষ্ট লাইব্রেরিগুলি তাদের নিজস্ব এলএসপি বাস্তবায়ন বেস্পোক এডিটর কার্যকারিতা সক্ষম করতে।
তাই ক্রস-ব্রাউজার অটোমেশন উন্নত করতে আমরা একটি অনুরূপ পদ্ধতি গ্রহণ করেছি: উন্নয়নশীল WebDriver BiDiযা আগে ব্রাউজার-নির্দিষ্ট প্রোটোকলের মধ্যে সীমাবদ্ধ অটোমেশন ফিচারসেটটিকে একটি প্রমিত প্রোটোকলে নিয়ে আসে যা যেকোনো ব্রাউজার দ্বারা প্রয়োগ করা যেতে পারে এবং যেকোনো প্রোগ্রামিং ভাষায় যেকোনো অটোমেশন টুলিং দ্বারা ব্যবহার করা যেতে পারে।
Mozilla-তে আমরা প্রটোকলের প্রমিতকরণের এই কৌশলটি দেখতে পাই যাতে প্রবেশের বাধা দূর করা যায়, আন্তঃপরিচালনযোগ্য বাস্তবায়নের একটি বৈচিত্র্যময় ইকোসিস্টেমকে বিকাশ লাভ করতে দেয়, এবং ব্যবহারকারীদের আমাদের ম্যানিফেস্টোর মূল অংশ হিসেবে তাদের চাহিদার জন্য সবচেয়ে উপযুক্ত বেছে নিতে সক্ষম করে। ওয়েব দৃষ্টি.
WebDriver BiDi এর ডিজাইন এবং এটি কীভাবে ক্লাসিক ওয়েবড্রাইভারের সাথে সম্পর্কিত সে সম্পর্কে আরও বিশদ বিবরণের জন্য, অনুগ্রহ করে আমাদের দেখুন আগে পোস্ট.
ফায়ারফক্সে পরীক্ষামূলক CDP সমর্থন সরানো হচ্ছে
ক্রস-ব্রাউজার পরীক্ষার উন্নতির জন্য আমাদের প্রাথমিক কাজের অংশ হিসাবে, আমরা CDP-এর একটি আংশিক বাস্তবায়ন প্রেরণ করেছি, যা পরীক্ষার ব্যবহারের ক্ষেত্রে সমর্থন করার জন্য প্রয়োজনীয় কয়েকটি কমান্ড এবং ইভেন্টের মধ্যে সীমাবদ্ধ। এটি পূর্বে Puppeteer-এ ফায়ারফক্সের জন্য পরীক্ষামূলক সমর্থনের ভিত্তি ছিল। যাইহোক, একবার এটি স্পষ্ট হয়ে গেল যে ক্রস-ব্রাউজার অটোমেশনের জন্য এটি এগিয়ে যাওয়ার উপায় নয়, এটির প্রচেষ্টা বন্ধ হয়ে গেছে। ফলস্বরূপ এটি অপরিবর্তিত এবং আধুনিক ফায়ারফক্স বৈশিষ্ট্য যেমন সাইট আইসোলেশনের সাথে কাজ করে না। তাই সমর্থন করা হয় অপসারণ করার জন্য নির্ধারিত 2024 এর শেষে।
আপনি যদি বর্তমানে ফায়ারফক্সের সাথে CDP ব্যবহার করছেন, এবং WebDriver BiDi-তে কীভাবে রূপান্তর করতে হয় তা জানেন না, অনুগ্রহ করে যেকোনো একটি ব্যবহার করে যোগাযোগ করুন এই পোস্টের নীচে তালিকাভুক্ত চ্যানেলগুলিএবং আমরা আপনার প্রয়োজনীয়তা নিয়ে আলোচনা করব।
পরবর্তী কি?
যদিও ফায়ারফক্স এখন আনুষ্ঠানিকভাবে Puppeteer-এ সমর্থিত, এবং অনেক অটোমেশন এবং টেস্টিং পরিস্থিতি কভার করার জন্য যথেষ্ট কার্যকারিতা রয়েছে, তবুও কিছু API আছে যা অসমর্থিত রয়ে গেছে। এগুলি বিস্তৃতভাবে তিনটি বিভাগে পড়ে (এর সাথে পরামর্শ করুন পুতুল ডকুমেন্টেশন একটি সম্পূর্ণ তালিকার জন্য):
- উচ্চমাত্রার CDP-নির্দিষ্ট API, বিশেষ করে যারা CDPS অধিবেশন মডিউল এগুলি সরাসরি সমর্থিত হওয়ার সম্ভাবনা নেই, তবে নির্দিষ্ট ব্যবহারের ক্ষেত্রে যা বর্তমানে এই APIগুলির প্রয়োজন সেগুলি মানককরণের প্রার্থী হতে পারে।
- এপিআইগুলি যার জন্য আরও মানদণ্ডের প্রয়োজন হয়। যেমন page.accessibility.snapshot Chromium অ্যাক্সেসিবিলিটি ট্রির একটি ডাম্প ফেরত দেয়। যাইহোক, যেহেতু বর্তমানে সেই গাছটি কেমন হওয়া উচিত তার কোন প্রমিত বিবরণ নেই, ক্রস-ব্রাউজার পদ্ধতিতে কাজ করা কঠিন। এমন কিছু ক্ষেত্রেও রয়েছে যা অনেক বেশি সোজা, কারণ তাদের শুধুমাত্র WebDriver BiDi স্পেকের উপর কাজ করতে হবে; উদাহরণস্বরূপ page.set ভূ-অবস্থান.
- যে APIগুলির একটি মান আছে কিন্তু এখনও প্রয়োগ করা হয়নি, উদাহরণস্বরূপ কমান্ডের জন্য প্রয়োজনীয় কর্মীদের মধ্যে স্ক্রিপ্ট চালানোর ক্ষমতা WebWorker.evaluate.
আমরা আশা করি সামনের দিকে এই শূন্যস্থানগুলো পূরণ করব। অগ্রাধিকার দিতে সাহায্য করার জন্য, আমরা আপনার প্রতিক্রিয়া জানতে আগ্রহী: অনুগ্রহ করে Firefox-এ আপনার Puppeteer পরীক্ষা চালানোর চেষ্টা করুন! আপনি যদি একটি বাগ বা অনুপস্থিত বৈশিষ্ট্যের কারণে Firefox-এ সেগুলি পেতে অক্ষম হন, তাহলে অনুগ্রহ করে নীচের একটি পদ্ধতি ব্যবহার করে আমাদের জানান যাতে আমরা আমাদের ভবিষ্যতের মান এবং বাস্তবায়ন কাজের পরিকল্পনা করার সময় এটিকে বিবেচনায় নিতে পারি:
সফ্টওয়্যার ইঞ্জিনিয়ার একটি সুস্থ ওপেন ওয়েব বজায় রাখার উপর দৃষ্টি নিবদ্ধ করেন। ওয়েব-প্ল্যাটফর্ম-পরীক্ষার মূল দলের সদস্য।