Playwright が昨年１年間で大幅パワーアップしていたので、使い方を確認したときの記録のまとめです。 ブラウザを自動操作できるということは、簡単なスクレイピングやブラウザ側のテスト自動化が簡単にできるようになります。 特に、Python での解説がまだまだ少なかったので、自分の学習を含めてまとめました。 今回は入門編ということで全体像をつかみつつ使用方法の流れを確認していただければありがたいです。 Selenium や Puppeteer を使っている方も、一度試す価値ありと思っています。 選定した理由 ブラウザのテストを Python で自動化したかったんです。 私なりの要件がありまして、非常にわがままな要件でしたが余裕ですべてクリアしました。 Python で書けること。社内で Python を使える方が多いので。pytest と連携してくれるとなおうれしい。 Docker コン

const pw = require('playwright'); // iPhone11のデバイス情報を取得 const iPhone11 = pw.devices['iPhone 11 Pro']; (async () => { const browser = await pw.webkit.launch(); const context = await browser.newContext({ viewport: iPhone11.viewport, userAgent: iPhone11.userAgent, geolocation: { longitude: 12.492507, latitude: 41.889938 }, permissions: { 'https://www.google.com': ['geolocation'] } }); const page = aw

iOS13.4やSafari13.1と一緒に新しいITPがリリースされました。主な変更点は二つ。 * 全ての3rd party cookieをブロック * Local Storage等、クッキー以外のストレージを最後のインタラクションから7日後に削除 インタラクションとは、クリック・タップ・入力のことで、ドメイン毎に監視され、7日以内にインタラクションがないドメインのLocal Storageは削除されます。 その他に、JavaScriptからdocument.referrerで取得する全てのクロスサイトリファラーのダウングレード（"https://store.example/baby/strollers/deluxe-stroller-navy-blue.html"の場合、"https://store.example/"しか取得できなくなる）、および5秒以内の自動ページ遷移の検知も追加さ

「〜がChromiumベースに！」なことが起こるたびに「Chromium/BlinkはWebKitを源流とするエンジンでしかじか」みたいな話が出てきて、「実質WebKitだから同じだね」という反応が出てくるのが恒例行事っぽくなってるけど、結構モニョモニョする。 先祖が同じなら子孫も同じ、ってそんな単純な話じゃない。 fork前、BlinkがChromium WebKitというかWebKit Chromium portと呼ばれていた頃でさえ、Chromium portとApple portの2つが同じエンジンと呼べる箇所って、layoutとかdomとかstyleとかブラウザエンジンのコア部分だけで、他はV8とJSCとか、SkiaとCore Graphicsとか、そもそもプロセス分けてる方法も違うし、呉越同舟というか寄り合い所帯感だった。composition周りだってApple portはC

朝起きたらSlackに新しいメッセージが届いていました。 （と書いて、もう１週間経っていますが） 次期ITPで実装されると思われる機能です。現時点ですでに３種類の変更が見えてきているので、一旦まとめておきたいと思います。前回はITP3としてリリースされると思っていたものが2.1,2.2,2.3に分割されてリリースされたので、バージョン番号の予測だけやめておきます。時期としては早くても3月（Safari 13.1）でしょうかね。 3rd party cookieの規制強化まずは3rd party cookieの規制強化です。Safariの今までの3rd party cookieの制限を（色々省略して）まとめると ・バージョン1.0（2003年）から持っていないcookieの読み書きをデフォルトでブロック ・ITP1.0からはさらにインタラクション（click, 入力）の記録がなく、そしてトラ

先月ITP2.3が発表されましたね。 ITPの短い歴史では初めての事後発表になってしまい、リリースまでに対応できないサービスが多かったと思いますが、アドエビスは３月末から準備を進めていました。 3月20日に届いた、Slackに仕込んだ自動ITP仕様変更検知から始まりました。 7月に、他のブログ記事でも紹介されたように、 ITPの仕様変更はwebkitのコミット履歴やbugzillaを調査すればわかるのですが、いち早く変更を検知するために、ITP実装の心臓部であるResourceLoadStatisticsMemoryStore.cppというファイルのコミット履歴RSSをSlackに登録しています。なお、ITP2.1のdocument.cookieの制限ように、トラッカー(prevalent resource)判定に関係ない機能は別ファイルに実装されていてこの仕組みでは検知できないので注意が

ITPの仕様 次々と新しいバージョンがリリースされるITP。微妙にアップデートされ、仕様がわかりにくくなっているので現時点で最新のものを解説する。 ITPの目的と概要 われわれウェブサイト運用者は cookieやローカルストレージなどを使ってブラウザにドメインのデータを保持し、 それらのデータを必要に応じてツール間で連携する ことによって行動計測やコンテンツの出し分けなどのマーケティング活動を行っている。ITPはウェブサイト訪問者のプライバシー保持のためにそれを制限する仕組みである。具体的に何をやっているのかざっくりまとめると、 この3つのケースにおいて cookieなどを使ったデータ保持が短期間しかできなくなる（期間の長さはケースごとそれぞれ異なる） リファラが使い物にならなくなる 可能性があるということである。その結果 コンバージョントラッキングができない リマーケティング広告が配信で

Note: Read about past updates to this technology in other blog posts about Intelligent Tracking Prevention, and the Storage Access API. The beta releases of iOS 12.2 and Safari 12.1 on macOS High Sierra and Mojave include an updated version of Intelligent Tracking Prevention (ITP). For purposes of developer communication, we’ll refer to it as ITP 2.1. With this update we further reduce trackers’ a