DEV Community: M.Bilal Khan

Android Is Taking Away Orientation Locks on Large Screens. Here’s What Developers Need to Know

M.Bilal Khan — Thu, 10 Sep 2026 07:43:29 +0000

For years, Android developers have had a simple way to control how their apps behave: tell the system that an activity should stay in portrait, keep it in landscape, or otherwise restrict how the app can rotate.

That familiar approach is changing.

Starting with Android 16, API level 36, apps targeting API 36 or higher can no longer rely on orientation restrictions on large-screen devices. That includes tablets and other devices where the display has a smallest width of 600dp or more. On those screens, Android can ignore an app's requested orientation and allow the user and the device to determine how the app is displayed.

And this is not just a small API change. It represents a bigger shift in how Android expects developers to think about app layouts.

The old assumption: "This app is portrait"

Many Android apps were built around an implicit assumption:

This is a phone app, so portrait is the normal orientation.

Developers could enforce that assumption through the manifest or at runtime. A typical application might declare a portrait-only activity, or call setRequestedOrientation() when it needed to lock the screen.

That worked reasonably well when the majority of Android devices were phones with relatively predictable screen sizes.

But today's Android ecosystem is considerably messier, in the good sense.

There are tablets, foldables, desktop-style windows, external displays and devices whose natural orientation may not match what an app developer expects. Google is increasingly treating Android as a platform where an application should be able to adapt to the space it is given rather than dictate the shape of that space.

What actually changes in Android 16?

For apps targeting Android 16/API 36 or higher, Android ignores several mechanisms that developers previously used to restrict large-screen applications.

That includes:

android:screenOrientation
android:resizeableActivity
android:minAspectRatio
android:maxAspectRatio
setRequestedOrientation()
getRequestedOrientation()

The orientation values developers are accustomed to, such as portrait, landscape, sensorPortrait, and sensorLandscape, are ignored on those large displays.

So imagine an app that has always been portrait-only.

On a phone, it can continue behaving as expected.

On a sufficiently large tablet, however, targeting API 36 means the system is allowed to display that app in landscape even though the developer requested portrait.

That can be a rather uncomfortable surprise.

Why is Google doing this?

Google's reasoning is fairly straightforward: large screens are no longer supposed to behave like oversized phones.

A tablet can be used in portrait or landscape. A foldable can change its available space dramatically. Desktop-style windowing can give an app a window that changes size while the application is running.

From Android's perspective, locking an application to one orientation makes these experiences harder to support.

Google describes orientation and resizability restrictions as increasingly restrictive in a world of multiple device types and window sizes. The direction Android is taking is therefore toward adaptive applications, where the UI responds to the available space rather than assuming one fixed screen shape.

In other words, Android is effectively saying:

"Don't tell me what shape your screen must be. Tell me how your UI behaves when the shape changes."

That is a reasonable philosophy.

It is also a potentially painful migration for existing applications.

The real problem for developers

The difficult part is not rotation itself.

The difficult part is discovering how many parts of your application quietly depended on rotation never happening.

An app may have:

fixed-width layouts
UI elements positioned with hardcoded assumptions
animations that assume a particular screen ratio
camera previews tied to a specific orientation
custom drawing code that expects portrait dimensions
fragments or activities that were never designed for resizing
state that is not restored correctly when an activity is recreated

Google specifically warns that applications designed around small-screen layouts and a fixed portrait orientation can experience problems such as stretched layouts, components appearing off-screen, or animations behaving incorrectly when these restrictions are removed. Device rotation can also cause activity recreation, which makes proper state preservation important.

This is where the change stops being a policy decision and becomes a real engineering problem.

"But my app works perfectly in portrait"

That may be exactly the problem.

If your application works perfectly because it has never been exposed to anything else, Android 16 can expose assumptions that were previously hidden.

Take a simple example.

Suppose a screen was designed around a width of 400dp and a vertical list of controls. In portrait mode, everything looks fine.

