I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Verify Feature Scope
I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
Problem Description
Currently, when performing long dictations on mobile devices (e.g., Android), if the phone screen locks during the recording session, the transcription process fails to capture the full audio, often resulting in only the first sentence being processed and the remainder of the recording being lost . Users have noted that this is a significant pain point for long-form voice input, as the system does not currently provide a way to recover audio if the automatic transcription fails.
Desired Solution you'd like
Proposed Implementation
Wake Lock Activation: Trigger the navigator.wakeLock.request('screen') method immediately upon starting an audio recording in the web interface.
Release: Release the wake lock wakeLock.release() automatically when the recording is stopped, paused, or if the transcription component is unmounted.
Handle Visibility Changes: Listen for the visibilitychange event to re-request the wake lock if the page becomes visible again, ensuring robust behavior even if the browser state fluctuates during the recording.
Alternatives Considered
A native Android App would have additional mechanisms to keep recording or keep Phone from sleeping.
Additional Context
Benefits
Data Reliability: Eliminates the risk of transcriptions being truncated or lost due to OS-level power saving or screen locking mechanisms .
Improved UX: Removes the need for users to manually keep their device awake during dictation, providing a seamless experience similar to native mobile applications.
Minimized Failure Points: By keeping the browser active, the environment remains stable for the audio processing API to finalize the transcription, rather than relying on the device to stay awake in the background.
Originally created by @tilllt on GitHub (Mar 27, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23145
### Check Existing Issues
- [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request.
### Verify Feature Scope
- [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
### Problem Description
Currently, when performing long dictations on mobile devices (e.g., Android), if the phone screen locks during the recording session, the transcription process fails to capture the full audio, often resulting in only the first sentence being processed and the remainder of the recording being lost . Users have noted that this is a significant pain point for long-form voice input, as the system does not currently provide a way to recover audio if the automatic transcription fails.
### Desired Solution you'd like
Proposed Implementation
- Wake Lock Activation: Trigger the navigator.wakeLock.request('screen') method immediately upon starting an audio recording in the web interface.
- Release: Release the wake lock wakeLock.release() automatically when the recording is stopped, paused, or if the transcription component is unmounted.
- Handle Visibility Changes: Listen for the visibilitychange event to re-request the wake lock if the page becomes visible again, ensuring robust behavior even if the browser state fluctuates during the recording.
### Alternatives Considered
A native Android App would have additional mechanisms to keep recording or keep Phone from sleeping.
### Additional Context
Benefits
- Data Reliability: Eliminates the risk of transcriptions being truncated or lost due to OS-level power saving or screen locking mechanisms .
- Improved UX: Removes the need for users to manually keep their device awake during dictation, providing a seamless experience similar to native mobile applications.
- Minimized Failure Points: By keeping the browser active, the environment remains stable for the audio processing API to finalize the transcription, rather than relying on the device to stay awake in the background.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @tilllt on GitHub (Mar 27, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23145
Check Existing Issues
Verify Feature Scope
Problem Description
Currently, when performing long dictations on mobile devices (e.g., Android), if the phone screen locks during the recording session, the transcription process fails to capture the full audio, often resulting in only the first sentence being processed and the remainder of the recording being lost . Users have noted that this is a significant pain point for long-form voice input, as the system does not currently provide a way to recover audio if the automatic transcription fails.
Desired Solution you'd like
Proposed Implementation
Wake Lock Activation: Trigger the navigator.wakeLock.request('screen') method immediately upon starting an audio recording in the web interface.
Release: Release the wake lock wakeLock.release() automatically when the recording is stopped, paused, or if the transcription component is unmounted.
Handle Visibility Changes: Listen for the visibilitychange event to re-request the wake lock if the page becomes visible again, ensuring robust behavior even if the browser state fluctuates during the recording.
Alternatives Considered
A native Android App would have additional mechanisms to keep recording or keep Phone from sleeping.
Additional Context
Benefits
Data Reliability: Eliminates the risk of transcriptions being truncated or lost due to OS-level power saving or screen locking mechanisms .
Improved UX: Removes the need for users to manually keep their device awake during dictation, providing a seamless experience similar to native mobile applications.
Minimized Failure Points: By keeping the browser active, the environment remains stable for the audio processing API to finalize the transcription, rather than relying on the device to stay awake in the background.
@tjbck commented on GitHub (Apr 1, 2026):
Addressed in dev.
@Classic298 commented on GitHub (Apr 1, 2026):
https://github.com/open-webui/open-webui/commit/0f8d7982e1a10dbc08f614eb271cc48610fc2f1f