Chrome 152 Beta برای توسعه دهندگان؛ تغییرات CSS، APIها و موارد نیازمند مهاجرت

Chrome 152 از 30 ژوئیه 2026 وارد کانال Beta شده و مجموعه ای از قابلیت های CSS، Web API، PWA، رسانه، WebGPU و Isolated Web Apps را همراه یک حذف و دو مسیر مهاجرت ارائه می کند. این مقاله تغییرات را از دید اثر واقعی روی محصول دسته بندی می کند تا بدانید چه چیزی را همین حالا آزمایش کنید، چه چیزی فقط برای پروژه های خاص مهم است و کجا احتمال regression وجود دارد.

Chrome 152 Beta دقیقاً چه وضعیتی دارد؟

Google در 30 ژوئیه 2026 اعلام کرد Chrome 152 در کانال Beta برای Android، ChromeOS، Linux، macOS و Windows قرار گرفته است. Beta به معنی stable بودن قابلیت ها برای همه کاربران نیست؛ اما مرحله ای است که تیم های وب باید تست compatibility را جدی کنند. فاصله بین Beta و Stable فرصت پیدا کردن regression در browser automation، component library، PWA و مسیرهای رسانه ای است. قابلیت هایی که پشت Origin Trial هستند نیز نیازمند opt-in جداگانه اند و نباید با قابلیت پیش فرض اشتباه گرفته شوند.

بهترین روش خواندن release note این نیست که همه featureها را یکسان مهم بدانیم. برخی مانند autocorrect و pseudo-classهای media دامنه عمومی دارند؛ برخی مانند subgroup-size-control فقط برای workloadهای WebGPU مهم اند؛ و بعضی موارد مثل Window Shape API به IWA روی ChromeOS محدود می شوند. تیم باید ابتدا inventory خود را با این دسته ها تطبیق دهد و فقط موارد مرتبط را وارد test plan کند.

تغییرات CSS و UI که بیشترین کاربرد عمومی دارند

کنترل برنامه نویسی pseudo-elementهای تازه

رابط CSSPseudoElement پیش تر برای pseudo-elementهایی مانند ::before و ::after تعریف شده بود. Chrome 152 پشتیبانی را به ::backdrop، ::scroll-marker و ::view-transition گسترش می دهد. کاربرد عملی ::backdrop این است که کلیک روی پس زمینه dialog را بدون منطق پیچیده تشخیص intersection مدیریت کنید، در حالی که کلیک داخل محتوای dialog اشتباه گرفته نمی شود.

::view-transition برای تیم هایی مهم است که transitionهای هندسی پیاده کرده اند. قابلیت جدید امکان intercept کردن transition در حال اجرا و شروع transition بعدی با مختصات عنصر در حال انیمیشن را فراهم می کند تا پرش بصری کمتر شود. این API نباید باعث شود fallback CSS کنار گذاشته شود؛ رفتار browserهای دیگر و حالت prefers-reduced-motion همچنان باید در طراحی component لحاظ شود.

attribute استاندارد autocorrect

attribute سراسری autocorrect به توسعه دهنده اجازه می دهد autocorrection را در input، textarea و hostهای contenteditable کنترل کند. این موضوع برای فیلدهایی مانند کد، نام کاربری، شناسه فنی، شماره قطعه یا متن چندزبانه مهم است؛ جایی که اصلاح خودکار می تواند داده صحیح را به مقدار اشتباه تبدیل کند. استفاده از آن باید هدفمند باشد؛ خاموش کردن autocorrect در تمام فرم ها تجربه نوشتن طبیعی را برای کاربران عادی تضعیف می کند.

<label for="repo">نام مخزن</label>
<input
  id="repo"
  name="repo"
  type="text"
  autocorrect="off"
  autocomplete="off"
  spellcheck="false"
>

این سه کنترل یک معنی ندارند. autocorrect اصلاح خودکار را هدف می گیرد، autocomplete پیشنهاد یا پرکردن مقدار را کنترل می کند و spellcheck بررسی املایی را. برای یک input فنی ممکن است هر سه خاموش باشند، اما برای متن توضیحی معمولاً spellcheck و autocorrect ارزشمندند.

pseudo-classهای وضعیت audio و video

