DEV Community: Omar Afifi

The Ghost in the View Transitions API: A Bizarre Debugging Saga with Google AI 👻

Omar Afifi — Fri, 07 Aug 2026 17:35:35 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

🎨 Project Overview

While working on a major upgrade for my personal portfolio (Check it out here: Live Portfolio Link | GitHub Repo), I built a feature called the Theme Showcase. When a user first loads the homepage, a slick View Transitions API animation sweeps across the screen, temporarily switching the site to one of my custom showcase themes (like "Obsidian" or "Midnight"), before gracefully sweeping back to their chosen default theme. It was a 1.7-second "Wow Effect" designed to show off the site's dynamic color system.

🐛 Bug Fix

Soon after deploying, I noticed a terrifying, chaotic bug. Sometimes, I would open the website and quickly switch to another tab to check an email, or minimize the browser window completely. When I switched back...

Instead of my beautiful default theme, the website was permanently stuck on one of the other showcase themes! The animation had frozen mid-way, leaving the site in an awkward intermediate state. While the website was still fully functional and I could manually fix it by selecting my original theme from the dropdown menu, it was a terrible first impression for a professional portfolio. It was as if a ghost had possessed the CSS.

My first instinct? Smash the refresh button. Refreshing would actually fix the glitch and play the animation perfectly—but only if I stayed patiently on the tab and watched it finish! If I refreshed and immediately switched tabs again, the ghost would return.

💻 Code

Here is the exact code change we made to exorcise the ghost. (You can view the full fix in this GitHub Commit)

The Buggy Code (Before):

const transition = document.startViewTransition(() => {
  html.setAttribute('data-theme', theme);
});

// If the browser aborts the transition here, the Promise rejects and execution halts forever!
transition.ready.then(() => {
  const animation = document.documentElement.animate(/* ... */);
  animation.onfinish = resolve;
});

The Bulletproof Code (After):

let isCancelled = false;

// 1. Gracefully handle tab switching
const handleVisibility = () => {
  if (document.hidden) {
    isCancelled = true;
    html.setAttribute('data-theme', originalTheme); // Instantly restore
    document.removeEventListener('visibilitychange', handleVisibility);
  }
};
document.addEventListener('visibilitychange', handleVisibility);

// 2. Bulletproof the View Transition Promise
return new Promise(resolve => {
  try {
    const transition = document.startViewTransition(() => {
      if (!isCancelled) html.setAttribute('data-theme', theme);
    });

    transition.ready.then(() => {
      if (isCancelled) return resolve();

      const animation = document.documentElement.animate(/* ... */);
      animation.onfinish = resolve;
      animation.oncancel = resolve;

    }).catch(() => {
      // THE MAGIC FIX: If the browser aborts the transition (background tab), resolve immediately!
      resolve();
    });
  } catch (error) {
    // Fallback if startViewTransition throws synchronously
    if (!isCancelled) html.setAttribute('data-theme', theme);
    setTimeout(resolve, duration);
  }
});

🛠️ My Improvements

My technical approach to resolving this was two-fold:

State Management on Visibility Change: I added a visibilitychange event listener. If the user navigates away, we instantly cancel the sequence and forcefully restore the original theme to prevent intermediate states.
Error Handling for the View Transitions API: The core issue was that browsers forcefully abort the startViewTransition when a tab is hidden to save battery. This caused the transition.ready Promise to reject. Because there was no .catch() block, the unhandled rejection caused the entire async sequence to hang permanently. By wrapping the transition in a try/catch and adding a .catch(() => resolve()) handler, we guarantee that the execution flow always continues gracefully, even if the browser interrupts it.

🤖 Best Use of Google AI

I couldn't figure out why this bug was only happening sometimes, and no errors were showing up in the console. So, I turned to my trusty pair programmer: Google AI integrated within the Antigravity IDE.

What's really cool about my workflow is that I chat with my AI agent completely casually in Arabic. It feels incredibly natural, like brainstorming with a senior engineer sitting right next to me. But debugging with AI isn't always a "one-shot" magic trick. It’s an iterative journey.

