cocozq Hexo https://cocozq.site/ All rights reserved 2026, cocozq Indie Developer cocozq 2026-10-04T01:45:55.578Z cocozq In a Tauri v2 + React desktop app, right-clicking anywhere pops up the native Chromium context menu — Back, Forward, Reload, View Source, Inspect, and friends.

That shatters the native feel of the app, leaks implementation details (it’s a WebView under the hood), and conflicts with the app’s own custom context menus — transfer panel actions, terminal menus, and the like.

Root Cause

A Tauri frontend runs inside a WebView (WebKitGTK on macOS/Linux, WebView2 / Edge Chromium on Windows). A WebView is essentially an embedded browser, so its default behavior includes:

  1. Right-click fires the browser’s contextmenu event → native menu pops up
  2. Unlike Electron, there is no global config option to turn this off
  3. Every DOM element can become a right-click trigger point

Why CSS Can’t Fix It

1
2
/* ❌ CSS cannot stop the contextmenu event */
* { user-select: none; }

Properties like user-select only affect text selection — they cannot prevent the contextmenu event from firing or the browser menu from appearing. This has to be solved with JavaScript event handling.

The Fix

Core idea: intercept once at the app root

Attach an onContextMenu handler on the outermost root element of the React tree and call e.preventDefault() to suppress the browser default. Thanks to React’s event bubbling, no matter which child component gets right-clicked, the event bubbles up to the root and gets intercepted.

1
2
3
4
5
6
7
8
9
10
11
12
// App.tsx — application entry
export default function App() {
  return (
    <div className="app-layout" onContextMenu={(e) => e.preventDefault()}>
      {/* everything in the app */}
      <Sidebar />
      <MainContent />
      <ToolPanel />
      {/* ... all dialogs, modals, panels ... */}
    </div>
  );
}

One line of code covers the entire app.

Key advantages

AspectDetail
CoverageEvery existing page/component — and every future one
Child-friendlyChild components can still handle contextmenu themselves for custom menus
Low maintenanceNo need to sprinkle handlers component by component
Zero perf costIt’s just a trivial event interceptor

Handling multi-window apps

If the app has standalone windows (e.g. a detached SFTP file-manager window), each window has its own render tree and root element, so each needs its own handler:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// App.tsx — main window
return (
  <div className="app-layout" onContextMenu={(e) => e.preventDefault()}>
    {/* main window content */}
  </div>
);

// App.tsx — standalone SFTP window (another return branch)
if (isSftpWindow && sftpWindowSessionId) {
  return (
    <div className="sftp-standalone-window" onContextMenu={(e) => e.preventDefault()}>
      <SftpBrowser sessionId={sftpWindowSessionId} />
    </div>
  );
}

Coexisting with custom context menus

Regions that need their own right-click menu (file lists, table rows) can bind onContextMenu normally in the child component:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// TransferPanel.tsx — custom context menu for the transfer list
<table>
  {transfers.map(transfer => (
    <tr
      key={transfer.id}
      // custom context menu handler
      onContextMenu={(e) => {
        e.preventDefault();        // suppress the browser menu
        e.stopPropagation();       // optional: stop bubbling to the root
        showCustomMenu(e, transfer); // show the custom menu
      }}
    >
      ...
    </tr>
  ))}
</table>

{/* custom context menu component */}
<TransferContextMenu visible={...} position={...} onClose={...}>

Note: since the root already called e.preventDefault(), the one in the child is redundant but harmless. If you want only specific regions to suppress the browser menu (rather than globally), use e.stopPropagation() in the child to keep the event from bubbling further.

Full Implementation Checklist

Step 1: Intercept at the main-window root

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// src/App.tsx
return (
  <SyncScrollProvider>
    <div className="app-layout" onContextMenu={(e) => e.preventDefault()}>
      <NotificationToasts />
      <TitleBar />
      <div className="app-body">
        <Sidebar />
        <div className="app-main">
          {/* ... */}
        </div>
      </div>
    </div>
  </SyncScrollProvider>
);

Step 2: Intercept at every standalone window root

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// src/App.tsx — every standalone return branch needs it
if (isSftpWindow) {
  return (
    <div className="sftp-standalone-window" onContextMenu={(e) => e.preventDefault()}>
      <SftpBrowser />
    </div>
  );
}

if (isOtherStandaloneWindow) {
  return (
    <div className="other-window-root" onContextMenu={(e) => e.preventDefault()}>
      {/* ... */}
    </div>
  );
}

Step 3: Verify coverage

Right-click-test each of these areas one by one:

  • Home / welcome panel
  • Host list sidebar
  • Terminal area
  • Settings toolbox (all sub-tabs)
  • SFTP file browser (embedded and standalone window modes)
  • File transfer panel
  • Add-host dialog
  • Quick-connect dialog
  • Snippets panel
  • Config file picker dropdown
  • About dialog
  • Every other popup / modal

Common Misconceptions

Myth 1: Adding it to one component is enough

Wrong — dead wrong. New pages and dialogs get added all the time and are easy to miss. Solve it at the architecture level with unified handling at the root element.

Myth 2: CSS can solve it

1
2
3
4
/* ❌ This does nothing */
body {
  -webkit-context-menu: none;
}

The -webkit-context-menu property is deprecated and unsupported by modern WebViews. JavaScript event handling is required.

Myth 3: It breaks copy/paste menus in inputs

No. e.preventDefault() only suppresses the native browser menu from popping up.

  • Text editing in <input> / <textarea> / [contenteditable] is unaffected
  • If you want to keep the native copy/paste/spellcheck menu inside inputs, add a condition:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<div
  onContextMenu={(e) => {
    // let inputs keep the native browser menu
    const target = e.target as HTMLElement;
    if (
      target.tagName === 'INPUT' ||
      target.tagName === 'TEXTAREA' ||
      target.isContentEditable
    ) {
      return; // don't suppress
    }
    e.preventDefault();
  }}
>

Myth 4: Tauri has a config switch for this

As of Tauri v2, there is no built-in option to disable the WebView context menu. It’s WebView-level behavior and must be handled in the web frontend layer.

Going Further: Fine-Grained Control

If the app needs tiered policies (different rules per region), use a Context + HOC approach:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// src/context/ContextMenuContext.tsx
const ContextMenuContext = createContext<{
  disable: boolean;
}>({ disable: true });

// Browser menu disabled by default; sub-regions can opt back in
export function ContextMenuProvider({ children }: { children: React.ReactNode }) {
  return (
    <ContextMenuContext.Provider value={{ disable: true }}>
      <div onContextMenu={(e) => {
        if (e.currentTarget.getAttribute('data-native-menu') !== 'true') {
          e.preventDefault();
        }
      }}>
        {children}
      </div>
    </ContextMenuContext.Provider>
  );
}

For most Tauri apps, though, one preventDefault() at the root is plenty — no need to over-engineer it.

Summary

ItemDetail
ProblemTauri/WebView apps pop the native browser menu on right-click
CauseDefault WebView behavior, no global switch to turn it off
FixRoot element onContextMenu={(e) => e.preventDefault()}
Cost1 line of code
CoverageThe whole app, including pages added in the future
CaveatMulti-window apps need it on each window’s root element

Applies to Tauri v1/v2 with React, Vue, Svelte, or any frontend framework.

]]> https://cocozq.site/2026/10/04/disable-browser-context-menu-in-tauri/ 2026-10-03T16:00:00.000Z In a Tauri v2 + React desktop app, right-clicking anywhere pops up the native Chromium context menu — Back, Forward, Reload, View Source, Inspect, and friends.