Chrome 152 pseudo-classهای :playing، :paused، :seeking، :buffering، :stalled، :muted و :volume-locked را برای elementهای media پشتیبانی می کند. این قابلیت بخشی از تمرکز Interop 2026 است و به UI اجازه می دهد بدون mirror کردن تمام stateها در JavaScript واکنش بصری نشان دهد. برای مثال می توان هنگام buffering یک indicator را نمایش داد یا ظاهر دکمه mute را براساس state واقعی media تغییر داد.

video:buffering + .media-status::after {
  content: "Loading";
}

video:muted + .media-status {
  opacity: 0.7;
}

video:playing + .media-status {
  visibility: hidden;
}

در production باید progressive enhancement رعایت شود، زیرا selector ناشناخته ممکن است rule را در browserهای قدیمی بی اثر کند. state حیاتی مانند accessible label یا کنترل playback نباید فقط به CSS وابسته باشد؛ pseudo-class بهترین نقش را در presentation و کاهش glue code دارد، نه جایگزینی کامل منطق player.

alpha() و window-drag

تابع alpha() در CSS Color 5 اجازه می دهد رنگ مبنا حفظ و فقط کانال شفافیت تغییر کند. این الگو برای design tokenها مفید است، چون لازم نیست نسخه RGB یا HSL رنگ را دوباره استخراج کنید. در سوی دیگر، property جدید window-drag ناحیه draggable را در PWA دسکتاپ مشخص می کند، نام استانداردشده app-region است، valueها را به move و none تغییر می دهد و inheritance صریح دارد. مهاجرت باید با بررسی hit targetهای interactive همراه باشد تا button داخل titlebar ناخواسته drag نشود.

Web APIهای مهم: تطبیق تجربه و محدود کردن اتصال

CPU Performance API

CPU Performance API tier عملکرد CPU دستگاه را در اختیار وب اپ قرار می دهد. هدف آن benchmark دقیق سخت افزار یا fingerprinting مستقیم نیست؛ کاربرد مناسب، انتخاب یک تجربه متناسب است. مثلاً editor تصویری می تواند effect پیش نمایش سبک تر انتخاب کند یا یک وب اپ AI اندازه مدل و concurrency را محافظه کارانه تنظیم کند. Google پیشنهاد می کند این اطلاعات در کنار Compute Pressure برای واکنش به فشار جاری استفاده شود، نه اینکه tier ثابت را حقیقت مطلق بدانیم.

کاربر می تواند مقدار گزارش شده را در Performance settings override کند و مدیر سازمان نیز policy مربوط به CpuPerformanceTierOverride دارد. بنابراین کد نباید tier را برای authorization، pricing یا deny کردن feature اساسی استفاده کند. آن را hint تجربه کاربری بدانید. همچنین telemetry باید بررسی کند تصمیم adaptive واقعاً latency، crash یا battery consumption را بهتر کرده است؛ صرف در دسترس بودن API دلیل استفاده نیست.

Connection Allowlists

Connection Allowlists به document یا worker اجازه می دهد مقصدهای اتصال را به فهرست مجاز محدود کند. سرور فهرست endpointهای مجاز را در یک HTTP response header توزیع می کند و Chrome پیش از اتصال مقصد را بررسی می کند. اتصال هایی که match نباشند مسدود می شوند. این قابلیت می تواند لایه دفاعی مفیدی برای کاهش data exfiltration یا تماس تصادفی با domainهای خارج از معماری باشد، به ویژه در اپ هایی که scriptهای متعدد یا محتوای extensible دارند.

بااین حال allowlist اشتباه می تواند production را قطع کند. domainهای analytics، image CDN، API منطقه ای، WebSocket، OAuth callback و endpointهای failover باید در inventory باشند. rollout مناسب از report یا محیط staging آغاز می شود، سپس policy با observability و rollback منتشر می شود. این مکانیزم نیز جای CSP، validation سمت سرور و کنترل egress زیرساخت را نمی گیرد؛ یک کنترل browser-side مکمل است.

OpaqueRange برای متن داخل form control

OpaqueRange یک بازه زنده از متن داخل value فیلدهایی مانند textarea و input متنی را نمایش می دهد. APIهایی مانند getBoundingClientRect()، getClientRects() و CSS Custom Highlight می توانند برای suggestion درون خطی، highlight و popover متصل استفاده شوند. برای حفظ encapsulation فقط offsetهای value آشکار می شوند و startContainer یا endContainer مقدار null می دهند. این طراحی برای editorهای سبک، autocomplete و ابزارهای نگارشی مهم است.