(Note: I interact with my AI agent natively in Arabic! For this post, I have translated our debugging conversation. I've kept the original Arabic screenshots on hand just in case the judges want to see them!)

Phase 1: The Misdiagnosis

At first, I explained the symptoms loosely to the AI:

Me: "I have another issue. Sometimes the theme changes to dark suddenly and weird things happen. I don't know what it is."

The AI analyzed the code and thought the animation feature itself was the bug (assuming it was just annoying the user). So, it enthusiastically offered a "fix" by completely disabling the showcase animation function!

I had to intervene and correct its assumption:

Me: "Bro, no, you misunderstood! The animation at the beginning is natural and fine. What's NOT natural is leaving the website open, going to another tab, and coming back to find it permanently stuck on a new theme."

Phase 2: The Deep Dive

Once I steered the AI in the right direction, it immediately dug into the mechanics of tab-switching. It realized that modern browsers aggressively pause requestAnimationFrame when a tab goes to the background.

The AI wrote the visibilitychange listener, but then we ran into another issue when I was testing it locally with my dev server.

Me: "Why does it open on a different theme every time I hit save in my editor? I have to manually refresh to get my original theme back."

The AI assumed I was just being impatient with the 1.7-second animation delay during live-reloads:

AI: "When you save, the dev server refreshes the page. The animation starts, switches to the showcase theme, and then returns. You are just manually refreshing before the 1.7 seconds finish, trapping yourself in a loop! Just wait 1.7 seconds."

Phase 3: The "Aha!" Moment

I knew I wasn't just being impatient. The UI was literally getting stuck. I pushed the AI to look deeper:

Me: "Bro, I'm not rushing. I open it, find it on a new theme, and it is completely STUCK on it. This causes problems if the user goes to another tab. Focus well, think carefully, and take your time."

That’s when the AI hit the absolute jackpot.

It didn't just hand me a snippet of code; it provided a masterclass on browser mechanics. It analyzed the View Transitions API behavior and uncovered the true root cause: to save battery and resources, modern browsers aggressively throttle or abort animations when a tab is hidden. This aggressive optimization was causing the transition.ready promise to reject silently, which hung the entire async sequence because it lacked a .catch() block.

I initially asked the AI if we could just "force" the browser to play the animation in the background anyway. Instead of blindly agreeing, the AI pushed back and explained the engineering philosophy behind this: it’s a hard performance constraint built into modern browsers. You can't fight the browser's resource management. Instead, it taught me the "Best Practice": monitor the tab's state (which led to the visibilitychange listener), gracefully catch any forced abortions (the .catch() fix), instantly restore the original UI, and respect the browser's rules.

Thanks to Google AI in the Antigravity IDE, I didn't just fix a bug—I learned exactly why the browser was behaving that way under the hood. It transformed a frustrating debugging session into a profound learning experience about advanced JavaScript APIs and browser rendering mechanics. This is exactly what the future of pair programming looks like!

Reviving Daphq: How I Built an Open-Source, Bare-Metal File Transfer Engine Solo with GitHub Copilot

Omar Afifi — Wed, 27 May 2026 21:12:32 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Daphq is a robust, open-source, cross-platform file transfer application engineered entirely from scratch to deliver hardware-saturating speeds over local area networks (LAN), Wi-Fi, and Mobile Hotspots.

As a solo developer, I built Daphq to solve a personal frustration: the bloated overhead, privacy concerns, and artificial speed limits of conventional HTTP-based or cloud-reliant file-sharing tools. Daphq bypasses the standard Web/REST layer completely, establishing direct, bare-metal TCP Sockets (Socket & ServerSocket) with SocketOption.tcpNoDelay enabled to eliminate protocol latency and push network hardware to its absolute physical limits.

Built using Flutter (Dart) for seamless cross-platform performance (currently native on Android and Windows), Daphq features a highly decoupled architecture using the BLoC/Cubit pattern, multi-gigabyte memory protection guards, and background network synchronization, and intelligent user guidance.

Demo

The entire project is completely open-source and free to review, fork, or run locally:

🌐 Official Product Website: omar-afifi.com/daphq/
💻 GitHub Repository: github.com/omarafifi-cse/daphq

Screenshots in Action

Android UI Layout	Windows Desktop Experience

Clean, robust mobile layout with active background service tracking.	Fluid, modern, and highly responsive desktop experience.

The Comeback Story

Daphq was born under high pressure, but after shipping the bare bones of version v1.0.0, it was essentially abandoned in my local repository directory. The project had immense raw speed potential, but it was plagued by architectural gaps, clunky user workflows, and high-stress bugs that made it unviable for everyday users.

The GitHub Finish-Up-A-Thon Challenge was the exact catalyst I needed to dust off the codebase and transform it from a fragile command-like utility into a highly polished, resilient consumer application (v2.3.0).

The Deep Evolution: v1.0.0 vs. v2.3.0

Here is exactly how the architecture and UX matured over the course of this challenge:

Discovery, Connectivity & Resilience:
- Before (v1.0.0): Zero automation. Users manually typed cryptic IPv4 addresses, and any connection drop required a full app restart.
- After (v2.3.0): A custom UDP Auto-Discovery Service with an integrated watchdog. Backed by a rewritten, Bulletproof Receiver Engine, the app instantly bounces back if a connection drops or cancels abruptly—never getting stuck on "Connecting...".
User Interface, Fluidity & Storage:
- Before (v1.0.0): Rigid layouts, storage bloat from cached files, and main-thread hangs (UI freezing) when selecting large directories.
- After (v2.3.0): A unified dashboard anchored by an "Orbital Radar" and Non-Blocking Async UI. Sharing 1,000+ files is now buttery smooth with zero lagging. Plus, it features Persistent Folders to permanently remember your download path and Smart Auto-Cleaning to wipe cache bloat automatically.
Smart User Guidance:
- Before (v1.0.0): Users suffered from slow transfers due to ISP router bottlenecks without knowing why.
- After (v2.3.0): Integrated a real-time speed monitor that triggers a Smart Hotspot Guide if speeds drop below 2.0 MB/s, guiding users to utilize 5GHz direct hotspots for up to 10x faster speeds.
Memory Safety & Disk I/O Flow Control:
- Before (v1.0.0): High risk of Out-Of-Memory (OOM) crashes when streaming multi-gigabyte files due to unthrottled asynchronous disk reads.
- After (v2.3.0): Implemented zero-copy byte slicing (Uint8List.sublistView) and Natural Socket Backpressure (await socket.flush()). Daphq now self-throttles to match real-time network speeds, saving physical RAM.
Deep System-Wide Integrations:
- Before (v1.0.0): Isolated sandboxed app.
- After (v2.3.0): Deployed deep OS hooks, including native Android Share Menu entry and background execution. On Android, Instant Wake-up intelligently turns on the screen for incoming requests. On Windows, the Context Menu Shell Extension was completely rebuilt to be unbreakable, eliminating all File Explorer hangs.

My Experience with GitHub Copilot

As a solo developer, you are the software architect, the UI designer, the QA technician, and the DevOps engineer all at once. Time is your greatest bottleneck. Throughout this sprint, GitHub Copilot didn’t just autocomplete lines of boilerplate—it acted as an incredibly knowledgeable senior engineering peer, unlocking complex architectural problems.

Here are three distinct breakthroughs where GitHub Copilot completely changed the trajectory of the project:

1. Solving the Math of the Orbital Radar UI

I wanted the home dashboard to feel alive with an evenly distributed, deterministic "Orbital Radar" circle showing available peer devices. Distributing dynamic widgets symmetrically on a circular plane without them overlapping can quickly become a headache.

Copilot's Intervention: By providing Copilot with my layout boundaries and device state arrays, it instantly mapped out the exact trigonometric distribution math using cos and sin over a mapped index. Furthermore, it proactively recommended assigning unique ValueKeys to the dynamically generated widgets, preventing unnecessary re-paints and maximizing rendering performance on low-end hardware.

2. Eliminating the Windows FFI Mutex Deadlock

A critical, highly frustrating platform bug on Windows caused Daphq to accidentally trigger background execution loops whenever a user performed completely unrelated right-click shell actions elsewhere in the OS. Worse, exiting the app caused a stubborn Dart VM deadlock.

Copilot's Intervention: I explained the process conflict to Copilot. It guided me through structuring a clean, platform-specific local session mutex check. When it came to bypassing the Dart VM shutdown hang, Copilot instantly generated the safe native Windows FFI code block to execute a clean ExitProcess command, killing the deadlocks instantly and safely.

3. Engineering Flow-Safe Dynamic Streaming Buffer

To stop aggressive disk-read bursts from triggering Out-Of-Memory exceptions, I needed a way to throttle file streams smoothly based on network capacity.

Copilot's Intervention: Copilot analyzed my asynchronous data-sync loop and suggested transitioning away from arbitrary chunk delay timers. It helped refactor the code to explicitly await socket.flush() based on monitored bytesBuffered thresholds. The result was an automated backpressure loop that scales throughput up or down safely based on real-time network conditions.

// Standard path for larger files: stream in chunks
final reader = fileToRead.openRead();
try {
  await for (var chunk in reader) {
    if (_isCancelled) throw "Transfer Cancelled";
    try {
      socket.add(chunk);
      bytesBuffered += chunk.length;

      if (bytesBuffered >= AppConstants.socketFlushThresholdBytes) {
        // Awaited flush: provides backpressure so the disk read loop
        // runs at network speed, not disk speed. Without this, a fast
        // UFS device would read the entire file in <500ms before any
        // onUpdate fires, causing the snapshot/stutter UI bug.
        await socket.flush();
        bytesBuffered = 0;
      }
    } catch (e) {
      if (_isCancelled) throw "Transfer Cancelled";
      if (e is SocketException || e.toString().contains("reset by peer")) {
        throw "Receiver disconnected during transfer.";
      }
      rethrow;
    }

    // ... UI update logic 
  }
}

The Verdict

Building Daphq independently meant encountering dozens of architectural edge cases. Having GitHub Copilot available to instantly generate platform-specific guards, analyze multi-threaded socket behavior, and handle tedious Win32 registry bindings allowed me to focus on what mattered most: delivering a breathtakingly fast file transfer engine.

Daphq went from an unpolished repository artifact to a production-grade open-source engine capable of hitting 80-90 MB/s (~93% bandwidth saturation) over a standard local Wi-Fi 5 connection. I couldn't be prouder of how this challenge ended.