That shatters the native feel of the app, leaks implementation details (it’s a WebView under the hood), and conflicts with the app’s own custom context menus — transfer panel actions, terminal menus, and the like.

]]> Completely Disabling the Native Browser Context Menu in Tauri Apps 2026-10-04T01:45:55.578Z cocozq

While building a screenshot tool, I ran into a series of nasty problems: pressing ESC to cancel a capture yanked the main window to the foreground, popup combo boxes from apps like PowerToys couldn’t be detected or captured, and the image shown on the capture overlay didn’t match the image actually captured. These issues span Windows window management, GDI screen capture, Tauri’s event system, and browser image rendering. This post records the full debugging and fixing process — hopefully it helps fellow developers hitting similar walls.

Issue 1: Main Window Jumps to the Foreground After ESC-Cancel

Symptom

Pressing ESC to cancel a screenshot unexpectedly brought the app’s main window to the foreground and gave it focus.

Root cause

The cancel logic explicitly called show() and set_focus() on the main window:

1
2
3
// inside cancel_capture
let _ = main_window.show();
let _ = main_window.set_focus();

The intent was to restore the main window — but users expect a cancel to quietly return the app to the tray, not to steal focus.

Fix

Remove the show/focus calls from the cancel path; only destroy the capture overlay window:

1
2
3
4
5
6
fn cancel_capture() {
    // only destroy the capture window, don't show/focus the main window
    if let Some(window) = app.get_webview_window("capture") {
        let _ = window.destroy();
    }
}

Takeaways

  • Desktop utility apps should respect the user’s focus state — never steal focus on a cancel action
  • Tray-resident apps should stay silent after a cancel

Issue 2: PowerToys Combo Box Can’t Be Detected or Captured

Symptom

PowerToys’ “Image Resizer” window has a dropdown list box. Other screenshot tools (QQ Screenshot, ShareX) detect and capture it just fine — ours couldn’t see it at all.

Debugging

Step 1: Window enumeration diagnostics

First, verify whether window enumeration can even see the combo box. Write a diagnostic script that enumerates all visible windows with EnumWindows:

1
2
3
Window title: ""  Class: "ComboBox"  Style: 0x96000000  ExStyle: 0x00000088
  Position: (993, 422)  Size: 575x489
  Owner PID: 12345

Key findings:

  1. The combo box is a standalone window — not a child control of the main window, but an independent top-level window
  2. Its title is empty — it was being filtered out by the existing title.is_empty() check
  3. Its extended style contains WS_EX_TOOLWINDOW and WS_EX_NOACTIVATE — excluded by the style filter

Step 2: Drop the filters, add a fallback

1
2
3
4
5
6
7
8
9
10
// Before: filtering out empty-title / special-style windows
if title.is_empty() { continue; }
if ex_style & WS_EX_TOOLWINDOW != 0 { continue; }

// After: fall back to class name for empty titles, no style filtering
let display_title = if title.trim().is_empty() {
    class_name.clone()  // use the window class as the title
} else {
    title.clone()
};

Step 3: Merge same-process windows

The combo box window and the main window belong to the same process but enumerate as two separate windows. Users expect clicking to highlight the whole region (main window + combo box), not each piece separately.

Implement same-process window merging:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Use GetAncestor to find the root window; merge overlapping or
// adjacent windows from the same process
for i in 0..raw_windows.len() {
    if used[i] { continue; }
    let root_i = GetAncestor(hwnd_i, GA_ROOT);
    let mut merge_rect = Rect::from(hwnd_i);

    for j in (i+1)..raw_windows.len() {
        if used[j] { continue; }
        if pid_j == pid_i && (root_j == root_i) {
            let rect_j = Rect::from(hwnd_j);
            if merge_rect.overlaps_or_near(&rect_j, threshold=50) {
                merge_rect = merge_rect.union(&rect_j);
                used[j] = true;
            }
        }
    }
    // build the window entry from the merged rect
}

Merge result: main window (1014,562 535x437) + combo box (993,422 575x489) → merged (993,422 575x577)

Takeaways

  • On Windows, many popup controls (combo boxes, popup menus, tooltips) are standalone windows, not child controls of their parent
  • Don’t over-filter during window enumeration — empty titles and special styles must not be exclusion criteria
  • Consider merging multiple windows from the same process, or the UX suffers
  • Use GetAncestor(hwnd, GA_ROOT) to tell whether windows belong to the same top-level tree

Issue 3: The Combo Box Collapses When Capturing

Symptom

With the combo box expanded, pressing the screenshot hotkey instantly collapsed it — the captured image never showed the dropdown contents.

Root cause

In the capture flow, hiding the main window changed focus, which made the combo box lose focus and close:

1
Hotkey fired → hide main window (focus change) → combo box loses focus, closes → capture → combo box missing

Fix: reorder the operations

Capture first, hide windows after:

1
Hotkey fired → capture immediately (synchronous) → hide main window → show overlay

Also add the WS_EX_NOACTIVATE style to the main window so showing/hiding it never steals focus:

1
2
3
4
5
6
7
8
9
10
fn hide_main_window(app: &AppHandle) {
    if let Some(window) = app.get_webview_window("main") {
        let hwnd = window.hwnd().unwrap().0 as *mut std::ffi::c_void;
        unsafe {
            let ex_style = GetWindowLongPtrW(hwnd, GWL_EXSTYLE);
            SetWindowLongPtrW(hwnd, GWL_EXSTYLE, ex_style | WS_EX_NOACTIVATE.0);
        }
        let _ = window.hide();
    }
}

Takeaways

  • A screenshot tool must capture before any window state changes
  • The WS_EX_NOACTIVATE style lets windows show/hide without grabbing focus
  • Global hotkey handling should capture synchronously — avoid async delays that allow focus to shift

Issue 4: GDI Capture Misses Layered Windows

Symptom

Capturing with the xcap library dropped layered-window content such as the combo box — while ShareX captured it fine.

Root cause

xcap’s underlying screen-capture call doesn’t set the CAPTUREBLT flag. Windows’ BitBlt excludes layered windows by default; you must pass CAPTUREBLT to include them.

Fix: implement GDI capture with CAPTUREBLT

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
pub fn gdi_capture_all_monitors() -> Result<RgbaImage, String> {
    unsafe {
        let vx = GetSystemMetrics(SM_XVIRTUALSCREEN);
        let vy = GetSystemMetrics(SM_YVIRTUALSCREEN);
        let vw = GetSystemMetrics(SM_CXVIRTUALSCREEN);
        let vh = GetSystemMetrics(SM_CYVIRTUALSCREEN);

        let hdc_screen = GetWindowDC(GetDesktopWindow());
        let hdc_mem = CreateCompatibleDC(hdc_screen);
        let h_bitmap = CreateCompatibleBitmap(hdc_screen, vw, vh);
        SelectObject(hdc_mem, h_bitmap as *mut c_void);

        // Key: SRCCOPY | CAPTUREBLT ensures layered windows are captured
        let result = BitBlt(
            hdc_mem, 0, 0, vw, vh,
            hdc_screen, vx, vy,
            SRCCOPY | CAPTUREBLT,  // 0x00CC0020 | 0x40000000
        );

        // ... GetDIBits to fetch pixel data ...
    }
}

The alpha channel trap

The 32-bit pixel data returned by GetDIBits has an undefined alpha channel (usually 0). Save it straight to a 32-bit BMP and render it in a browser, and every pixel turns transparent!

1
2
3
4
5
// Must force alpha to 255 (opaque)
for chunk in buffer.chunks_exact_mut(4) {
    chunk.swap(0, 2);  // BGRA → RGBA
    chunk[3] = 255;     // force alpha = opaque
}