تغییر رفتار اعلان PWA روی macOS

در macOS، اعلان PWA نصب شده اکنون به خود PWA با نام و icon آن در Notification Center نسبت داده می شود، نه به Google Chrome. این تغییر تجربه را به اپ native نزدیک می کند اما دو اثر سازگاری دارد. اول، requireInteraction برای notificationهای PWA روی macOS دیگر پشتیبانی نمی شود، زیرا persistence توسط تنظیمات per-app سیستم عامل کنترل می شود. دوم، نمایش badge از Badging API به permission اعلان نیاز دارد.

برای سازمان هایی که permission را از طریق policy پیش اعطا می کنند، صرف NotificationsAllowedForUrls کافی نیست؛ Google می گوید profile مربوط به MDM برای bundle ID مشخص PWA نیز لازم است. بنابراین regression ممکن است فقط روی دستگاه managed دیده شود. تست باید نصب تازه، upgrade PWA موجود، deny/allow permission، badge و رفتار notification در focus و background را پوشش دهد.

Isolated Web Apps و WebGPU؛ قابلیت های تخصصی اما مهم

IWA Sub apps اجازه می دهد یک Isolated Web App چند sub app با نام، icon و OS integration جدا داشته باشد. هر sub app می تواند روی shelf هویت مستقل و association فایل متفاوت داشته باشد. این قابلیت بیشتر برای suiteهای سازمانی یا kioskهای مدیریت شده مناسب است. policyهای enterprise برای اجازه یا منع نصب بدون prompt ارائه شده اند؛ در نتیجه طراحی packaging باید با مدیریت دستگاه هماهنگ باشد.

Unframed display mode border و titlebar استاندارد را حذف می کند تا IWA کل پنجره را با branding و menu hierarchy سفارشی پر کند. Window Shape API نیز روی ChromeOS می تواند شکل غیرمستطیلی پنجره بسازد، اما به unframed mode و window management permission نیاز دارد. این آزادی UI مسئولیت accessibility، drag region، close/minimize affordance و discoverability را بالا می برد. custom chrome نباید کاربر را از کنترل های پایه سیستم محروم کند.

در WebGPU، feature اختیاری subgroup-size-control به compute shader اجازه می دهد اندازه subgroup را برای سخت افزار هدف مشخص کند. workloadهای AI و محاسبات موازی که از subgroup operation استفاده می کنند ممکن است performance قابل پیش بینی تری بگیرند. اما انتخاب اندازه نادرست یا فرض پشتیبانی همگانی می تواند نتیجه معکوس دهد. feature detection، benchmark روی GPUهای واقعی و fallback shader ضروری است.

رسانه، DRM و اشتراک صفحه

attribute جدید encryptionScheme در تنظیمات MediaCapabilities به برنامه اجازه می دهد پشتیبانی از schemeهایی مانند cenc یا cbcs را از طریق decodingInfo() بپرسد. برای سرویس ویدئویی، این query می تواند پیش از انتخاب stream یا DRM configuration انجام شود و خطای دیرهنگام playback را کاهش دهد. پاسخ API باید همراه codec، resolution و key system ارزیابی شود؛ یک field به تنهایی compatibility کامل را تضمین نمی کند.

در getDisplayMedia()، hint جدید audioPreference به browser اعلام می کند که اشتراک audio همراه video ترجیح داده می شود. این فقط preference است و تصمیم نهایی به browser، سیستم عامل و انتخاب کاربر بستگی دارد. UI نباید بعد از درخواست فرض کند audio حتماً وجود دارد؛ trackهای برگشتی را بررسی کنید و اگر audio در دسترس نبود، پیام روشن و مسیر retry ارائه دهید.

Origin Trialها، deprecation و حذف

Speculation Rules viewport heuristics

Origin Trial تازه برای کنترل heuristicهای viewport در Speculation Rules ارائه شده است. سایت هایی که prefetch یا prerender را بر اساس نزدیکی link به viewport تنظیم می کنند می توانند پارامترهای جایگزین را آزمایش کنند. معیار موفقیت فقط سرعت navigation نیست؛ مصرف bandwidth، کار بی استفاده، hit rate و اثر روی دستگاه ضعیف نیز باید اندازه گیری شود. این قابلیت آزمایشی را بدون flag و ثبت cohort وارد تجربه عمومی نکنید.