Now put that same screen into a much wider window.

The controls might spread too far apart. A fixed-width panel may look tiny. A button positioned near the bottom may end up somewhere unexpected. A custom animation may calculate its movement based on dimensions that no longer make sense.

Nothing is technically "broken" in Android.

The application simply wasn't designed for the new environment.

Tablets are only part of the story

Although this change is often described as the "tablet orientation lock problem," tablets are really just the most obvious example.

The Android documentation specifically points to:

tablets
large foldable displays
desktop windowing
different window sizes and configurations

The common factor is available screen space, not the marketing category of the device. Android uses the sw600dp threshold to determine the large-screen behavior.

This also explains why a developer may see behavior that seems inconsistent between devices.

One Android device may respect the old behavior because its available screen width falls below the threshold, while another larger device may ignore the orientation request.

There is a temporary escape hatch

Android 16 does provide developers with a temporary compatibility option.

An application or activity can use the PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest property to retain the older restricted behavior while the app is being migrated.

That sounds comforting, but there is an important catch.

It is temporary.

Google's current documentation says this opt-out will not be available once an application targets Android 17/API 37. At that point, orientation, aspect-ratio and resizability restrictions will always be ignored on displays meeting the large-screen threshold.

So the compatibility property is better thought of as a migration bridge, not a permanent solution.

What should developers do instead?

The answer is not necessarily "remove every orientation restriction tomorrow."

The more useful approach is to start identifying what your application actually depends on.

If an application truly needs a particular layout, make that layout work at different sizes.

If a camera screen needs special handling, make the camera preview respond correctly to the available orientation and display configuration.

If a screen contains a large collection of controls, redesign it so those controls can reflow, resize or reposition instead of assuming a fixed portrait canvas.

Modern Android development increasingly revolves around responsive and adaptive UI. The goal is not simply to support portrait and landscape as two separate versions of a screen. It is to make the interface respond to the amount of space available.

That distinction is important.

This may actually be good for Android users

From a user's perspective, Google's decision makes sense.

If someone buys a large tablet, they reasonably expect the tablet to behave like a tablet. If they rotate it, they expect applications to make reasonable use of that space.

Being greeted by a narrow portrait application floating awkwardly inside a huge display is not exactly the premium large-screen experience.

Android 16's change is intended to reduce that kind of compatibility behavior by allowing apps to use the full available display instead of remaining locked into older aspect-ratio and orientation assumptions.

The downside is that Android is moving some of the complexity from the platform to the developer.

Previously, the system could help maintain the developer's preferred shape.

Now the developer increasingly has to make the application comfortable with whatever shape it receives.

One more thing: API 36 is becoming unavoidable

This change matters even more now because targeting API 36 is no longer a distant concern for Android developers.

Google's current documentation states that Google Play requires apps to target API level 36 as of August 2026.

That means this is moving from "something to keep an eye on" to a practical compatibility issue for applications distributed through Google Play.

And with Android 17/API 37 removing the temporary orientation/resizability opt-out entirely, developers shouldn't build their migration strategy around keeping the old behavior forever.

The bigger change isn't orientation

At first glance, Android 16's large-screen change looks like Google taking away a useful switch.

But the bigger message is different:

Android is moving from device-specific UI to space-specific UI.

Instead of thinking:

"This is my portrait screen."

Developers increasingly need to think:

"This is the space my application has right now. How should my interface behave inside it?"

That's a bigger mental shift than simply changing an AndroidManifest setting.

For new applications, this philosophy can lead to much better interfaces. For older applications, especially those built around fixed portrait screens, it can mean a painful round of testing and redesign.

Either way, the old assumption that a large Android screen will politely obey a portrait-orientation lock is becoming a thing of the past.

And Android 17 makes it clear that Google isn't planning to turn the clock back.

Two Ways to Write an Article in 2026 (And Why the Best Ones Use Both)

M.Bilal Khan — Mon, 17 Aug 2026 12:11:01 +0000