Takeaways

  • Windows BitBlt needs the CAPTUREBLT flag to capture layered windows
  • GetDIBits alpha is untrustworthy — set it to 255 manually
  • Prefer PNG over BMP for saved screenshots to avoid the browser’s 32-bit BMP alpha rendering quirks

Issue 5: Overlay Shows a Different Image Than What Was Captured (the Nastiest One)

Symptom

The image saved to disk contained the combo box, but the image displayed on the capture overlay had a blank hole where the combo box should be. The highlight rectangle correctly covered the combo box region — the pixels were just missing.

Debugging

The most time-consuming issue, spanning several links of the frontend-backend data sync chain.

Initially the screenshot data traveled over Tauri events:

1
2
3
4
5
6
7
// Backend: fire the event
app.emit("capture-ready", &result)?;

// Frontend: listen for it
listen<CaptureResult>("capture-ready", (event) => {
    setImageSrc(convertFileSrc(event.payload.path));
});

Problem: the capture-ready event fired right after the capture window’s show() — but the webview might not have finished loading and the listener wasn’t registered yet, so the event was lost.

Switched to letting the frontend pull the data via a Tauri command — but start_capture used take_pending_capture(), which consumed the pre-cached data:

1
2
3
4
5
6
7
// inside start_capture
let result = take_pending_capture();  // consumed the data!

// when the frontend later calls get_cached_capture
pub fn get_cached_capture() -> Option<CaptureResult> {
    pending.take()  // already consumed — returns None!
}

The frontend got nothing, fell back to the possibly-missed event, and ended up loading the wrong image (probably a stale cached screenshot).

Even with the correct file path in hand, 32-bit BMP alpha can render wrong regions in the browser.

Final fix

1. Backend: peek instead of take — keep the data available for the frontend

1
2
3
4
5
6
7
8
// in start_capture: peek, don't consume
let result = peek_pending_capture();

// frontend command: peek as well
#[tauri::command]
pub fn get_cached_capture() -> Option<CaptureResult> {
    PENDING_CAPTURE.lock().map(|p| p.clone()).unwrap_or(None)
}

2. Frontend: polling + event listening as a double safety net

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
useEffect(() => {
    let gotData = false;
    let pollInterval: number | null = null;

    const tryGetData = () => {
        if (gotData) return;
        invoke<CaptureResult | null>("get_cached_capture")
            .then((result) => {
                if (result) {
                    gotData = true;
                    setCaptureResult(result);
                    setImageSrc(convertFileSrc(result.path));
                    if (pollInterval) clearInterval(pollInterval);
                }
            });
    };

    // try immediately + poll
    tryGetData();
    pollInterval = setInterval(tryGetData, 50);
    setTimeout(() => { if (pollInterval) clearInterval(pollInterval); }, 2000);

    // also listen for the event as backup
    listen<CaptureResult>("capture-ready", (event) => {
        if (!gotData) { /* ... */ }
    });
}, []);

3. Save screenshots as PNG

1
2
3
// Before: save_bmp_fast(&full_image, &path)?;
// After:
full_image.save(&path).map_err(|e| format!("PNG save failed: {}", e))?;

Takeaways

  • Tauri events are not guaranteed delivery: if the webview hasn’t finished loading, events get dropped. Critical data needs a command-based pull path too
  • Be careful with data consumption: take (consume) vs peek (inspect) have different semantics — use peek in multi-consumer scenarios
  • Polling + events as a double safety net: for critical data, the frontend should use both polling and event listeners so nothing gets lost
  • BMP is treacherous in browsers: 32-bit BMP alpha can be misinterpreted — use PNG

Overall Architecture After the Fixes

The capture flow now looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1. Hotkey fired (synchronous)
   ├── GDI capture (with CAPTUREBLT)
   ├── Enumerate windows (merge same-process windows)
   ├── Save as PNG
   └── Cache the result (without consuming)

2. start_capture (async)
   ├── Peek the cached result
   ├── Hide the main window
   ├── Create the capture overlay window
   ├── Emit the capture-ready event
   └── Frontend polls get_cached_capture for the data

3. Frontend overlay
   ├── Poll for the screenshot path and window list
   ├── Load the PNG image
   ├── Match the smallest containing window on mouse move
   └── Highlight the window region

Quick-Reference Cheat Sheet

ProblemRoot causeFix
Main window pops up after ESC-cancelCancel logic explicitly shows + focuses itRemove the show/focus calls
Combo box not detectedEmpty titles and special styles filtered outFall back to class name, drop style filters
Combo box collapses on captureHiding windows shifts focusCapture first, hide after; add WS_EX_NOACTIVATE
Layered windows missingBitBlt without CAPTUREBLTGDI capture with CAPTUREBLT
Overlay image ≠ captured imageData consumed early + BMP alphaPeek instead of take + polling + PNG

Closing Thoughts

A screenshot tool looks simple but touches multiple low-level mechanisms: the Windows window system, graphics capture APIs, and cross-process data sync. The deepest lessons from this build:

  1. The Windows window system is far more complex than it looks: a humble combo box can involve multiple standalone windows, layered windows, and focus management
  2. Verify data flow end to end: correct data in backend logs doesn’t mean the frontend receives it — verify every link
  3. Never assume API behavior: GetDIBits alpha, BitBlt layered capture, browser BMP rendering — all need real-world verification
  4. Have a fallback when events are unreliable: polling is inelegant, but far better than lost data
]]> https://cocozq.site/2026/10/04/screenshot-capture-debugging-guide/ 2026-10-03T16:00:00.000Z

While building a screenshot tool, I ran into a series of nasty problems: pressing ESC to cancel a capture yanked the main]]>

Screenshot Tool Debugging Notes: Window Detection, Layered Capture, and Frontend Data Sync 2026-10-04T01:49:08.122Z cocozq

Someone recently messaged me that their Sharp MD player won’t power on. I’ve previously written two posts about dead Sharp MD units, so here’s a reorganized write-up to give anyone hitting the same problem a few ideas.

Sharp MD players have two notorious common faults: shattered gears and dead-no-power. They tend to split by model — the MT66 and MT77/877 rarely suffer shattered gears, but these two “sleep to death”: even a brand-new unit, left sitting unused for a long time, will refuse to power on when picked up again, which tanks its value. I’ve previously revived several units like this, including MT66/MT77 models — but if you ask me for the exact root cause, I honestly don’t know. Really! Every single one of them just… came back to life on its own while I was probing it on the bench.

Sharp MT77 in blue

The first unit I ever revived: I was probing around IC401, casually poking a few voltages with the multimeter, and it just powered on — as if some capacitor was the culprit. One unit proves nothing, so I found another one with the same symptom. My guess was a stuck power IC state or an aged capacitor, and my earlier probing had effectively injected some impedance that pulled a level back into range or changed a load capacitance. So I pulled out the Service Manual, ready to check the RESET/VCC signals and capture the power-up sequence on the scope. Given how badly I slept through digital/analog electronics and signals & systems back in college — and how little attention I paid the oscilloscope in lab class — it’s no surprise the scope was probably misconfigured: nothing I measured looked right, nothing matched expectations. Then after another round of random poking, the unit came back to life. A later MT66 with the same symptom went down the exact same path.

Things worth trying

  1. Set the bench supply to 1.3V. Don’t ask me why — the first unit mysteriously recovered while powered at exactly that voltage.
  2. Find a ~100kΩ resistor and try discharging the RESET / VCC / XTAL / PLVBAT pins of IC401 to ground.

IC401 probe points on the MT77

