Contact Video Controls Plus | Bug Reports & Feature Requests

The Video Controls Plus contact page collects bug reports, feature requests, and general inquiries through a structured form plus a direct email fallback. Average first response is under 48 hours; complex bug reports may take longer because the maintainer reproduces every reported issue locally before responding. For the fastest resolution, include the exact URL where the bug occurs, the browser and version, and one to three steps to reproduce. The page also links to the public feature-request board so popular requests can be voted on by the community.

Use cases

Reporting a bug on a specific site

Use the structured form: it asks for browser version, extension version, the exact URL, and reproduction steps. The maintainer can usually fix bugs that are reproducible in under an hour; "it sometimes does not work" reports get queued behind the reproducible ones.

Suggesting a new feature

The contact form has a feature-request mode that posts your idea to /feature-requests, where other users can vote on it. Popular requests usually ship within one or two release cycles.

Asking a usage question

For general "how do I do X" questions, the FAQ at /faq covers about 80% of incoming questions. The contact form is the right channel for the remaining 20%.

Press, partnerships, or sponsorship inquiries

The page surfaces a direct email for non-support inquiries that need a quick human reply, separate from the bug-tracker queue.

How it works

  1. Pick the inquiry type. Bug report, feature request, usage question, or other. Each routes to a different queue with a different SLA.
  2. Fill the structured fields. Browser, version, URL (for bugs), reproduction steps, and any error logs from the browser console.
  3. Submit. The form posts to a private database; you receive an email confirmation with a tracking ID.
  4. Track status. Signed-in users see all their submissions at /my-submissions with status updates as the maintainer triages.

Examples

  • A bug report with reproduction steps. Average resolution time: 3–7 days, sometimes shipped in the next release.
  • A vague "it does not work" message. A clarifying reply asks for the URL, browser version, and console errors; until those arrive, the report is parked.

Frequently asked questions

How fast do you respond?

First response within 48 hours on average. Resolution depends on complexity — simple bugs in 3–7 days, larger features queue behind ongoing release work.

Is there phone or live-chat support?

No. The project is maintained by one person plus contributors; written channels (form + email) are the only support routes.

Where do feature requests go?

They are posted publicly at /feature-requests so other users can upvote them. Items with the most votes typically ship first.

Can I see the status of a request I submitted earlier?

Yes — sign in and visit /my-submissions to see every form you have submitted, with current status and any maintainer replies.

What information should I include in a bug report?

Browser + version, extension version, the URL where the bug happens, and 1–3 steps to reproduce. If you can attach a console screenshot, even better.

Will my email be used for marketing?

No. The email is used only to reply to your inquiry. The project does not run a marketing list.

Tips

  • A 30-second screen recording of the bug shortens resolution time by days. Free tools like Loom or the browser screenshot extension are enough.
  • Search /faq first; about 80% of incoming "how do I" questions already have an answer there.
  • If your feature request overlaps with an existing one on /feature-requests, upvote that one instead of filing a duplicate — it ships faster that way.
  • Mark "this is a regression" if the feature worked in a previous version; regressions jump the queue.

Limitations

  • No phone, live-chat, or weekend support.
  • The maintainer cannot reproduce bugs that depend on a paid course platform or a region-locked service the maintainer cannot access. In those cases, a screen recording is required.
  • Custom-development requests outside the scope of the public extension are politely declined; the project stays focused on the published feature set.

Last updated 2026-05-06 by Ahsan Mahmood, maintainer.