Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Web: TypeError: null is not an object (evaluating '_nativeEnabledCompleter.completeError') on overlapping enable() calls

Open Beginner friendly
#150 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
dart, javascript
Domain
mobile, web-dev

Research direction

Start with lib/assets/no_sleep.js and trace how overlapping enable() calls handle _nativeEnabledCompleter and _playVideoCompleter in their promise handlers. Reproduce by calling WakelockPlus.enable() several times without awaiting in Safari. Done means overlapping calls no longer produce the reported TypeError or an unhandled rejection.

Written by the indexing model from the issue text.

Description

Version: 1.7.0. The same code is still in main.
Platform: Web, Safari / iOS PWA

Description

In lib/assets/no_sleep.js, all calls to enable() share the module-level _nativeEnabledCompleter. Overlapping enable() calls can end up using the same completer while each sends its own navigator.wakeLock.request('screen'). The first request to settle completes the completer and sets it to null. When the next request settles, its handler calls _nativeEnabledCompleter.completeError(...) on null; on success it calls .complete() instead.

The TypeError is thrown inside a .catch handler of a promise that nothing awaits. Dart code can't catch it, so it surfaces as an unhandled rejection. Our Sentry has about 19K events of it, mostly from Safari, where wakeLock.request often rejects with NotAllowedError.

Steps to reproduce

Call WakelockPlus.enable() several times without awaiting, for example on every route change, in Safari.

Suggested fix

In each enable() call, keep a local reference to the completer and use that reference in .then / .catch, instead of reading the shared variable:

var completer = _nativeEnabledCompleter
navigator.wakeLock.request('screen')
.then(function (wakeLock) { /* ... / completer.complete(); if (_nativeEnabledCompleter === completer) _nativeEnabledCompleter = null })
.catch(function (err) { /
... */ completer.completeError(errorMessage); if (_nativeEnabledCompleter === completer) _nativeEnabledCompleter = null })
return completer.future
_playVideoCompleter is handled the same way and has the same problem.

Workaround

On our side, we now run enable() / disable() one at a time and skip a call when the wakelock is already in the requested state.

Dominant language
Dart
Stars
110
Forks
98
Avg merge
9h 27m
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fluttercommunity/wakelock_plus

All issues in fluttercommunity/wakelock_plus

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.