It's almost Midnight. Somewhere, a developer opens a blank tab, types a prompt into an AI, and has a polished 1,200-word article in minutes. Somewhere else, another developer opens the same blank tab, stares at it for forty minutes, deletes three sentences, writes one true one, and finally starts typing for real.

Both of them will hit publish tomorrow. Only one of them will get remembered.

That's the tension I want to talk about, because I think it's the real question hiding under "how do I write a good article" in 2026: not AI or heart — but how you let one serve the other.

Way One: Writing With AI

This is the fast lane, and it's genuinely useful. You bring the idea, the AI helps you:

Breakdown a topic
Draft an outline
Punch up a clunky sentence
Catch the boring paragraph you were too tired to notice
Turn years of scattered learning into one clean explanation

Used well, this isn't cheating. It's what editors have always done for writers — except now everyone has one.

Used badly, though, it produces a very specific kind of article: correct, competent, and completely forgettable. You've read a hundred of them. Perfect grammar. Zero pulse. The kind of post you skim, nod at, and never think about again. The tell is always the same — it sounds like an article about the topic, not like your article about it.

Way Two: Writing With Heart

This is the slow lane. It's you, the actual failure that taught you the lesson, the 2 AM bug that made you want to quit, the moment something finally clicked and you felt like a wizard for ten whole minutes.

Heart-writing isn't about being emotional for its own sake. It's about specificity. It's the difference between:

"Debugging can be frustrating but rewarding."

and:

"I spent three hours debugging our API, convinced the logic was broken. It wasn't. I'd written a nested loop with i and j as counters, and with my eyesight, on a bad-contrast monitor, they were nearly indistinguishable — I kept reading i where I'd written j, and my brain corrected it every single time without telling me. It took a junior dev, glancing over my shoulder for thirty seconds, to spot it. I went home and renamed many variable I owned that night..based on True story😊"

The second one isn't better because it's more honest in some abstract moral sense. It's better because it's true in a way nobody else could have written. That's the whole game. AI can simulate insight. It cannot simulate the specific, embarrassing, real thing that happened to you.

The cost of this path is that it's slower, scarier, and occasionally humbling — because writing with heart means admitting you didn't always know what you were doing.

The Real Answer: They're Not Two Roads. They're Two Hands.

Here's what actually works, and it's the framework underneath most articles you've bookmarked without noticing:

1. Start with the true thing only you have.
Not a topic. A moment. The bug, the mistake, the surprising result, the question a junior dev asked you that you couldn't answer cleanly. This is the part AI cannot do for you, because it doesn't have your Tuesday.

2. Let AI hold the structure while you hold the story.
Once you know what happened, structure is a solved problem — and this is where AI genuinely shines. Ask it to help you outline, to suggest where the piece drags, to find the sentence buried on paragraph nine that should actually be your opening line. Let it be your scaffolding, not your voice.

3. Write the ugly first draft yourself.
Even three rough paragraphs. Even bad ones. This is non-negotiable, and here's why: your voice lives in your word choices under pressure — the slightly weird metaphor, the joke that only makes sense if you know you, the rhythm of how you explain things when you're not trying to sound impressive. AI can polish that voice. It can't originate it from nothing.

4. Use AI as your harshest kind editor, not your ghostwriter.
"Where does this get boring?" "What's the weakest paragraph?" "Is my opening line actually earning the reader's next thirty seconds?" These are incredible questions to ask a model. "Write my article for me" is not — because you'll get back competence with the fingerprints sanded off.

5. Read it out loud before you publish.
This one has nothing to do with AI. It's the oldest trick there is, and it still catches everything: the sentence that's too long, the paragraph that doesn't mean anything, the ending that fizzles instead of lands. If you'd feel embarrassed saying a sentence to a friend, don't publish it.

Why This Actually Matters

