← Back to Blog

Edge Drop Guides | Aug 5, 2026 | 6 min read

How to Report a Bug in Edge-Drop

By Deepender Yadav

How to Report a Bug in Edge-Drop — Edge Drop Guide

A bug report that says "the shelf does not open sometimes" is a bug report that will sit in the issue tracker for weeks. A bug report that says "on Windows 11 23H2, Edge-Drop 0.2.7, single 4K monitor at 150% scaling, the shelf fails to open when the cursor enters the right-edge trigger strip while VS Code is fullscreen" is a bug report that gets triaged in a day. The difference is information. This guide covers what to include in an Edge-Drop bug report, where to file it, and how to gather the diagnostic information that makes the report actionable. For neighbouring topics see onboarding tutorial: what it covers and how to replay and how to build from source for the curious.

Where to file bugs

Edge-Drop's bug tracker is on GitHub: https://github.com/Deepender25/Edge-Drop/issues

To file a bug:

  1. Open the issues page in a browser.
  2. Click "New issue."
  3. Choose the "Bug report" template if one is offered.
  4. Fill in the template.
  5. Submit.

A GitHub account is required. There is no email-based bug reporting channel; GitHub Issues is the canonical tracker. This is standard for open-source projects and keeps the discussion visible to other users who may have the same bug.

Before filing, search the existing issues for keywords related to the bug. Duplicate reports are not harmful but they waste maintainer time. If a relevant issue exists, add a thumbs-up reaction and a comment with your reproduction details rather than filing a new issue.

The minimum information to include

Every bug report should include:

  • Edge-Drop version — find it in the About / Help tab of settings, or in the tray icon's right-click menu. See how to read Edge-Drop's in-app changelog for the version location.
  • Edge-Drop channel — GitHub NSIS build or Microsoft Store MSIX. The channel affects update behaviour and some packaging details. See how Edge-Drop updates on GitHub builds.
  • Windows version — Win+R → winver → note the version and build number (e.g., "Windows 11 23H2, build 22631.4317").
  • Windows display language and locale — relevant for language-specific bugs. See how to change language and RTL layout.
  • Display setup — number of monitors, resolution, scaling factor (e.g., "1 monitor, 3840x2160, 150% scaling" or "2 monitors, primary 2560x1440 at 100%, secondary 1920x1080 at 100%").
  • What you expected — the behaviour you thought would happen.
  • What actually happened — the behaviour you observed.
  • Reproduction steps — the minimum sequence to trigger the bug. Aim for 30 seconds or less.

The 30-second reproduction

The single most valuable part of a bug report is a minimal reproduction. The format:

1. Open Edge-Drop.
2. Open VS Code.
3. Copy a 100-line text file from VS Code.
4. Move the cursor to the right edge of the screen.
5. Expected: shelf opens, showing the copied text.
6. Actual: shelf does not open; tray icon is unresponsive for 5 seconds.

The principles:

  • Start from a fresh state. If the bug requires specific history, describe how to set that up. Otherwise, assume a fresh launch.
  • Be specific about every action. "Copy something" is not specific; "copy a 100-line text file from VS Code" is.
  • Include timings. If the bug involves a delay, note how long. "5 seconds" is more useful than "a while."
  • One bug per report. If you found two bugs, file two reports. Mixed reports are hard to triage.
  • Skip the speculation. Do not diagnose the cause; describe the symptom. Diagnosis is the maintainer's job.

If you cannot reproduce the bug deterministically, say so. "Happens about once a day, usually after the machine has been idle" is a useful statement; "happens sometimes" is not.

Clipboard formats involved

Many Edge-Drop bugs are format-specific. Note which clipboard format was involved:

  • Plain text — copied from a text editor, terminal, or chat.
  • Rich text / HTML — copied from a web page, Word, or an email client.
  • Image / bitmap — copied from a screenshot tool (Snipping Tool, ShareX) or an image editor.
  • File / HDROP — copied from Explorer (one or more files).
  • URL — copied from a browser address bar or a link.
  • Custom format — copied from a specific app that uses a custom clipboard format (e.g., a Photoshop layer, an Excel range, a Word selection with embedded objects).

If the bug only happens with one format, that is a strong clue. If it happens with all formats, that is a different clue.

For the broader topic of clipboard formats, see what the Windows clipboard can and cannot store.

Display and DPI details