For those who know their stuff: help pin down the real cause

Grab the MT77 Service Manual, power it up (or rather, fail to), and record the static voltages on these pins with a multimeter, then follow up with a scope:

  • RESET (pin 59) — is it stuck low?
  • VCC (pin 62) — is there a ramp-up at all?
  • XTAL (pin 63) — is the crystal oscillating?
  • PLVBAT (pin 52) — compare against a working unit

A revived MT77, powered on again

]]> https://cocozq.site/2026/10/04/sharp-md-no-power-repair/ 2026-10-03T16:00:00.000Z

Someone recently messaged me that their Sharp MD player won’t power on. I’ve previously written two posts about dead Sharp]]>

Sharp MD Players (MT66/MT77) That Won't Power On: Repair Notes (Mostly Blind Luck) 2026-10-04T01:59:37.927Z cocozq Using the CocoMarkdown project as a worked example, this post summarizes complete implementations for two drag-and-drop scenarios in Tauri (v2) apps, for other projects to reference.

Contents

  1. Scenario Overview
  2. Scenario 1: In-App Drag & Drop
  3. Scenario 2: External Files Dropped Into the App
  4. Common Pitfalls
  5. Full Code Reference

1. Scenario Overview

ScenarioDrag sourceDrop targetRecommended approach
In-app DnDDOM element inside the appDOM element inside the appMouse events (mousedown/mousemove/mouseup)
External filesOS file managerRegion inside the appTauri native events + HTML5 DnD assist

Core principle: never use the HTML5 Drag and Drop API for in-app dragging, because Tauri’s WebView2 (Windows) intercepts native drag events — the cursor turns into a “not allowed” icon and no amount of preventDefault() fixes it.

2. Scenario 1: In-App Drag & Drop

2.1 Why not the HTML5 DnD API

On Windows WebView2, HTML5 Drag and Drop events get intercepted at the native layer:

  • Calling e.preventDefault() in dragover cannot stop the cursor from turning into the forbidden icon
  • dataTransfer.dropEffect settings have no effect
  • Custom MIME types don’t help either
  • Even intercepting the DragDrop event in Rust via on_window_event and calling prevent_default() doesn’t work (Tauri v2’s DragDropEvent has no prevent_default method)

Conclusion: the HTML5 DnD API does not work inside Tauri WebView2 — use Mouse events instead.

2.2 Mouse-Event Implementation

Overall approach

  1. mousedown: record the drag source element and start coordinates
  2. mousemove: once movement passes a threshold, activate the drag, show a ghost element following the cursor, highlight the target region
  3. mouseup: complete the drop, run the business logic
  4. Extras: ESC to cancel, prevent accidental click after a drag

JavaScript implementation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
// ── State ──
let dragSrcPath = null;       // drag source path
let dragOverItem = null;      // currently hovered target element
let dragSrcElement = null;    // drag source DOM element
let isDragging = false;       // drag in progress?
let wasDragging = false;      // a drag just finished (to swallow click)
let dragStartX = 0;           // drag start X
let dragStartY = 0;           // drag start Y
let dragGhost = null;         // ghost element following the cursor

// ── Ghost element management ──
function createDragGhost(label) {
  dragGhost = document.createElement('div');
  dragGhost.className = 'tree-drag-ghost';
  dragGhost.textContent = label;
  document.body.appendChild(dragGhost);
}

function moveDragGhost(x, y) {
  if (!dragGhost) return;
  dragGhost.style.left = (x + 12) + 'px';
  dragGhost.style.top = (y + 12) + 'px';
}

function removeDragGhost() {
  if (dragGhost) { dragGhost.remove(); dragGhost = null; }
}

// ── Reset drag state ──
function clearDragState() {
  if (dragSrcElement) dragSrcElement.classList.remove('dragging');
  if (dragOverItem) dragOverItem.classList.remove('drag-over');
  dragSrcPath = null;
  dragOverItem = null;
  dragSrcElement = null;
  isDragging = false;
  removeDragGhost();
  document.body.classList.remove('explorer-dragging');
}

// ── mousedown: record the source ──
container.addEventListener('mousedown', (e) => {
  const item = e.target.closest('.tree-item[data-path]');
  if (!item) return;
  if (e.button !== 0) return;  // left button only
  dragSrcPath = item.dataset.path;
  dragSrcElement = item;
  dragStartX = e.clientX;
  dragStartY = e.clientY;
  isDragging = false;
  wasDragging = false;
});

// ── mousemove: drag in progress ──
document.addEventListener('mousemove', (e) => {
  if (!dragSrcPath || !dragSrcElement) return;

  // Movement threshold (prevents clicks from triggering drags)
  const dx = e.clientX - dragStartX;
  const dy = e.clientY - dragStartY;
  if (!isDragging) {
    if (Math.abs(dx) < 4 && Math.abs(dy) < 4) return;
    isDragging = true;
    dragSrcElement.classList.add('dragging');
    document.body.classList.add('explorer-dragging');
    const label = dragSrcElement.querySelector('.tree-label')?.textContent || '';
    createDragGhost(label);
  }

  // move the ghost
  moveDragGhost(e.clientX, e.clientY);

  // hit-test the drop target (elementFromPoint sees through the ghost)
  const target = document.elementFromPoint(e.clientX, e.clientY)
    ?.closest('.tree-item[data-is-dir="true"]');

  if (dragOverItem && dragOverItem !== target) {
    dragOverItem.classList.remove('drag-over');
  }
  if (target && target.dataset.path !== dragSrcPath) {
    target.classList.add('drag-over');
    dragOverItem = target;
  } else if (dragOverItem) {
    dragOverItem.classList.remove('drag-over');
    dragOverItem = null;
  }
});

// ── mouseup: complete the drop ──
document.addEventListener('mouseup', async (e) => {
  if (!dragSrcPath || !dragSrcElement) {
    dragSrcPath = null;
    dragSrcElement = null;
    return;
  }
  if (!isDragging) {
    dragSrcPath = null;
    dragSrcElement = null;
    return;
  }

  wasDragging = true;
  const destDir = dragOverItem?.dataset.path;
  const srcPath = dragSrcPath;
  clearDragState();

  if (!srcPath || !destDir) return;
  if (srcPath === destDir) return;

  // guard against dropping a folder into its own subdirectory
  if (destDir.startsWith(srcPath + '\\') || destDir.startsWith(srcPath + '/')) {
    showToast('Cannot move a folder into its own subfolder');
    return;
  }

  // perform the move
  await handleExplorerDrop(srcPath, destDir);
});

// ── swallow the click that fires after a drag ──
container.addEventListener('click', (e) => {
  if (wasDragging) {
    e.stopPropagation();
    e.preventDefault();
    wasDragging = false;
  }
}, true);

// ── ESC cancels the drag ──
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && isDragging) {
    clearDragState();
    wasDragging = false;
  }
});

CSS

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/* drag source: translucent */
.tree-item.dragging {
  opacity: 0.4;
}

/* drop target: highlighted border */
.tree-item.drag-over {
  background: rgba(108, 99, 255, 0.2);
  outline: 1px dashed var(--accent);
  outline-offset: -1px;
}

/* while dragging: cursor */
body.explorer-dragging,
body.explorer-dragging .tree-item {
  cursor: grabbing !important;
}

/* ghost label following the cursor */
.tree-drag-ghost {
  position: fixed;
  z-index: 9999;
  pointer-events: none;       /* key: lets elementFromPoint see through it */
  background: var(--accent);
  color: #fff;
  padding: 4px 10px;
  border-radius: 4px;
  font-size: 12px;
  white-space: nowrap;
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.3);
  opacity: 0.9;
}