Here's the thing nobody tells you about writing on dev.to or Medium in 2026: readers have gotten very good at smelling the difference between a piece written through someone and a piece written by something. Not because AI writing is bad — it isn't — but because readers aren't actually looking for information anymore. They can get information anywhere, instantly, for free. What they're looking for, every time they click on an article instead of asking a chatbot directly, is you. Your particular scar tissue. Your particular way of seeing a problem. The proof that a real person went through something and came back with a flashlight for the rest of us.

That's not a nostalgic argument for doing things the hard way. It's a practical one: the articles that get saved, shared, and remembered are the ones where a real experience got a little help getting dressed for the world — not the ones where an experience was replaced entirely.

So, Start Tonight

Don't open with a prompt. Open with a memory — the bug, the launch that went sideways, the comment on your PR that stung more than it should have, the tiny win nobody else would understand the weight of.

Write that part yourself, badly, honestly.

Then bring in the help.

That's not two ways to write an article in 2026. That's one way, done right — with both hands.

I built a Chrome extension, got 100 installs, and 90% of users left. Here's what I'm fixing.

M.Bilal Khan — Tue, 11 Aug 2026 10:42:27 +0000

Somewhere around install #80, I stopped checking my Chrome Web Store dashboard every day. Not because I'd lost interest — because the number that mattered wasn't installs anymore, it was this one: 10 active users.

Out of 101 people who installed Goat Alert, roughly 20 uninstalled it outright, and most of the rest just... quietly stopped using it. No uninstall, no feedback, no bug report. They just went dark.

That's a rough number to sit with when you built the thing yourself. But it's also the most useful number I have, because it's telling me something installs never could: the idea works well enough to get a "yes," and not well enough to get a "keep."

Here's what I think is actually happening.

Goat Alert does one thing: it notifies you at a random interval, and if you ignore it for 60 seconds, a goat sound plays. That's funny for the first three, maybe five times. Then it becomes exactly what any repetitive notification becomes — noise you've learned to dismiss on reflex, or annoying enough that you just turn the extension off.

I built a joke. I didn't build a habit. Those are different problems, and I only fully understood that after watching my own retention numbers.

What I'm changing:

Snooze, not just dismiss. Right now the only options are "deal with the notification" or "ignore it and get screamed at." There's no middle ground for "not now, but check on me in 5." Adding a snooze button on the notification itself — no popup, no extra click, just an action button.

Rotating messages. Same text every time is a big part of why it becomes background noise so fast. Swapping in a small rotating set of messages so it doesn't read as identical each time.

Streaks and a stats page. This is the one I think matters most. Right now there's zero feedback loop — you either get annoyed or you don't, and nothing sticks around to show you it's working. Adding a simple streak counter and a stats page (times dismissed, times the goat actually screamed, days active) gives people a reason to open the popup that isn't just "turn this off."

A gentler alternative sound. Not everyone wants a goat scream as their daily interruption. Adding a soft chime mode as an option, so the "annoying by design" mechanic still works for people who want persistence without chaos.

None of this requires new permissions, so the update ships silently to everyone already using it — no re-approval prompt, no disruption.

The honest part

I don't know yet if any of this actually fixes retention. It's a reasonable theory based on watching where people seem to drop off, not a guarantee. The only way I'll actually know is by shipping it and watching the same numbers again in a few weeks.

If you've built something small that people install and then abandon, I'd genuinely like to hear what you found — whether it was a UX thing, a "this solved a one-time problem" thing, or something else entirely. Retention on tiny tools feels like an underdiscussed problem compared to how much airtime "getting the first users" gets.

How MV3 Service Workers Made Me Use an Offscreen Document Just to Play a Goat Sound

M.Bilal Khan — Tue, 21 Jul 2026 06:59:27 +0000

So I built a Chrome extension that does one very stupid thing: it waits a random amount of time, then screams at you like a goat if you don't dismiss the notification fast enough.

Simple idea. Should've been a simple build. It was not, because Manifest V3 said no.

The plan was easy, in my head

Here's what I thought I needed:

chrome.alarms to fire at a random interval
chrome.notifications to show a "you good?" popup
If the user ignores it for 60 seconds, play a goat sound

