Ekstensi Chrome: Memperluas API untuk mendukung Navigasi Instan

Dave Tapuska

TL;DR: Extensions API telah diupdate untuk mendukung back/forward cache, melakukan pramuat navigasi. Lihat detailnya di bawah ini.

Chrome telah bekerja keras untuk membuat navigasi menjadi cepat. Navigasi Instan teknologi seperti Back/Forward Cache (dikirim di desktop dalam Chrome 96) dan Aturan Spekulasi (dikirimkan di Chrome 103) meningkatkan kualitas proses mundur dan maju pengalaman yang lancar bagi developer. Dalam postingan ini, kita akan mempelajari update yang telah dilakukan pada browser API ekstensi untuk mengakomodasi alur kerja baru ini.

Memahami jenis-jenis halaman

Sebelum pengenalan Back/Forward Cache dan pra-rendering, individu tab hanya memiliki satu halaman aktif. Inilah yang selalu terlihat. Jika pengguna kembali ke halaman sebelumnya, halaman aktif akan dihancurkan (Halaman B) dan laman sebelumnya dalam riwayat akan direkonstruksi sepenuhnya (Halaman A). Ekstensi tidak perlu mengkhawatirkan bagian mana dari halaman siklus proses yang karena hanya ada satu untuk tab, yaitu status aktif/terlihat.

Dengan Back/Forward Cache dan pra-rendering, tidak ada lagi one-to-one hubungan antara tab dan laman. Sekarang, setiap tab benar-benar menyimpan beberapa halaman dan halaman beralih antarstatus, bukannya dihancurkan dan direkonstruksi.

Misalnya, sebuah halaman dapat memulai prosesnya sebagai halaman pra-rendering (tidak terlihat), bertransisi ke halaman aktif (terlihat) saat pengguna mengklik link, lalu disimpan di Back/Forward Cache (tidak terlihat) saat pengguna membuka halaman lain, semuanya tanpa pernah memusnahkan halamannya. Nanti di artikel ini kita akan melihat properti baru yang diekspos untuk membantu ekstensi memahami halaman negara bagian.

Perhatikan bahwa tab dapat memiliki serangkaian laman pra-rendering (bukan hanya satu), satu active (terlihat), dan serangkaian halaman Back/Forward yang di-cache.

Apa saja yang berubah bagi developer ekstensi?

IdBingkai == 0

Di Chromium, kami menyebut frame paling atas/utama sebagai frame terluar.

Penulis ekstensi yang menggunakan frameId dari {i>frame<i} terluar adalah 0 (praktik terbaik sebelumnya) mungkin bermasalah. Karena tab kini dapat memiliki beberapa frame terluar (pra-rendering dan di-cache halaman), dengan asumsi bahwa ada satu elemen terluar {i>frame<i} untuk tab salah. frameId == 0 akan terus mewakili frame terluar halaman aktif, tetapi frame terluar halaman other di tab yang sama akan menjadi bukan nol. Kolom baru frameType memiliki telah ditambahkan untuk mengatasi masalah ini. Lihat bagian “Bagaimana cara menentukan apakah bingkai merupakan bingkai terluar?” dari postingan ini.

Siklus proses frame versus dokumen

Konsep lain yang bermasalah dengan ekstensi adalah siklus hidup dari {i>frame<i}. Frame menghosting dokumen (yang terkait dengan URL yang di-commit). Dokumen dapat berubah (misalnya dengan menavigasi), tetapi frameId tidak, dan karenanya sulit mengaitkan sesuatu yang terjadi dalam dokumen tertentu dengan cukup frameIds. Kami memperkenalkan konsep documentId yang merupakan pengidentifikasi unik untuk setiap dokumen. Jika {i>frame<i} dinavigasi dan membuka dokumen baru yang akan diubah pengenalnya. Bidang ini berguna untuk menentukan kapan halaman mengubah status siklus prosesnya (antara pra-rendering/active/cache) karena tetap sama.

Peristiwa navigasi web

Peristiwa di namespace chrome.webNavigation dapat diaktifkan beberapa kali pada halaman yang sama tergantung pada siklus hidupnya. Lihat “Bagaimana cara mengetahui siklus proses apa yang ada di halaman?” dan bagian “Bagaimana cara menentukan waktu transisi halaman?”.

Bagaimana cara mengetahui siklus proses apa yang ada di halaman?