Rust backend: the move command

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#[tauri::command]
fn move_item(src_path: String, dest_dir: String) -> Result<String, String> {
    let src = PathBuf::from(&src_path);
    let dest = PathBuf::from(&dest_dir);

    if !src.exists() {
        return Err("Source does not exist".to_string());
    }
    if !dest.is_dir() {
        return Err("Destination is not a directory".to_string());
    }

    let file_name = src.file_name()
        .map(|n| n.to_string_lossy().to_string())
        .unwrap_or_default();
    let dest_full = dest.join(&file_name);

    if dest_full.exists() {
        return Err("A file/folder with that name already exists at destination".to_string());
    }

    fs::rename(&src, &dest_full)
        .map_err(|e| format!("Move failed: {}", e))?;

    Ok(dest_full.to_string_lossy().to_string())
}

2.3 Key Design Points

PointDetail
Movement thresholdDrag activates only after moving 4px+ from mousedown, so clicks never trigger drags
pointer-events: noneThe ghost must set this, otherwise elementFromPoint hits the ghost instead of the target
wasDragging flagA click still fires after mouseup — intercept it in the capture phase
Body-level cursorAdd a class to body during drags for cursor: grabbing, so the pointer is correct everywhere
Subdirectory guardPrevent dropping a folder into its own subdirectory (infinite loop)
Name-collision checkBackend verifies no same-named file/folder exists at the destination

3. Scenario 2: External Files Dropped Into the App

3.1 Dual-strategy architecture

Dropping external files needs both strategies at once:

  • Strategy A (primary): Tauri native events — real file paths via tauri://drag-enter / tauri://drag-leave / tauri://drag-drop
  • Strategy B (supporting): HTML5 DnD events — UI visual feedback (highlight borders) backing up strategy A

Why both? Tauri’s native events only provide drag-enter / drag-leave / drag-drop — no dragover — but the UI highlight needs continuous updates during dragover.

3.2 Rust: forwarding native drag events

Register an on_window_event handler in the Tauri builder to forward native drag events to the frontend:

1
2
3
4
5
6
7
8
tauri::Builder::default()
    .on_window_event(|window, event| {
        if let tauri::WindowEvent::DragDrop(drop_event) = event {
            if let tauri::DragDropEvent::Drop { paths, position: _ } = drop_event {
                let _ = window.emit("tauri://drag-drop", paths);
            }
        }
    })

Note: Tauri v2’s DragDropEvent has no prevent_default() method — don’t try to call it.

3.3 Frontend: Tauri events + HTML5 DnD assist

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
function setupExternalDragDrop() {
  const targetPanel = document.querySelector('.explorer-panel');
  const editorPanel = document.querySelector('.editor-panel');

  // ── Strategy A: Tauri native events ──
  if (window.__TAURI__?.event?.listen) {
    window.__TAURI__.event.listen('tauri://drag-enter', () => {
      targetPanel?.classList.add('explorer-drag-over');
    });

    window.__TAURI__.event.listen('tauri://drag-leave', () => {
      targetPanel?.classList.remove('explorer-drag-over');
    });

    window.__TAURI__.event.listen('tauri://drag-drop', (event) => {
      targetPanel?.classList.remove('explorer-drag-over');
      const paths = Array.isArray(event.payload)
        ? event.payload
        : (event.payload?.paths || []);
      if (paths.length > 0) {
        handleDroppedFiles(paths);
      }
    });
  }

  // ── Strategy B: HTML5 DnD (visual feedback + fallback paths) ──
  if (targetPanel) {
    ['dragenter', 'dragover'].forEach((name) =>
      targetPanel.addEventListener(name, (e) => {
        e.preventDefault();
        e.stopPropagation();
        targetPanel.classList.add('explorer-drag-over');
      })
    );
    ['dragleave', 'drop'].forEach((name) =>
      targetPanel.addEventListener(name, (e) => {
        e.preventDefault();
        e.stopPropagation();
        targetPanel.classList.remove('explorer-drag-over');
      })
    );
    targetPanel.addEventListener('drop', async (e) => {
      const paths = [];
      if (e.dataTransfer?.files) {
        for (const f of e.dataTransfer.files) {
          if (f.path) paths.push(f.path);
        }
      }
      if (paths.length > 0) {
        await handleDroppedFiles(paths);
      }
    });
  }

  // ── Editor area: only .md files accepted ──
  if (editorPanel) {
    const MD_RE = /\.(md|markdown|mdown|mkd|mkdn|mdwn|mdtxt|text|mdtext|Rmd)$/i;
    ['dragenter', 'dragover'].forEach((ev) =>
      editorPanel.addEventListener(ev, (e) => {
        if (!e.dataTransfer.types.includes('Files')) return;
        e.preventDefault();
        e.stopPropagation();
        editorPanel.classList.add('editor-drag-over');
      })
    );
    ['dragleave', 'drop'].forEach((ev) =>
      editorPanel.addEventListener(ev, (e) => {
        e.preventDefault();
        e.stopPropagation();
        editorPanel.classList.remove('editor-drag-over');
      })
    );
    editorPanel.addEventListener('drop', async (e) => {
      if (!e.dataTransfer?.files || e.dataTransfer.files.length === 0) return;
      for (const f of e.dataTransfer.files) {
        if (MD_RE.test(f.name) && f.path) {
          await openFile(f.path);
          break;
        }
      }
    });
  }
}

3.4 CSS: drop-zone visual feedback

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
/* explorer drop highlight */
.panel-content.explorer-drag-over {
  position: relative;
}

.panel-content.explorer-drag-over::after {
  content: '';
  position: absolute;
  inset: 0;
  z-index: 10;
  pointer-events: none;
  border: 2px dashed var(--accent);
  border-radius: var(--radius-sm);
  background: rgba(108, 99, 255, 0.06);
  animation: dragPulse 1.5s ease-in-out infinite;
}

/* editor drop highlight */
.editor-panel.editor-drag-over::after {
  content: '';
  position: absolute;
  inset: 0;
  z-index: 10;
  pointer-events: none;
  border: 2px dashed var(--accent);
  border-radius: var(--radius-sm);
  background: rgba(108, 99, 255, 0.06);
  animation: dragPulse 1.5s ease-in-out infinite;
}

@keyframes dragPulse {
  0%, 100% { opacity: 1; }
  50% { opacity: 0.6; }
}

3.5 Tauri capability configuration

Make sure capabilities includes the event-listening permissions:

1
2
3
4
5
6
{
  "permissions": [
    "core:event:default",
    "core:event:allow-listen"
  ]
}

4. Common Pitfalls

4.1 WebView2 intercepts HTML5 DnD events

SymptomCauseFix
Cursor turns into the forbidden iconWebView2 intercepts drags at the native layer; preventDefault() is uselessUse Mouse events for in-app dragging
drop never firesWebView2 treats the drag as files being dropped into the appGet paths from Tauri native events
dataTransfer.getData() returns emptyWebView2 security restrictionsGet paths from the Tauri event payload

4.2 elementFromPoint hits the ghost element

While the ghost follows the cursor, document.elementFromPoint(x, y) returns the ghost itself instead of the target underneath.

Fix: the ghost must set pointer-events: none.

4.3 Stray click after a drag

The browser still fires click after mouseup, accidentally opening the file/folder you just dropped.

Fix: use the wasDragging flag to intercept the click in the capture phase.

4.4 File.path may be undefined

In WebView2, the .path property of HTML5 DnD File objects may be undefined — no filesystem path available.

Fix: prefer Tauri native events (strategy A) for paths; HTML5 DnD is only visual feedback plus a fallback.

