Bugzilla

I can reproduce this issue without using any headset, the difference between us and Chrome is that they still requested a driver wakelock after track ended, which prevents the computer going to sleep.

---

When audio is playing, both Firefox and Chrome requests proper wakelocks.

* Chrome
```
SYSTEM:
[DRIVER] Realtek Audio (INTELAUDIO\FUNC_01&VEN_10EC&DEV_0289&SUBSYS_10280BEB&REV_1000\5&54f1b19&0&0001)
An audio stream is currently in use.

EXECUTION:
[PROCESS] \Device\HarddiskVolume3\Program Files\Google\Chrome\Application\chrome.exe
Playing audio
``` 

* Firefox
```
SYSTEM:
[DRIVER] Realtek Audio (INTELAUDIO\FUNC_01&VEN_10EC&DEV_0289&SUBSYS_10280BEB&REV_1000\5&54f1b19&0&0001)
An audio stream is currently in use.

EXECUTION:
[PROCESS] \Device\HarddiskVolume3\Program Files\Firefox Nightly\firefox.exe
non-display request
```

---

After audio pauses or ends, Firefox would release both wakelock immediately, but Chrome would release its Process wakelock first, and then relase Driver wakelock later. As its Driver wakelock overlaps with next audio, Chrome is able to keep wakelock all the time during playing audio from Youtube Music playlist. But Firefox would lose wakelock for a very short period of time during the transition of the song. 

However, simply considering the behavior of when a wakelock should be hold. I think Firefox is more precise and correct. The problem for me is how Windows count the time for sleeping. When setting sleep time to `1 min`, what I expect is "being completely idle after 1 min". When playing audio shouldn't be considered as completely idle, however, that is not how Windows works. 

Touching keyboard or mouse would reset the sleep timer, but keeping playing audio or video doesn't seem affecting the timer. So the timer seems starting counting after the music starts, if no wakelock is being hold at any moment after 1 min, then the system would be going to sleep. That can also explain some weird issues we saw before about complaining the system going to sleep unexpectedly.

I can reproduce this issue without using any headset, the difference between us and Chrome is that they still requested a driver wakelock after track ended, which prevents the computer going to sleep.

---

When audio is playing, both Firefox and Chrome requests proper wakelocks.

* Chrome
```
SYSTEM:
[DRIVER] Realtek Audio (INTELAUDIO\FUNC_01&VEN_10EC&DEV_0289&SUBSYS_10280BEB&REV_1000\5&54f1b19&0&0001)
An audio stream is currently in use.

EXECUTION:
[PROCESS] \Device\HarddiskVolume3\Program Files\Google\Chrome\Application\chrome.exe
Playing audio
``` 

* Firefox
```
SYSTEM:
[DRIVER] Realtek Audio (INTELAUDIO\FUNC_01&VEN_10EC&DEV_0289&SUBSYS_10280BEB&REV_1000\5&54f1b19&0&0001)
An audio stream is currently in use.

EXECUTION:
[PROCESS] \Device\HarddiskVolume3\Program Files\Firefox Nightly\firefox.exe
non-display request
```

---

After audio pauses or ends, Firefox would release BOTH wakelocks immediately, but Chrome would release its Process wakelock first, and then relase Driver wakelock later. As its Driver wakelock overlaps with next audio, Chrome is able to keep wakelock all the time during playing audio from Youtube Music playlist. But Firefox would lose wakelock for a very short period of time during the transition of the song. 

However, simply considering the behavior of when a wakelock should be hold. I think Firefox is more precise and correct. The problem for me is how Windows count the time for sleeping. When setting sleep time to `1 min`, what I expect is "being completely idle after 1 min". When playing audio shouldn't be considered as completely idle, however, that is not how Windows works. 

Touching keyboard or mouse would reset the sleep timer, but keeping playing audio or video doesn't seem affecting the timer. So the timer seems starting counting after the music starts, if no wakelock is being hold at any moment after 1 min, then the system would be going to sleep. That can also explain some weird issues we saw before about complaining the system going to sleep unexpectedly.