DocumentLifecycle telah ditambahkan ke sejumlah API ekstensi tempat frameId sebelumnya tersedia. Jika jenis DocumentLifecycle ada pada peristiwa (seperti onCommitted), nilainya adalah status tempat peristiwa dibuat. Anda selalu dapat mengkueri informasi dari WebNavigation getFrame() dan getAllFrames() , namun menggunakan nilai dari peristiwa akan selalu disukai. Jika Anda menggunakan salah satu metode tersebut mengetahui status {i>frame<i} dapat berubah antara saat peristiwa dibuat dan saat promise yang ditampilkan oleh kedua metode tersebut diselesaikan.

DocumentLifecycle memiliki nilai berikut:

• "prerender inci : Saat ini tidak ditampilkan kepada pengguna, tetapi bersiap untuk ditampilkan kepada pengguna.
• "active": Ditampilkan kepada pengguna.
• "cached": Disimpan dalam Back/Forward Cache.
• "pending_deletion": Dokumen sedang dihancurkan.

Bagaimana cara menentukan apakah {i>frame<i} adalah {i>frame<i} terluar?

Sebelumnya, ekstensi mungkin telah memeriksa apakah frameId == 0 menentukan jika kejadian yang terjadi adalah untuk {i>frame<i} terluar atau tidak. Dengan beberapa halaman Di tab, kita sekarang memiliki beberapa bingkai terluar, sehingga definisi frameId yang bermasalah. Anda tidak akan pernah menerima peristiwa tentang Back/Forward yang di-cache {i>frame<i}. Namun, untuk frame yang telah dipra-render, frameId akan bukan nol untuk {i>frame<i} terluar. Jadi menggunakan frameId == 0 sebagai sinyal untuk menentukan apakah bingkai terluar salah.

Untuk membantu melakukan hal ini, kami memperkenalkan tipe baru yang disebut FrameType Jadi, menentukan apakah {i>frame<i} memang adalah {i>frame<i} terluar itu sekarang mudah. FrameType memiliki nilai berikut:

• "outermost_frame": Biasanya disebut sebagai bingkai paling atas. Perlu diketahui bahwa ada kelipatan. Misalnya, jika Anda memiliki pra-rendering dan di-cache laman, masing-masing memiliki {i>frame<i} terluar yang bisa disebut {i>frame<i} paling atas.
• "fenced_frame": Dicadangkan untuk penggunaan pada masa mendatang.
• "sub_frame": Biasanya iframe.

Kita dapat menggabungkan DocumentLifecycle dengan FrameType dan menentukan apakah suatu frame {i>frame<i} terluar yang aktif. Contoh: tab.documentLifecycle === “active” && frameType === “outermost_frame”

Bagaimana cara mengatasi masalah waktu penggunaan dengan frame?

Seperti yang kami katakan di atas, {i>frame<i} meng-{i>host<i} dokumen dan {i>frame<i} dapat menavigasi ke direktori dokumen, tetapi frameId tidak akan berubah. Hal ini menimbulkan masalah ketika Anda menerima peristiwa hanya dengan frameId. Jika Anda mencari URL dalam {i>frame<i} itu mungkin berbeda dari ketika peristiwa terjadi, hal ini disebut masalah waktu penggunaan.

Untuk mengatasinya, kami memperkenalkan documentId (dan parentDocumentId). webNavigation.getFrame() kini menjadikan frameId opsional jika documentId disediakan. Tujuan documentId akan berubah setiap kali frame dibuka.

Bagaimana cara menentukan kapan halaman bertransisi?

Ada sinyal eksplisit untuk menentukan kapan transisi halaman antarstatus.

Mari kita lihat peristiwa WebNavigation.

Untuk navigasi pertama pada halaman, Anda akan melihat empat peristiwa secara berurutan yang tercantum di bawah ini. Perhatikan bahwa keempat peristiwa ini dapat terjadi dengan Status DocumentLifecycle adalah "prerender" atau "active".

onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted

Hal ini diilustrasikan dalam diagram di bawah yang menunjukkan perubahan documentId ke "xyz" saat halaman pra-rendering menjadi halaman aktif.

Saat halaman bertransisi dari Back/Forward Cache atau pra-rendering ke status aktif, akan ada tiga peristiwa lagi (tetapi dengan DocumentLifecyle menjadi "active").

onBeforeNavigate
onCommitted
onCompleted

documentId akan tetap sama seperti pada peristiwa asli. Ini adalah yang diilustrasikan di atas saat documentId == xyz diaktifkan. Perhatikan bahwa peristiwa navigasi yang sama diaktifkan, kecuali untuk onDOMContentLoaded karena halaman sudah dimuat.

Jika ada komentar atau pertanyaan, jangan ragu untuk bertanya di chromium-extensions ras.