4.5 Tauri v2’s DragDropEvent has no prevent_default

Tauri v1’s DragDropEvent had prevent_default(); it was removed in v2. Don’t call it inside on_window_event.

4.6 External drops vs in-app drags conflicting

Mouse-event in-app dragging and HTML5 DnD / Tauri-native external drops don’t interfere, but note:

  • Mouse mousemove does not fire during an HTML5 DnD operation (the browser suppresses mouse events mid-DnD)
  • So both mechanisms coexist safely

5. Full Code Reference

Files involved in the CocoMarkdown project:

FileContents
src/app.js (L1211-L1315)In-app drag: Mouse-event implementation
src/app.js (L2225-L2320)External file drops: dual-strategy implementation
src/app.js (L2435-L2474)Post-drop file move handling
src/styles.css (L694-L793)Drag-related CSS
src-tauri/src/lib.rs (L808-L837)Rust move_item command
src-tauri/src/lib.rs (L871-L878)Rust on_window_event forwarding
src-tauri/capabilities/default.jsonEvent-listening permissions

Summary

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────────────────┐
│           Tauri Drag & Drop Decision Tree            │
├─────────────────────────────────────────────────────┤
│                                                     │
│  What is the drag source?                           │
│  │                                                  │
│  ├── DOM element inside the app                     │
│  │   └── Use Mouse events (mousedown/move/up)        │
│  │       - No HTML5 DnD (WebView2 intercepts it)     │
│  │       - ghost element: pointer-events: none      │
│  │       - wasDragging swallows stray clicks        │
│  │                                                  │
│  └── External OS file                               │
│      └── Tauri native events + HTML5 DnD assist      │
│          - Tauri events give real file paths         │
│          - HTML5 DnD gives dragover feedback        │
│          - on_window_event forwards drag-drop       │
│                                                     │
└─────────────────────────────────────────────────────┘
]]> https://cocozq.site/2026/10/04/tauri-drag-drop-guide/ 2026-10-03T16:00:00.000Z Using the CocoMarkdown project as a worked example, this post summarizes complete implementations for two drag-and-drop scenarios in]]> Implementing Drag and Drop in Tauri Apps: A Complete Guide 2026-10-04T01:55:46.871Z cocozq When developing a Tauri + Rust desktop app, teams often hit a bizarre situation: the app runs silky smooth under npm run tauri dev, but the packaged Release build (exe) mysteriously crashes when performing certain file I/O or async operations.

If your logs caught thread 'main' has overflowed its stack, this post may help you locate and fix the problem fast.

Symptoms

The app crashed suddenly during deep directory traversal (e.g. SFTP read_dir) or large file reads/writes. The underlying Rust crash log looked like this:

1
2
[SFTP] 🔵 sftp_read_dir CALLED: path=/home/wwwroot/website/wp-content
thread 'main' (114380) has overflowed its stack

Common Investigation Traps

On first pass, developers tend to fall into two traps:

  1. ❌ Blaming LTO (Link Time Optimization)
    Theory: Release mode enables LTO, functions get aggressively inlined, and deeply nested inlining blows up the call stack.
    Truth: check your Cargo.toml — unless you explicitly set lto = true under [profile.release], Rust does not enable full LTO by default.
  2. ❌ Blaming infinite recursion from the frontend
    Theory: the frontend TypeScript retries recursively when it hits “file already exists”.
    Truth: as long as the recursion has an exit (e.g. the second call passes an overwrite flag), even two or three levels of shallow recursion can never cause a system-level stack overflow.

The Real Root Cause

This stack overflow was actually a chain reaction of three underlying mechanisms stacking up:

  1. Windows’ tiny main-thread stack limit: unlike the 8MB convention on Linux/macOS, a PE executable on Windows gives the default main thread only 1MB of stack.
  2. Wildly oversized stack allocations: to boost performance, file read/write code may declare a huge array right on the stack. A single let mut buffer = [0u8; 64 * 1024]; eats 64KB of stack on the spot.
  3. Async Future state-machine bloat in Release: under Release optimization (opt-level = 3), the Rust compiler packs complex async call chains into one giant Future state machine, with all related locals stored inside that state-machine object.

When Tauri’s main thread (which typically handles both the GUI and IPC command processing) reaches this code, 1MB of cramped space + a bloated Future state machine + a giant local buffer punches straight through the stack. Dev mode doesn’t crash only because, without deep optimization merging Futures together, locals get released quickly.

The Fix

To solve this thoroughly and elegantly, attack it from two sides.

Fix 1: Enlarge the Windows main-thread stack at compile time (the cure)

Since the default 1MB isn’t enough, change the linker argument at build time to raise the stack ceiling to the standard 8MB.

Find or create build.rs in your src-tauri directory and add:

1
2
3
4
5
6
7
8
9
fn main() {
    // 💡 On Windows, force the main-thread stack up to 8MB
    // so extremely complex async Futures or deep calls can't
    // blow through the default 1MB limit
    #[cfg(target_os = "windows")]
    println!("cargo:rustc-link-arg=/STACK:8388608");

    tauri_build::build()
}

💡 Tip: injecting the linker arg via build.rs is safer than editing .cargo/config.toml directly — it won’t clobber global rustflags and break Tauri’s build scripts.

Fix 2: Move giant buffers to the heap (the optimization)

Never allocate super-sized arrays on the function stack. For any buffer above ~`10KB, decisively put it on the heap with a Vec`.

1
2
3
4
5
// ❌ Bad: allocated on the stack, devours stack space instantly
let mut buffer = [0u8; 64 * 1024];

// ✅ Good: allocated on the heap, takes all pressure off the stack
let mut buffer = vec![0u8; 64 * 1024];

Lessons Learned

  • Windows-only Release crashes: suspect the default 1MB stack limit first.
  • Beware oversized locals: especially inside async functions, where locals get swept into the compiler-generated Future state machine struct and can silently drain the stack.
  • Put build.rs to work: it’s the cleanest place for per-platform linker customization — no global config pollution.
]]> https://cocozq.site/2026/10/04/tauri-stack-overflow-fix/ 2026-10-03T16:00:00.000Z When developing a Tauri + Rust desktop app, teams often hit a bizarre situation: the app runs silky smooth under npm run tauri dev, but the packaged Release build (exe) mysteriously crashes when performing certain file I/O or async operations.

If your logs caught thread 'main' has overflowed its stack, this post may help you locate and fix the problem fast.

]]> Tracking Down a Stack Overflow Crash in Tauri (Rust) Windows Release Builds 2026-10-04T01:54:20.153Z cocozq CocoFileTV Icon

CocoFileTV - File Manager

Get it on Google Play

Managing files on a TV shouldn’t feel like a chore. CocoFileTV is a powerful file manager built exclusively for Android TV — fully navigable with a D-pad remote, and optimized for the 10-foot large-screen experience.

Browse local files, USB drives, cloud storage, NAS shares, and FTP servers — all from your couch.

CocoFileTV poster

Screenshots

CocoFileTV home screen

TV-optimized home dashboard

Scan QR code to transfer files

Scan-to-transfer over LAN

Cloud storage drives

Cloud drives with QR login

Key Highlights

1. Scan to Transfer Files

No USB stick needed, no complicated setup. Scan the QR code shown on your TV with your phone’s browser and send files straight to the TV over the local network. It elegantly solves the age-old “how do I get files onto my TV” problem.

2. Cloud Storage QR Login

Connect Google Drive, OneDrive, Dropbox, and Box. Instead of typing passwords with a remote, just scan the QR code and enter a short code on your phone to log in — faster and far less painful.