client-side XSLT

Chrome به حذف client-side XSLT در Chrome 158 نزدیک می شود. برای سایت هایی که هنوز XML را در browser با stylesheet تبدیل می کنند، deprecation trial امکان تمدید مهاجرت حدود نه ماه تا Chrome 175 را می دهد. trial درمان دائمی نیست؛ فقط زمان می خرد. inventory استفاده از XSLTProcessor، processing instructionهای XML و صفحات legacy را انجام دهید و تبدیل را به build step، server-side rendering یا JavaScript استاندارد منتقل کنید.

حذف Private Aggregation API

Private Aggregation API در Chrome 152 حذف می شود و Google آن را در کنار تغییر مسیر برخی Privacy Sandbox APIها قرار داده است. اگر محصول شما مستقیماً Shared Storage یا Protected Audience را با aggregation integration استفاده می کند، usage را در code و vendor SDKها پیدا کنید. بسیاری از تیم ها مصرف مستقیم ندارند اما dependency تبلیغاتی ممکن است داشته باشد؛ بنابراین فقط جست وجوی repository کافی نیست و release note سرویس های third-party نیز باید بررسی شود.

چک لیست تست Chrome 152 Beta

1. نسخه Beta را روی حداقل یک سیستم دسکتاپ و Android در محیط جدا نصب کنید.
2. suite خودکار critical path را اجرا و تفاوت screenshot، console و network را ثبت کنید.
3. فرم های دارای autocomplete، spellcheck و input فنی را با autocorrect آزمایش کنید.
4. playerهای audio/video را در حالت play، pause، seek، buffer، mute و stall بررسی کنید.
5. برای PWA macOS، attribution اعلان، permission badge و نبود requireInteraction را تست کنید.
6. هر استفاده مستقیم یا غیرمستقیم از XSLT و Private Aggregation را inventory کنید.
7. در صورت استفاده از API تازه، feature detection و fallback را قبل از merge بنویسید.
8. برای Origin Trial، cohort، metric موفقیت، تاریخ انقضا و owner تعیین کنید.
9. نتیجه را در browser support matrix و release readiness تیم ثبت کنید.

پرسش های متداول

Chrome 152 چه زمانی وارد Beta شد؟

در 30 ژوئیه 2026 و برای Android، ChromeOS، Linux، macOS و Windows.

آیا CPU Performance API سرعت دقیق CPU را می دهد؟

هدف آن ارائه tier برای تطبیق تجربه است، نه benchmark دقیق یا تصمیم امنیتی.

چه تغییری برای اعلان PWA در macOS رخ داده است؟

اعلان به خود PWA نسبت داده می شود؛ requireInteraction پشتیبانی نمی شود و Badge permission اعلان می خواهد.

آیا client-side XSLT همین حالا حذف شده است؟

خیر، حذف برای Chrome 158 برنامه ریزی شده و trial مهاجرت تا حدود Chrome 175 زمان اضافه می دهد.

Private Aggregation API چه وضعیتی دارد؟

در Chrome 152 حذف می شود؛ مصرف مستقیم و dependencyهای third-party باید ممیزی شوند.

آیا قابلیت های Chrome Beta را می توان فوراً production-only کرد؟

بهتر است با feature detection، fallback و تست cross-browser استفاده شوند؛ Beta مرحله ارزیابی قبل از Stable است.

جمع بندی

Chrome 152 Beta یک release تک موضوعی نیست. برای بیشتر تیم های وب، autocorrect، media state pseudo-classها، تغییر notification PWA و برنامه حذف XSLT مهم ترند. برای محصول های امنیت محور، Connection Allowlists ارزش آزمایش دارد؛ برای AI و graphics، CPU tier و WebGPU subgroup control مطرح اند؛ و برای IWAهای سازمانی، sub app و window management دامنه تازه ای باز می کنند.

فهرست کامل قابلیت ها، Origin Trialها و حذف ها در اعلام رسمی Chrome 152 Beta برای توسعه دهندگان منتشر شده است. اقدام درست، فعال کردن همه featureها نیست؛ بلکه ساخت یک test matrix براساس exposure واقعی محصول و حل موارد migration پیش از Stable است.