Bir Chrome extension JSON'u otomatik olarak İndirilenler klasörüne kaydederken bozulan sekiz şey

25 Eylül 2026'da dev.to'da yayınlanan bir yazı, bir tarayıcı extension'ının kendi verisinin bir JSON kopyasını kullanıcının İndirilenler klasörüne otomatik olarak kaydetmesi için nelerin gerektiğini ve görünüşte basit olan downloads.download() çağrısının Manifest V3 altında neden bir mayın tarlasına dönüştüğünü adım adım anlatıyor. Yazıda, metnin herhangi bir insan editörlüğü olmadan bir yapay zeka ajanı (Claude) tarafından üretildiği belirtiliyor; üretim, Chrome, Edge ve Firefox için MIT lisanslı açık kaynaklı bir sekme yöneticisi olan TabBunker'ın kaynak kodu ile Eylül 2026'da Chrome for Testing 153 ve Firefox 155 üzerinde yapılan test çalıştırımlarına dayanıyor. Yazı, yol boyunca bozulan sekiz şeyi sayıyor.

Neden İndirilenler klasörüne otomatik kayıt

Çıkış noktası oynaklıktır (volatility). Yazıya göre Chrome'un dokümantasyonu, storage.local verisinin extension kaldırıldığında silindiğini belirtiyor; yani Kaldır'a tek bir tıklama, yanlışlıkla yapılan bir kaldırma veya silinen bir profile, bir sekme yöneticisindeki kayıtlı tüm listeleri yok ediyor. Projenin cevabı, İndirilenler/TabBunker/ klasöründe düz bir JSON dosyasıydı; her değişiklikten kısa bir süre sonra yeniden yazılıyor, sunucusuz, hesapsız ve dosya seçici olmadan. Tasarım, conflictAction: 'overwrite' ile yazılan hep güncel tek bir dosyayı, artı conflictAction: 'uniquify' ile yazılan tarihli anlık görüntüleri içeriyor — bir şey değiştiğinde saatte en fazla bir tane, en yeniden 30 tanesi tutuluyor. Yazma işlemleri, Manifest V3 service worker'ı 30 saniye sonra hayatta olmayabileceği için, chrome.alarms kullanılarak ilk kaydedilmemiş düzenlemeden 30 saniye sonra planlanıyor.

Bir string'i downloads API'sine ulaştırmak

İlk bozulma klasik Blob-URL hilesidir. Yazıya göre URL.createObjectURL bir Chrome MV3 service worker'da mevcut değildir; Firefox ise MV3 arka planını createObjectURL'un mevcut olduğu bir event page olarak çalıştırır — ancak yazarın testlerinde Firefox bir data: URL indirmesini erişim reddedildi hatasıyla geri çevirmiştir. Çözüm özellik algılamadır (feature detection): mevcut olduğunda createObjectURL kullan, aksi halde data: URL'ye düş ve indirme tamamlandığında Blob URL'leri iptal et (revoke). Yazar ayrıca data: yolunu 1 MB'dan 64 MB'a kadar dosyalarla ölçmüştür; en büyüğü Chrome for Testing'de yaklaşık 1,3 saniyede tamamlandığından, gerçek dünyadaki yükler limitlerin rahatça içindedir.

Üzerine yazma, indirme geçmişi ve temizlik

Yazı, conflictAction: 'overwrite' davranışının test edilen iki tarayıcıda da aynı olduğunu, diskte en yeni içerikle tek bir dosya bıraktığını buldu. Ancak her yazma, tarayıcının indirme geçmişine de bir kayıt ekler; dolayısıyla birkaç dakikada bir yeniden yazılan bir dosya, kullanıcının indirme listesini çöp bilgisiyle doldurur. Bu nedenle extension, her yeni yazma tamamlandıktan sonra önceki geçmiş kaydını siler; erase yalnızca geçmiş kaydını siler, diskteki dosyayı değil. Eski anlık görüntüleri silmenin kendi sıralama tuzağı vardır: downloads.removeFile(id), downloads.erase({ id })'den önce çalışmalıdır, çünkü erase'den sonra kaldırılacak bir öğe kalmaz. Kullanıcı dosyayı zaten elle sildiğinde, öğe exists: false bildirir ve yalnızca erase gerekir. Yazı, aynı dosyayı silme üç kez başarısız olursa anlık görüntülemenin durduğunu ve hatanın döngüye girmek yerine yüzeye çıkarıldığını ekliyor.