Core Features

  • File & folder management — browse, copy, move, delete, rename, and create folders
  • USB & external storage — access thumb drives and external disks directly
  • Cloud storage — manage files across Google Drive, OneDrive, Dropbox, and more
  • NAS & network explorer — browse network shares seamlessly on your TV
  • FTP client — transfer files between the TV and other devices
  • File preview — preview text, images, and videos, with large-file paging and encoding options
  • Search & sort — find files by name, type, or path; sort by name, size, or modified time
  • Tags & filters — organize files with tags for quick access
  • Share & web management — manage files and install APKs from a browser on the same network, no USB needed
  • Remote-control friendly — every screen designed for D-pad navigation

Perfect For

  • Managing files on Android TV / Google TV
  • Browsing USB drives on the big screen
  • Accessing cloud storage and NAS from the couch
  • Installing APKs without touching a USB stick

Privacy & Stability First

CocoFileTV focuses on stability, performance, and privacy — local-first file operations with no unnecessary data leaving your devices, delivering a smooth and reliable file management experience for TV users.

Get the App

]]> https://cocozq.site/2026/10/02/introducing-cocofiletv/ 2026-10-01T16:00:00.000Z CocoFileTV Icon

CocoFileTV - File Manager

Get it on Google Play

Managing files on a TV shouldn’t feel like a chore. CocoFileTV is a powerful file manager built exclusively for Android TV — fully navigable with a D-pad remote, and optimized for the 10-foot large-screen experience.

Browse local files, USB drives, cloud storage, NAS shares, and FTP servers — all from your couch.

]]> Introducing CocoFileTV: A Powerful File Manager for Android TV 2026-10-02T07:40:29.295Z cocozq Coco Launcher Icon

Coco Launcher - Minimalist

Get it on Google Play

Your home screen should help you focus — not distract you. Coco Launcher is a clean, lightweight Android launcher for users who want a simpler, faster, distraction-free home screen.

No clutter. No unnecessary features. Just the apps and information you need.

Coco Launcher poster

Screenshots

Frequent and recent apps with custom dock

Smart lists: Frequent & Recent Apps

Theme and layout settings

Deep customization: themes & grid

Information cards and widgets

Information cards & widgets

Why Coco Launcher?

Minimalist Home Screen

A focused layout keeps your home screen clean. Frequently used and recent apps are organized automatically, so what you need is always one tap away.

Find any app instantly by name, first letter, or Pinyin — perfect for Chinese app names and blazing-fast app launching.

Smart App Lists

Frequently used and recently opened apps update automatically, keeping important apps always within reach without manual sorting.

Custom Dock Bar

Pin your favorite apps to the dock for quick one-tap access.

Information Cards

Swipe from the edge to glance at useful info: battery, RAM, storage, CPU, Bluetooth devices, time, and countdowns.

Beautiful Themes

Multiple themes plus dark mode to make the launcher truly yours.

Physical Keyboard Support

Launch apps instantly with hardware key shortcuts — a perfect companion for phones with physical keyboards, alongside my other keyboard-first apps.

Modern Android Experience

Gesture and 3-button navigation support with a clean edge-to-edge interface.

Perfect For

  • Users who want a simple Android home screen
  • Fans of lightweight launchers
  • People who prefer distraction-free design
  • Users with physical keyboard devices
  • Chinese users who need Pinyin app search

Built for Simplicity, Speed & Stability

Coco Launcher focuses on simplicity, speed, and stability — a clean home screen experience made for everyday use, with no bloat and no noise.

Get the App

]]> https://cocozq.site/2026/10/02/introducing-coco-launcher-m/ 2026-10-01T16:00:00.000Z Coco Launcher Icon

Coco Launcher - Minimalist

Get it on Google Play

Your home screen should help you focus — not distract you. Coco Launcher is a clean, lightweight Android launcher for users who want a simpler, faster, distraction-free home screen.

No clutter. No unnecessary features. Just the apps and information you need.

]]> Introducing Coco Launcher: A Clean, Minimalist Android Home Screen 2026-10-02T08:13:55.439Z cocozq Coco Bluetooth Remote Icon

Coco Bluetooth Remote

Get it on Google Play

Lost your TV remote again? Typing a password with arrow keys letter by letter? Coco Bluetooth Remote turns your phone into a Bluetooth remote control, a full wireless keyboard, and a touchpad — using the standard Bluetooth HID protocol.

No app to install on your TV. No Wi-Fi needed. No cloud, no account. Just pair over Bluetooth and start controlling.

Screenshots

TV remote control interface

Familiar TV remote layout

Full wireless keyboard interface

Full keyboard with modifiers & F-keys

Bluetooth pairing screen

Pair in seconds, auto-reconnect

Why Choose It?

  • No TV-side app — works with any device that supports standard Bluetooth HID
  • No Wi-Fi or internet required — pure local Bluetooth connection
  • Fast, stable, low-latency — secure local communication, no cloud dependency

Core Features

1. Smart TV Remote Control

A familiar remote experience with D-pad navigation, OK/Enter, Back, Home, Menu, Power (on supported devices), volume, mute, number keys, and channel switching — plus full media controls (play/pause, stop, previous/next track).

2. Full Wireless Keyboard

Typing on a TV with a D-pad is painful. Coco Bluetooth Remote gives you a complete keyboard: letters, numbers, symbols, Ctrl/Alt/Shift/Win modifiers, F1–F12, arrows, Esc/Tab/Backspace/Delete, Home/End/Insert, Page Up/Down, and Print Screen. Perfect for searching movies, entering passwords, or driving a PC from the couch.

3. Wireless Touchpad

Turn your phone screen into a responsive touchpad with cursor movement, single/double tap, long-press drag, and adjustable sensitivity. Great for web browsing, presentations, and desktop control.

4. NEW in v1.0.6: Gamepad Mode

The latest update adds a gamepad remote control mode with joystick, D-pad, ABXY buttons, and triggers. It also fixes the HID keycode mapping for the number key “0” for better remote compatibility.

5. Multiple Compatibility Modes

Different brands handle system keys differently, so the app ships multiple key-sending modes you can switch per device. Compatible with Android TV, Google TV, smart TVs, TV boxes, projectors, Windows, macOS, and Linux — with compatibility improving every release.

Thoughtful Details

  • Beautiful light & dark themes, one-hand-friendly layout
  • Auto-reconnect to the last paired device
  • Adjustable touchpad sensitivity and optional haptic feedback
  • Multi-language support

Privacy First

All communication happens over local Bluetooth only:

  • No internet connection required
  • No cloud servers, no accounts
  • No data collection, no keystroke uploads

How to Use

  1. Enable Bluetooth on your phone.
  2. Open Coco Bluetooth Remote.
  3. On your TV, TV box, or computer, search for Bluetooth devices.
  4. Pair with Android Remote Keyboard.
  5. Start controlling instantly.

Get the App

]]> https://cocozq.site/2026/10/01/introducing-coco-bluetooth-remote/ 2026-09-30T16:00:00.000Z Coco Bluetooth Remote Icon

Coco Bluetooth Remote

Get it on Google Play

Lost your TV remote again? Typing a password with arrow keys letter by letter? Coco Bluetooth Remote turns your phone into a Bluetooth remote control, a full wireless keyboard, and a touchpad — using the standard Bluetooth HID protocol.

No app to install on your TV. No Wi-Fi needed. No cloud, no account. Just pair over Bluetooth and start controlling.

]]> <![CDATA[Introducing Coco Bluetooth Remote: Turn Your Phone into a TV Remote, Wireless Keyboard & Touchpad]]> 2026-10-02T00:49:40.854Z cocozq 可可注音輸入法圖示