Step 3 is where things fell apart. Because in Manifest V3, your background script isn't a persistent background page anymore — it's a service worker. And service workers have the audio capabilities of a rock. No Audio() object. No Web Audio API. Nothing. You can't just do new Audio('goat.mp3').play() and call it a day, because there's no DOM for it to live in.

I found this out the way everyone finds out things in MV3: by writing the obvious code, watching it silently fail, and then spending 20 minutes wondering if I'd misspelled "goat."

Enter: the offscreen document

Chrome's answer to "service workers can't do X" for a bunch of X's (audio playback included) is the offscreen document API. It's exactly what it sounds like — a hidden HTML page that exists purely so your extension has something with a DOM, so it can do DOM things. In my case, playing an mp3 of a goat losing its mind.

The flow ends up looking like this:

service worker (background.js)
  → creates an offscreen document if one doesn't exist
  → sends it a message: "play the sound"
offscreen.html/offscreen.js
  → has an <audio> tag
  → actually plays the sound
  → closes itself when done

It's a little bit like hiring a stunt double because the main actor (your service worker) isn't allowed near water. The offscreen document does the wet work, then goes home.

Rough version of what that looks like in code:

// background.js
async function playGoatSound() {
  if (!(await chrome.offscreen.hasDocument())) {
    await chrome.offscreen.createDocument({
      url: 'offscreen.html',
      reasons: ['AUDIO_PLAYBACK'],
      justification: 'Playing a goat scream sound effect'
    });
  }
  chrome.runtime.sendMessage({ action: 'playSound' });
}

// offscreen.js
chrome.runtime.onMessage.addListener((msg) => {
  if (msg.action === 'playSound') {
    const audio = new Audio('sounds/goat.mp3');
    audio.play();
  }
});

Nothing exotic. But it took me embarrassingly long to figure out that "reasons: ['AUDIO_PLAYBACK']" is a required field and not optional flavor text, and that you genuinely cannot skip the offscreen document if you want sound out of a service worker. There's no secret shortcut.

The other MV3 gotcha: your background script forgets everything

Service workers also don't persist. Chrome can (and will) kill your background script whenever it feels like, which is a problem when your whole app is "wait N minutes, then do a thing." If your script gets shut down mid-wait, a regular setTimeout just... doesn't fire. It's gone. Chrome ate it.

This is what chrome.alarms is actually for — it's not just a nice API, it's the only way to reliably schedule something in the future when your background context can disappear at any moment. So Goat Alert ends up using two alarms:

One for "time to show the notification" (the random 5/10/15/20 min interval)
One for "15 seconds have passed, did they dismiss it? No? Ok, scream."

Both survive the service worker dying and waking back up, because chrome.alarms is backed by the browser itself, not by whatever fragile JS context happened to be running when you set the timer.

What I'd tell past me

Building this taught me that a huge chunk of "why is my simple Chrome extension so complicated" comes down to one thing: Manifest V3 assumes your background script is disposable, and designs everything around surviving that. Once you accept that and stop trying to keep long-lived state or objects (like an Audio instance) alive in the service worker, the actual APIs make sense. Offscreen documents for anything DOM-shaped, alarms for anything time-shaped.

Anyway. 100+ installs, people are enjoying it, so all efforts are worth it.

Give it a try, will put a smile on your face Goat Alert

I spent a week trying to intercept Slack push notifications from a Chrome extension. Here's why it's impossible.

M.Bilal Khan — Wed, 15 Jul 2026 18:55:52 +0000

After I published my last article about building a Chrome extension that speaks browser notifications aloud, a commenter asked a question I didn't have a good answer to.

He pointed out that a lot of web apps — Slack, Gmail, most modern tools — fire their notifications from a service worker via registration.showNotification(), not from the page's JavaScript context. My MAIN world override of window.Notification would never reach those.

He was right. And I told him I'd look into it.

