In-app bug reporting (modules for webview, Tauri and Flutter apps)
In-app bug reporting needs a different route than a website, because the script tag that works on a page does not work inside an app. Bugfix therefore offers modules that you copy into the project: one for apps on webview and Tauri, one for Flutter. Reports from the app land in the same inbox as reports from your site.
Why in-app bug reporting uses modules instead of the loader
On a site, one tag fetches the widget from the Bugfix center. Inside an app that does not work: the security policy of the app and offline mode cut off an external script. For this reason applications get separate modules that are vendored, that is, copied into the project as a file. The app does not fetch a script from outside.
A tester who finds a problem in a build presses the button of the module, and the report goes the same way as a report from the site.
Module for webview and Tauri: bugfix-app.js
For in-app bug reporting on webview and Tauri, the file bugfix-app.js is self-contained and does not depend on a framework. What it brings with it:
- an interface inside an isolated shadow DOM;
- an offline queue in localStorage;
- a device identifier;
- detection of the platform and of the font scale;
- switching on with the
enabledflag, usually for test builds only.
Two calls make up its API:
BugfixApp.init({ project, version, enabled, position, color, button })
BugfixApp.send('bug', text, contact)init adds the floating button and the form. send works without any interface of its own and suits apps that already have a button of their own.
The screenshot is taken when the build contains html2canvas. Without it the message goes out without a picture and the module does not crash.
Module for Flutter: bugfix_flutter.dart
Flutter apps get in-app bug reporting from the file bugfix_flutter.dart. It covers the same job with the tools of the framework:
- a screenshot of the root
RepaintBoundarysaved as PNG; - a queue that tells “no network” apart from “rejected on the merits”;
- a pause of 16 seconds between sends, because the anti-spam rule allows one message per 15 seconds;
- a list “My requests” with the correspondence and the unread replies;
- the context of the app.
One inbox for the site and the app
Messages from apps and from sites go into one table under a shared project key. The owner sees them together and receives the same automatic task and the same reply to the author as for a site message.
A message has one of four kinds: bug, idea, confusion or other. Familiar synonyms (unclear, question, feature, error, crash) are mapped to them automatically. An unfamiliar word becomes other, so a message is never lost because of a label.
Typical cases: a tester reports a problem from a test build of an app; a product has both a site and an app and wants one list of problems; an app with its own interface calls send from its own button.
Connecting in-app bug reporting step by step
- Add the address of the Bugfix database to
connect-srcin the security policy of the app. - Vendor the file, as a copy in your project, and do not use an external loader.
- Initialize the module with a gate for test builds.
The canonical addresses of the files are https://bugfix.asibots.pro/bugfix-app.js and https://bugfix.asibots.pro/bugfix_flutter.dart.
Limits to plan for
In-app bug reporting comes with a few boundaries:
- The external loader of the website widget is not an option inside an app. The module has to be a vendored file.
- The
enabledflag is meant for test builds, so a module is usually not active in a production build. - A screenshot in the webview module needs html2canvas in the build. Otherwise reports go without one.
- The Flutter module waits 16 seconds between sends.
- The kind of a message is one of four values. Anything else is stored as other.
Frequently asked questions
Why can't the website tag be used for in-app bug reporting?
The security policy of an app and offline mode cut off an external script. That is why apps use modules that are copied into the project: bugfix-app.js for webview and Tauri, bugfix_flutter.dart for Flutter.
What happens if the build has no html2canvas?
The message goes out without a screenshot, and the module does not crash.
What happens to a message kind that Bugfix does not know?
Allowed kinds are bug, idea, confusion and other. Known synonyms are mapped to them, and an unknown word becomes other, so the message is not lost.