可可注音輸入法

實體鍵盤專用 • BlackBerry 台灣注音鍵位 • 五鍵選字

可可注音輸入法是一款專為實體全鍵盤手機打造的注音輸入法（ㄅㄆㄇㄈ），將 37 個注音符號與聲調符號完整映射到 QWERTY 鍵盤上，沿用 BlackBerry 台灣版注音鍵位習慣，並保留廣受好評的五鍵選字體系，讓您在實體鍵盤上重現流暢極速的台灣注音輸入體驗。

⌨️ 實體全鍵盤注音佈局（BlackBerry 經典鍵位映射）

以下為 37 個注音符號與聲調在實體 QWERTY 鍵盤上的完整分佈圖，雙符號鍵支援連按切換（Multi-Tap）：

可可注音輸入法實體鍵盤佈局圖

經典 BlackBerry 台灣版鍵位映射與連按雙符號切換說明

📱 實機畫面與介面展示

實體鍵盤注音介面

五鍵選字與實體鍵盤映射

繁簡切換與工具列

即時繁簡切換與快捷工具列

細緻設定與機型配對

連按切換時間與自訂外觀

⚡ 核心亮點

1. ⌨️ 實體鍵盤注音（完美傳承經典）

  • 37 個注音符號 + 聲調完整映射：依循 BlackBerry 台灣版經典注音鍵位。
  • 雙符號鍵連按切換（Multi-Tap）：同一按鍵連按循環切換雙注音符號（如 W→ㄉ，連按兩下 WW→ㄊ），切換超時時間支援自訂（300~1500ms），行為與原生黑莓完全一致。

2. 👍 五鍵選字（拇指不離主鍵盤）

  • 候選欄常駐 5 個候選字：0 鍵選擇首選字，方向鍵選第 2~5 候選字。
  • 完全免用數字鍵：真正實現盲打選字，輸入效率倍增。
  • 聲調可省略：空格直接輸出首選字，支援簡拼輸入（例如輸入 ㄑㄎ 直接出現「情況」）。

3. 🔄 一鍵繁簡切換

  • 工具列設有繁簡按鈕快速切換候選字輸出，亦可使用快捷鍵 Sym + Del 隨時切換，繁體中文即時生效。

🛠️ 豐富功能支援

  • 軟鍵盤模式：鍵帽同時顯示字母與注音符號，觸控螢幕手機亦能享受一致的輸入邏輯。
  • 同步顯示漢語拼音：注音框可同步提示對應拼音，幫助快速熟悉實體鍵位。
  • 手勢操作：支援上下滑動選字、左右滑動翻頁，靈敏度與有效觸控區域均可自由調整。
  • 便捷工具整合：內建剪貼簿歷史管理、輸入框算式即時計算、藍牙遙控鍵盤功能。
  • 詞庫備份與匯入：支援使用者個人詞庫備份/還原、自訂詞庫匯入與通訊錄姓名整合。

📱 支援機型

自動偵測並針對以下實體全鍵盤裝置深度調校：

  • BlackBerry 系列：KEYone / KEY2 / KEY2 LE / Priv
  • Unihertz Titan 系列：Titan / Titan Pocket / Titan Slim / Titan2 Elite
  • 其他全鍵盤設備：Zinwa Q25 / Q27、IKKO Mind One 及一般外接藍牙實體鍵盤

下載與體驗

可可注音輸入法專注於穩定性、原生極速效能與純淨隱私，為喜愛實體鍵盤的玩家提供無可替代的台灣注音輸入體驗。

]]> https://cocozq.site/2026/09/27/introducing-cocoime-zy/ 2026-09-26T16:00:00.000Z 可可注音輸入法圖示

可可注音輸入法

實體鍵盤專用 • BlackBerry 台灣注音鍵位 • 五鍵選字

可可注音輸入法是一款專為實體全鍵盤手機打造的注音輸入法（ㄅㄆㄇㄈ），將 37 個注音符號與聲調符號完整映射到 QWERTY 鍵盤上，沿用 BlackBerry 台灣版注音鍵位習慣，並保留廣受好評的五鍵選字體系，讓您在實體鍵盤上重現流暢極速的台灣注音輸入體驗。

]]> 可可注音輸入法：專為實體全鍵盤手機打造的經典注音輸入體驗 2026-10-02T00:49:40.842Z cocozq CocoNote Icon

Every utility tool starts with a problem close to home. For CocoNote, it was a very personal one: helping my aging parents manage their small hometown grocery store.

Today, I’m excited to share the story behind CocoNote, how it works, and how it evolved into a modern, scan-to-open everyday note-taking application.

The Origin Story

My parents run a small convenience store in my hometown. Over the years, with hundreds of items coming in and out, remembering the price and stock details of every single product became increasingly difficult for them.

I wanted to give them a tool that was effortless to use: point the camera at any barcode, scan it, and immediately see the product’s price, specs, and stock notes.

No complex spreadsheets, no bloated POS systems with monthly subscriptions—just a clean, responsive mobile app that solves the exact problem in front of them.

As I built and refined it, I began using it for my own daily routines—tracking medication schedules, managing hardware device serial numbers, indexing household storage boxes, and logging everyday expenses. That’s how CocoNote grew into the product it is today.

Key Highlights & App Screenshots

CocoNote Main Dashboard

Clean Note Stream & Quick Actions

CocoNote Markdown Preview

Rich Markdown Rendering

CocoNote Cloud & Backup

Encrypted Sync & Cloud Backup

Core Features

1. Scan-to-Open Notes (Barcode & QR Code Binding)

The core highlight of CocoNote. Bind any QR code or standard barcode to a specific note. Whether you are scanning a product in a store, a server rack label, or a storage box in your garage, one scan brings up the exact note and details instantly.

2. Encrypted Note Sharing

Privacy matters. CocoNote lets you generate encrypted shareable content, ensuring that private information, credentials, or sensitive notes can be securely sent and unlocked only by intended recipients.

3. Native Markdown Support & Tag System

Write formatted notes cleanly using full Markdown syntax (headers, checklists, code blocks, tables). Organize and cross-reference information quickly using a flexible tag management system.

4. Smart Reminders & Fast Capture

  • Set time-based alerts and notifications for critical tasks or medication instructions.
  • Fast capture support for text, images, and audio attachments on the go.

5. Seamless Multi-Device Sync & Local-First Resilience

Designed with a local-first mindset—your data is always accessible offline on your device, with optional cloud sync to keep notes in harmony across all your devices.

Built with Craft & Care

CocoNote is built using Flutter, engineered for high performance, smooth 60fps animations, and a polished user experience on both Android and iOS.

What’s Coming Next

  • Enhanced batch barcode import & export (CSV / JSON)
  • Advanced OCR scanning for receipt text extraction
  • Desktop companion client built with Flutter Desktop / Tauri

Get CocoNote

CocoNote is rolling out across app stores. Stay tuned for upcoming release notes and deep-dive technical articles on how its offline sync engine and camera scanning pipeline were architected.

]]> https://cocozq.site/2026/09/27/introducing-coconote/ 2026-09-26T16:00:00.000Z CocoNote Icon

Every utility tool starts with a problem close to home. For CocoNote, it was a very personal one: helping my aging parents manage their small hometown grocery store.

Today, I’m excited to share the story behind CocoNote, how it works, and how it evolved into a modern, scan-to-open everyday note-taking application.

]]> Introducing CocoNote: A Local-First, Scan-to-Open Smart Note App 2026-10-02T00:49:40.841Z