I spent a week researching whether there was any way to close that gap. There isn't. But the reason why is more interesting than a simple "no."

Two ways a website can show you a notification

When a website sends you a browser notification, it can do it in one of two ways.

The first is the constructor path. The page's own JavaScript calls new Notification("You have a message") directly. This is common for in-tab alerts, real-time updates when you're actively on the site, or any notification triggered by something you just did.

The second is the push path. The browser receives a push event from the website's server, wakes up the website's service worker in the background, and the service worker calls self.registration.showNotification() from inside its own scope. This is what happens when Slack notifies you of a new message while the tab is closed or backgrounded. The page never runs. No page JavaScript ever fires.

My extension catches the first path. The MAIN world content script overrides window.Notification before any page code runs. But the service worker never touches the page's window. It has no window. It runs in a completely isolated thread, completely separate from the page, and calls showNotification on itself.

The override is never reached.

Why can't the extension reach the service worker?

This is the part that took me a week to fully accept.

Chrome extensions can inject content scripts into web pages. They can run code in the MAIN world or the ISOLATED world of a page. They can observe network requests, intercept navigations, and modify headers.

What they cannot do is inject code into a third-party website's service worker.

Service workers operate in a separate thread with no DOM, no window, and no connection to the page's JavaScript context. The Chrome Extensions API simply does not offer a mechanism to run extension code inside an arbitrary third-party service worker scope. It's a hard security boundary — and for good reasons. Allowing extensions to arbitrarily patch service workers for any website on the internet would be a significant attack surface.

So: the extension lives on the page side. The push notification lives on the service worker side. There is a wall between them.

Three approaches I investigated

I didn't accept "impossible" without looking for workarounds. Here's what I found.

Approach 1: Override ServiceWorkerRegistration.prototype.showNotification in the MAIN world

A page's JavaScript can call navigator.serviceWorker.ready.then(reg => reg.showNotification(...)). If you override ServiceWorkerRegistration.prototype.showNotification in the MAIN world, you'd intercept that pattern.

The problem: Slack's push notifications don't come from page JavaScript. They come from inside the service worker script itself, where it calls self.registration.showNotification(). The service worker runs in its own scope. The MAIN world prototype override doesn't reach there.

This approach catches one narrow pattern and misses the actual push notification path entirely.

Approach 2: chrome.debugger API with CDP

This is the most discussed workaround in the Chromium Extensions community. The chrome.debugger API gives an extension access to the Chrome DevTools Protocol. With CDP's Fetch.fulfillRequest command, you can intercept a network response — including a service worker JavaScript file — and modify it before the browser processes it. Inject your code into the SW script, and it runs inside the service worker scope.

This technically works. It is completely unusable for a consumer extension.

When you attach the debugger to any tab, Chrome displays a persistent banner at the top of the browser: "Chrome is being controlled by automated test software." This banner appears on every tab. It cannot be dismissed. It cannot be hidden by the extension. The only way to suppress it is to launch Chrome with --silent-debugger-extension-api, which is not something a real user would do.

For a Chrome Web Store extension that people install on their own machine, this approach would immediately look like malware. Ruled out.

Approach 3: declarativeNetRequest

Manifest V3's declarativeNetRequest API lets extensions block or redirect network requests. Could you redirect the Slack service worker script to a modified version?

No. declarativeNetRequest can block or redirect a request, but it cannot modify the response body. And even if it could redirect the service worker script URL, the replacement would need to be served from the same origin as the site — extensions can't serve content from slack.com.

What Firefox can do that Chrome can't

Here's where it gets interesting.

Firefox has an API called webRequest.filterResponseData(). It lets an extension intercept a network response and modify its body before the browser processes it. Applied to a service worker JavaScript file, you could inject code that runs inside the SW scope. That code could override self.registration.showNotification and intercept push notifications.

This capability exists in Firefox. It was advocated for by Giorgio Maone, the developer of NoScript, who needed exactly this kind of deep injection for a privacy tool.