Several Edge-Drop bugs are display-specific:

  • Multi-monitor — does the bug happen with one monitor, two, or three? Does it happen on the primary, the secondary, or only when the shelf is on a specific monitor?
  • DPI scaling — does the bug happen at 100%, 125%, 150%, or 200% scaling? Mixed-DPI setups (e.g., 4K at 150% and 1080p at 100%) are particularly informative.
  • Monitor orientation — landscape vs portrait. Portrait monitors change the edge trigger geometry.
  • Refresh rate — high-refresh monitors (144 Hz, 240 Hz) can affect hover dwell timing.
  • HDR — HDR-enabled monitors can affect rendering.

For the relevant settings, see how to pick which monitor Edge-Drop uses and DPI mixing: blurry overlays on a secondary screen.

Diagnostic logs

Edge-Drop writes diagnostic logs under %APPDATA%\Edge-Drop\logs\. The logs are plain text and rotated by size. To attach logs to a bug report:

  1. Quit Edge-Drop (tray icon → Quit).
  2. Open %APPDATA%\Edge-Drop\logs\ in File Explorer.
  3. Copy the most recent .log file (and the previous one if the bug happened across a rollover).
  4. Attach the files to the GitHub issue (drag-and-drop into the issue body).

Logs do not contain clipboard content. They contain:

  • Timestamps of clipboard sequence changes.
  • Format identifiers (e.g., "CF_TEXT", "CF_HDROP") — not the content.
  • Error messages from the poller, the renderer, or the IPC layer.
  • Settings load/save events.

If you are uncomfortable sharing logs publicly, redact any lines you prefer not to share. The remaining lines are still useful.

For the on-disk layout, see where Edge-Drop stores data on disk.

The bug report template

A copy-paste template:

**Edge-Drop version:** 0.2.7
**Channel:** GitHub NSIS / Microsoft Store
**Windows version:** Windows 11 23H2, build 22631.4317
**Display language:** English (United States)
**Display setup:** 1 monitor, 3840x2160, 150% scaling, landscape, 60 Hz, HDR off

**Expected:**
The shelf opens when the cursor enters the right-edge trigger strip.

**Actual:**
The shelf does not open. The tray icon is unresponsive for 5 seconds.

**Reproduction:**
1. Open Edge-Drop.
2. Open VS Code.
3. Copy a 100-line text file from VS Code.
4. Move the cursor to the right edge of the screen.
5. Observe: shelf does not open.

**Clipboard format involved:**
Plain text (CF_TEXT), ~5 KB.

**Frequency:**
Always (5/5 attempts).

**Logs:**
Attaching edge-drop-2026-08-19.log.

What happens after you file

The maintainers triage new issues on a best-effort cadence. Triage typically means:

  • Confirming the bug reproduces on a current build.
  • Labelling the issue (bug, enhancement, question, etc.).
  • Asking for additional information if needed.
  • Assigning a priority.

Not every issue gets a fix. Some bugs are deemed low-priority; some are deemed "won't fix" because the cost outweighs the benefit. The decision is the maintainers'; the reporter's job is to provide accurate information.

For features you would like to see, file a feature request using the same issues page, but mark it as a feature request in the title (e.g., "Feature request: ..."). Feature requests are not bugs; they are prioritised differently.

What Edge-Drop does not claim

  • The bug tracker is not a support channel. For "how do I..." questions, see the documentation first; this series of guides covers most workflows.
  • The maintainers do not commit to a fix timeline. Open-source projects ship fixes when the maintainer has time.
  • Bug reports are public. Anyone on the internet can read them. Do not include private information (passwords, customer data, internal URLs) in a bug report.
  • Bug reports do not auto-close when a new version ships. The reporter or a maintainer closes the issue after verifying the fix.

For the broader open-source context, see how to evaluate a public beta desktop app and bus factor: what if a solo app goes quiet.

Summary

A useful Edge-Drop bug report includes the version, channel, Windows version, display setup, expected versus actual behaviour, and a 30-second reproduction. Note the clipboard format involved and attach the diagnostic logs from %APPDATA%\Edge-Drop\logs\. File the report on GitHub Issues, after searching for existing reports of the same bug. The template in this guide can be copy-pasted and filled in. The maintainers triage on a best-effort cadence; not every issue gets a fix, but accurate reports significantly improve the chance of one.

Related reading

Sources

Deepender Yadav
Written by Deepender Yadav · Author & Developer

Deepender Yadav is a B.Tech Computer Science Engineering student and software developer interested in building practical software and open-source projects.

GitHub · LinkedIn

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support

Free · Lightweight · Privacy First
Find us on CodeHype