Dosya adı değil, id

Extension'ın kendi dosyasını ada göre araması Chrome 153'te başarısız oldu: filenameRegex sorgusu mutlak yolla eşleşiyor, extension'ın kendi verdiği göreli dosya adını kullanan kesin bir sorgu ise sıfır sonuç döndürüyordu. Yazının vardığı sonuç, güvenilir tanıtıcının downloads.download()'ın çözüldüğü sayısal id olduğudur; bu id devam eden yazma, güncel dosya ve her anlık görüntü için saklanır. İlgili bir risk, bir indirmenin onu başlatan service worker'dan daha uzun yaşamasıdır. Bunu güvenli kılan üç önlem alındı: id'yi promise çözüldükten hemen sonra saklamak; downloads.onChanged dinleyicisini arka plan betiğinin en üstünde senkron olarak kaydetmek, çünkü Chrome uyandırma olayını yalnızca betiğin ilk çalışması sırasında kaydedilen dinleyicilere gönderir; ve tamamlanan ya da kesilen indirmeleri sonuçlandırıp hâlâ çalışanları yeniden denenebilmeleri için duraklatılmış (stalled) olarak işaretleyen iki dakikalık bir watchdog alarmı kurmak.

İptaller ve kayıp düzenlemeler

Chrome'da saveAs: false, tarayıcının 'nereye kaydedilecek' ayarını geçersiz kılmaz ve extension'ın indirmesi USER_CANCELED ile kesildi (interrupted) olarak sonuçlandı — headless bir çalıştırmada 277 ms sonra. Yeniden denemek her 30 saniyede bir kaydetme iletişim kutusu açardı; bu nedenle iptal, kullanıcı harekete geçene kadar yedeklemeyi duraklatır; kapanma ve çökme, devam eden yazma işaretini (in-flight marker) sadece temizler; disk dolu veya erişim reddedildi gibi diğer hatalar 5 dakika sonra, ardından her 30 dakikada bir yeniden denenir. Son olarak, boole tipi bir dirty bayrağı bir yarış durumu barındırır: yedekleme sürerken yapılan bir düzenleme, kaydedilmemişken kaydedilmiş olarak işaretlenebilir. Bunun yerine geçirilen çözüm monotonik bir revizyon sayacıdır — her düzenleme sayacı artırır, her yazma yakaladığı revizyonu kaydeder ve tamamlanma en yükseğini korur.

Neden önemli

storage.local kalıcı bir arşiv değildir ve arka uç olmadan kalıcılığa ihtiyaç duyan extension geliştiricileri doğal olarak downloads API'sine yönelecektir. Bu yazı, bu yaklaşımın pratikte karşılaştığı hata türlerinin uygulamalı bir kontrol listesidir: service worker'larda eksik API'ler, extension bayraklarını geçersiz kılan tarayıcı ayarları, indirme geçmişi kirliliği ve düzenlemelerle yazmalar arasındaki yarış durumları. Aynı zamanda makine destekli teknik yazım hakkında ilginç bir veri noktasıdır — yazar, metnin kaynak kod ve ölçülmüş test çalıştırımlarından yapay zeka tarafından üretildiğini açıkça belirtiyor ve tarayıcı sürümleri ile zamanlamalardaki spesifiklik, bulguları tam da bu nedenle güvenilir ve yeniden kullanılabilir kılıyor.