Chrome removed blocking webRequest in MV3 and never added a filterResponseData equivalent. This is one of the more significant functional divergences between the two extension models post-MV3. Extension developers have raised it on the Chromium mailing lists. For now, it's a genuine gap.

What this means for Serious Notification

The extension works well for the constructor path — notifications fired from page JavaScript when a tab is active. For many apps and many use cases, that's most of their notification volume.

For pure push-via-service-worker notifications from backgrounded tabs — like Slack when you've minimised the window — the extension will miss them. I've added a Known Limitations section to the original article to reflect this honestly.

What would need to change for this to be solvable on Chrome? Some form of extension access to service worker scope — whether through a filtered response body API like Firefox's, or through a purpose-built notification interception hook in the Chrome Extensions API. Neither exists today.

If you want to see this change, the Chromium issue tracker is the place to make that case. I'm watching it.

In the meantime, if you want to try what's possible now:

🔗 https://chromewebstore.google.com/detail/hnaggblalhlbihfaegbknioadncpcged?utm_source=devto&utm_medium=content&utm_campaign=article2-sw

How I built a Chrome extension that speaks your notifications aloud — and the two Manifest V3 problems nobody warned me about

M.Bilal Khan — Tue, 07 Jul 2026 19:40:25 +0000

I counted how many times I glanced at a notification during a coding session last week.

Thirty-four times. Only four needed my attention.

So I built Serious Notification — a Chrome extension that speaks browser notifications aloud, but only when they match keywords you set. Type "failed" and only hear build errors. Type "urgent" and only hear what actually matters. Everything else stays silent.

It took a weekend to build the core. The two Manifest V3 architectural problems I hit along the way took longer to figure out. Neither of them is well documented. Here's both.

Problem 1: You can't intercept the Notification API in a regular content script

The plan seemed simple: listen for notifications, check them against keywords, speak the matching ones. A content script listening for notification events should work, right?

No.

Chrome's Notification constructor lives on window. When a website calls new Notification("You have a message"), it's using window.Notification in the page's own JavaScript context.

A standard Manifest V3 content script runs in what Chrome calls an ISOLATED world — a sandboxed environment that shares the DOM with the page but has its own separate JavaScript context. Your content script can read the DOM, but it cannot touch window.Notification on the actual page. By the time your script runs, the page's Notification constructor is completely separate from anything you can reach.

You can listen for a notification after it fires. You cannot intercept it before.

The fix: MAIN world content scripts

Manifest V3 added support for content scripts that run in the MAIN world. Set "world": "MAIN" in your manifest and your script runs directly in the page's JavaScript context — before any page code executes.

{
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["interceptor.js"],
      "world": "MAIN",
      "run_at": "document_start"
    }
  ]
}

Now you can override window.Notification before the page has a chance to use it:

const OriginalNotification = window.Notification;

window.Notification = function(title, options = {}) {
  window.dispatchEvent(
    new CustomEvent('__sn_notification__', {
      detail: { title, body: options.body || '' }
    })
  );
  return new OriginalNotification(title, options);
};

The catch: MAIN world scripts have no Chrome extension APIs

Here is the problem with MAIN world scripts. They run in the page context, which means:

No chrome.storage — you cannot read the user's saved keywords
No speechSynthesis — you cannot speak the notification aloud
No extension APIs at all

You are in the page's world. Chrome's extension APIs are not available there.

So you need two scripts.

The bridge

Script 1 (interceptor.js) runs in the MAIN world. It overrides window.Notification and fires a custom DOM event when a notification arrives.

Script 2 (content.js) runs in the ISOLATED world. It has full access to chrome.storage and speechSynthesis. It listens for the custom event:

window.addEventListener('__sn_notification__', async (e) => {
  const { title, body } = e.detail;
  const data = await chrome.storage.local.get(['enabled', 'keywords', 'speed']);

  if (!data.enabled) return;

  const keywords = data.keywords || [];
  const text = `${title} ${body}`.toLowerCase();
  const match = keywords.some(kw => text.includes(kw.toLowerCase()));

  if (match || keywords.length === 0) {
    const utterance = new SpeechSynthesisUtterance(`${title}. ${body}`);
    utterance.rate = data.speed || 1.0;
    speechSynthesis.speak(utterance);
  }
});

Two scripts. One custom DOM event as the bridge. The MAIN world intercepts, the ISOLATED world decides.

Problem 2: Chrome showed a "read and change all your data on all websites" warning at install

The extension needs to inject on every page — that's legitimate, since you don't know which tab will fire a notification. So <all_urls> host access is genuinely required.

But I was declaring it as a required permission in manifest.json:

"content_scripts": [
  {
    "matches": ["<all_urls>"],
    ...
  }
]

This caused Chrome to show the scariest possible install warning before users had any reason to trust the extension. I was watching my analytics and seeing a 33% uninstall rate. Some of that was almost certainly people bouncing at the permission screen, before they ever heard the extension speak a single word.

The fix: optional host permissions

Manifest V3 supports optional_host_permissions. Move <all_urls> there instead of requiring it at install:

{
  "permissions": ["storage", "scripting"],
  "optional_host_permissions": ["<all_urls>"]
}

Then register content scripts dynamically at runtime using chrome.scripting.registerContentScripts(), only after the user explicitly grants the permission:

// background.js
chrome.permissions.onAdded.addListener(async (permissions) => {
  if (permissions.origins?.includes('<all_urls>')) {
    await chrome.scripting.registerContentScripts([
      {
        id: 'interceptor',
        matches: ['<all_urls>'],
        js: ['interceptor.js'],
        world: 'MAIN',
        runAt: 'document_start',
      },
      {
        id: 'content',
        matches: ['<all_urls>'],
        js: ['content.js'],
        runAt: 'document_start',
      }
    ]);
  }
});

In the popup, show a "Turn on to hear alerts" button that triggers the permission request:

chrome.permissions.request({ origins: ['<all_urls>'] });

The result: the Chrome Web Store install dialog now shows Storage only. No broad-access warning. The scary prompt only appears when the user explicitly clicks "Turn on" inside the popup — after they have already installed the extension and understand what it does.

One edge case: updating from a version that required the permission

When you update an extension and a previously required permission becomes optional, Chrome removes it from the user's granted set. Existing users lose host access silently on update — the extension just stops working with no explanation.

The fix: fire a native notification immediately after update using the notifications permission:

chrome.runtime.onInstalled.addListener(({ reason }) => {
  if (reason === 'update') {
    chrome.notifications.create('update-notice', {
      type: 'basic',
      iconUrl: 'icon.png',
      title: 'Serious Notification — One quick step needed',
      message: 'We improved how permissions work. Open the extension and click "Turn on" to re-enable.',
      requireInteraction: true,
    });
  }
});

Silent failure is the worst outcome for retention. If something breaks on update, tell the user immediately and tell them exactly what to do.

What I built

Serious Notification speaks Chrome notifications aloud when they match keywords you set. Free, no account, works offline. Just shipped v0.2.0 with the optional permissions model above.

If you're building Chrome extensions and hit either of these problems — happy to answer questions in the comments. The MAIN world injection in particular has some edge cases around static property copying (permission, requestPermission) that took me a while to get right.

🔗Serious Notification - Live Chrome WebStore

Known Limitations

This approach only intercepts notifications fired via the Notification constructor in the page's JavaScript context.

Notifications fired from a service worker via registration.showNotification() — which is the path used by background push notifications in apps like Slack — bypass the MAIN world override entirely. The service worker runs in its own scope and never touches the page's window.

Chrome's extension model does not currently offer a hook into arbitrary third-party service workers, so this gap cannot be closed with the current architecture.

The extension works well for in-tab notifications and apps that call the constructor directly from page scripts. For pure push-via-service-worker apps when the tab is backgrounded, it will miss notifications.