Bug 252465 – In PWA, HTML Video Element may be unable to play stream from 'getUserMedia()'

• Component: WebRTC
• Status: RESOLVED FIXED

I get the media stream by 'getUserMedia()' and make it the source of HTML Video Element. Then I play the video after video is loaded.

It works all fine in Safari.

But the problem is that when it runs in PWA, it somestimes doesn't work. HTML Video Element is unable to play the stream, although the stream is active.

It reproducts after closing the PWA, reopen it right away, and repeat the operation above for several times(maybe 10+ times). 'vide.play()' is always in 'pending'. Also, when it reproducted, I find the icon which indicates the camera is in use will appear but disappear soon. If I close the PWA at this time, wait for 5s or so, and then reopen the PWA，it backs to normal. 

Reproduct both in iPhone 12 mini IOS 16.3 and iPad Pro Generation 3 IOS 15.7.2.

Test code：https://github.com/Cube-J/pwa_camera_test/blob/main/helloworld-pwa.html
Run: https://cube-j.github.io/pwa_camera_test/helloworld-pwa.html

Created attachment 465049 [details]
reproduce the bug

[Radar WebKit Bug Importer]

<rdar://problem/105874017>

[Chris]

I'm having the EXACT same problem and I've literally been banging my head against a wall for weeks now. The mediaStream shows that it has a track and it's 'live', not 'muted' and 'enabled' but the camera icon on the top-right either doesn't show or it just shows the red icon and not the green 'dot' and the camera definitely does not work (just black).

I'm kind of relying on this working as it's a fundamental part of a web application that forms the crux of my business.

[Chris]

It seems to happen randomly as OP mentions but I've also noticed you can instantly 'kill' the camera by simply pulling down the control center from the top of the screen. Probably not a webkit bug but more an iOS problem.

[youenn fablet]

> I'm having the EXACT same problem and I've literally been banging my head
> against a wall for weeks now. The mediaStream shows that it has a track and
> it's 'live', not 'muted' and 'enabled' but the camera icon on the top-right
> either doesn't show or it just shows the red icon and not the green 'dot'
> and the camera definitely does not work (just black).

If the camera icon does not show up, the track should be ended.
Can you provide a sysdiagnose ([e-mail]) in the case the track is not ended and video element does not display it?

> I've also noticed you can instantly 'kill' the camera by simply pulling down the control center from the top of the screen.

For this one, the track readyState should get to ended, the ended event should happen. You should be able to restart capture.

[Chris]

Created attachment 465228 [details]
iPad 6th Gen - iOS 16.3.1

[Chris]

> If the camera icon does not show up, the track should be ended.
> Can you provide a sysdiagnose ([e-mail]) in the case the track is
> not ended and video element does not display it?

ips file in comment 6 - the camera icon flashes on screen briefly OR it does reappear but without the green dot - the mediastream is showing as active and the track is there and enabled, not muted and with a readystate of 'live', but the camera does not function

> For this one, the track readyState should get to ended, the ended event
> should happen. You should be able to restart capture.

Yes, you're right - this is a different issue

[Tim F]

We are also having this issue using our PWA with the Dynamsoft drivers License scanning tool.  We have spent a few months now working with them to finally come to the conclusion that this bug is the root cause of our issue.  Because this is a core function of our companies PWA is is critical to resolve this bug.  We are willing to provide any feedback necessary to help if needed however it sounds like the information in the bug ticket covers it pretty well. Thank you for escalating this issue and we hope it is resolved soon.

[Chris]

(In reply to Tim F from comment #8)
> We are also having this issue using our PWA with the Dynamsoft drivers
> License scanning tool.  We have spent a few months now working with them to
> finally come to the conclusion that this bug is the root cause of our issue.
> Because this is a core function of our companies PWA is is critical to
> resolve this bug.  We are willing to provide any feedback necessary to help
> if needed however it sounds like the information in the bug ticket covers it
> pretty well. Thank you for escalating this issue and we hope it is resolved
> soon.

It's reassuring to know I'm not the only one on the planet going crazy with this bug!

Unfortunately after a few emails back and forth with @youennfablet he seems to have ghosted me - so not sure if any discovery was made or if this bug is on Apple's radar :(

I made a hilariously poorly shot video of my troubleshooting and evidence of the bug in progress here https://www.icloud.com/photos/#030hsgwXgkDqnhiMINrrxANEA

[youenn fablet]

If someone can easily reproduce the issue, can you check what the video track muted value (https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/muted) is?
I would expect it to be muted=true.

[Chris]

(In reply to youenn fablet from comment #10)
> If someone can easily reproduce the issue, can you check what the video
> track muted value
> (https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/muted) is?
> I would expect it to be muted=true.

In my linked video you can see that initially the track is muted, but after restarting the camera it still fails to load even while the track is not muted (the camera indicator is displayed but the green dot isn’t). No amount of relaunching the app fixes this problem and only a reboot of the iPad resolves it

I wrestled with this bug for many months but I think I finally discovered what triggers it. It seems (to me) that it is triggered when you close the app while a portion of the video is off-screen, or after it has been sent off-screen. 

Two ways that seem to reliably reproduce the bug:
1. Have the video element/recording be bigger than the screen and part of the video is clipped or off-screen, then close the app.
2. Have no part of the video element be off screen, but send it off screen for example by using a text input that brings up the keyboard, then close the app.

After either of those 2 things happen, the app will no longer be able to play the stream from getUserMedia(), even after closing and reopening the app. #2 is especially frustrating for my situation because I prompt users to input a title for their recording, which can trigger the bug if users close the app while on that page. This only happens while the app is in PWA mode on iOS, never while using the Safari browser on iOS, and never on a Mac or other PC with either Safari or Chrome.

The only way I've found to recover functionality is to either restart the device like mentioned by Chris, or what has worked for me is closing the app while the prompt that asks the users to Allow the app to access microphone and camera is visible on screen.

[Chris]

(In reply to thompsoncwt from comment #12)
> I wrestled with this bug for many months but I think I finally discovered
> what triggers it. It seems (to me) that it is triggered when you close the
> app while a portion of the video is off-screen, or after it has been sent
> off-screen. 
> 
> Two ways that seem to reliably reproduce the bug:
> 1. Have the video element/recording be bigger than the screen and part of
> the video is clipped or off-screen, then close the app.
> 2. Have no part of the video element be off screen, but send it off screen
> for example by using a text input that brings up the keyboard, then close
> the app.
> 
> After either of those 2 things happen, the app will no longer be able to
> play the stream from getUserMedia(), even after closing and reopening the
> app. #2 is especially frustrating for my situation because I prompt users to
> input a title for their recording, which can trigger the bug if users close
> the app while on that page. This only happens while the app is in PWA mode
> on iOS, never while using the Safari browser on iOS, and never on a Mac or
> other PC with either Safari or Chrome.
> 
> The only way I've found to recover functionality is to either restart the
> device like mentioned by Chris, or what has worked for me is closing the app
> while the prompt that asks the users to Allow the app to access microphone
> and camera is visible on screen.

Amazing work!

This explanation fits perfectly with my application use case- my app is basically a wizard interface that flips through multiple panels, showing and hiding div elements- one of those div elements is the 'picture taking' stage which contains the canvas and video elements that have the stream attached.. to improve the UX I basically call getUserMedia() before the 'picture taking' stage appears and leave it running when the user proceeds to the next step.

This has to be why the bug is so common for me!

What I will do is test my app by calling getUserMedia() only while the picture taking stage is on screen, I'll then have it stop the stream before the div is hidden- just to see if I can ever trigger the bug.

I would really love to see this fixed so hopefully the more we can keep this thread alive the greater our chances will be...

(In reply to thompsoncwt from comment #12)
> I wrestled with this bug for many months but I think I finally discovered
> what triggers it. It seems (to me) that it is triggered when you close the
> app while a portion of the video is off-screen, or after it has been sent
> off-screen. 
> 
> Two ways that seem to reliably reproduce the bug:
> 1. Have the video element/recording be bigger than the screen and part of
> the video is clipped or off-screen, then close the app.
> 2. Have no part of the video element be off screen, but send it off screen
> for example by using a text input that brings up the keyboard, then close
> the app.
> 
> After either of those 2 things happen, the app will no longer be able to
> play the stream from getUserMedia(), even after closing and reopening the
> app. #2 is especially frustrating for my situation because I prompt users to
> input a title for their recording, which can trigger the bug if users close
> the app while on that page. This only happens while the app is in PWA mode
> on iOS, never while using the Safari browser on iOS, and never on a Mac or
> other PC with either Safari or Chrome.
> 
> The only way I've found to recover functionality is to either restart the
> device like mentioned by Chris, or what has worked for me is closing the app
> while the prompt that asks the users to Allow the app to access microphone
> and camera is visible on screen.

After avoiding the two situations mentioned above, my app works fine(in iPhone mini12 IOS 16.3). However, after I upgraded my iPhone to ios 16.4 today, the bug comes back!!!

[Chris]

(In reply to cube from comment #14)
> (In reply to thompsoncwt from comment #12)
> > I wrestled with this bug for many months but I think I finally discovered
> > what triggers it. It seems (to me) that it is triggered when you close the
> > app while a portion of the video is off-screen, or after it has been sent
> > off-screen. 
> > 
> > Two ways that seem to reliably reproduce the bug:
> > 1. Have the video element/recording be bigger than the screen and part of
> > the video is clipped or off-screen, then close the app.
> > 2. Have no part of the video element be off screen, but send it off screen
> > for example by using a text input that brings up the keyboard, then close
> > the app.
> > 
> > After either of those 2 things happen, the app will no longer be able to
> > play the stream from getUserMedia(), even after closing and reopening the
> > app. #2 is especially frustrating for my situation because I prompt users to
> > input a title for their recording, which can trigger the bug if users close
> > the app while on that page. This only happens while the app is in PWA mode
> > on iOS, never while using the Safari browser on iOS, and never on a Mac or
> > other PC with either Safari or Chrome.
> > 
> > The only way I've found to recover functionality is to either restart the
> > device like mentioned by Chris, or what has worked for me is closing the app
> > while the prompt that asks the users to Allow the app to access microphone
> > and camera is visible on screen.
> 
> After avoiding the two situations mentioned above, my app works fine(in
> iPhone mini12 IOS 16.3). However, after I upgraded my iPhone to ios 16.4
> today, the bug comes back!!!

Yep I also changed my app according to these potential triggers but the bug is still triggering, it seems to be after the iPad screen times out and you come back to it later on :(

As a side note it also annoys me that pulling down the control center kills the camera - this doesn't happen in native apps. You can usually restart the camera with another getUserMedia() but there's no way programmatically you can detect when somebody has pulled the control center down.

Bug is still present in 16.4 - come on Apple!!!

[Tim F]

With the new iOS 16.4 update, safari is not setting the correct default camera that corresponds with the hardware and operating system for the SDK scanner tool using a PWA. We tested iOS 16.4 using an iPhone 10 through 12 and it is not defaulting to the correct camera setting which will render the SDK scanner unusable, however, if you use an iPhone 14 Pro it just so happens the default camera setting matches the safari suggested camera for the hardware and operating system so it will work (hilariously enough).  I do not believe it is connected to this bug report but could get convoluted.

[Tim F]

***So far the below issue seems to be resolved in 16.4.1***
 
With the new iOS 16.4 update, safari is not setting the correct default camera that corresponds with the hardware and operating system for the SDK scanner tool using a PWA. We tested iOS 16.4 using an iPhone 10 through 12 and it is not defaulting to the correct camera setting which will render the SDK scanner unusable, however, if you use an iPhone 14 Pro it just so happens the default camera setting matches the safari suggested camera for the hardware and operating system so it will work (hilariously enough).  I do not believe it is connected to this bug report but could get convoluted.

[Pasquale]

We have the exact same issue. 
iOS 16.4.1 / iPhone 12

If we add the PWA to home screen and then relaunch it in standalone mode from the home screen, we're unable to re-access the camera stream. Note: the pill on top left that should notify the user about the use of the camera flash and get stuck in a sort of loop.

[Mariano Goni]

I tried a lot of things to solve this. As of 16.4.1 no simple solution is available, it looks like a problem with how the service worker caches info. 

The only solution I found to "reset" the camera state without restarting the iPhone or completely erasing Safari cache, is to have a simple web page that opens and closes the camera, added to the home screen. 

You have to hit open cam, it will fail, then hit the close button, and then close this mini app. After this, this and the other app camera start working, normally only once, or perhaps 4 times in a row, until something happens and you have to do the reset. 

It's been 2 weeks of trial and error to finally find out it's an iOS bug. Where can we report it?

[Chris]

(In reply to Mariano Goni from comment #19)
> I tried a lot of things to solve this. As of 16.4.1 no simple solution is
> available, it looks like a problem with how the service worker caches info. 
> 
> The only solution I found to "reset" the camera state without restarting the
> iPhone or completely erasing Safari cache, is to have a simple web page that
> opens and closes the camera, added to the home screen. 
> 
> You have to hit open cam, it will fail, then hit the close button, and then
> close this mini app. After this, this and the other app camera start
> working, normally only once, or perhaps 4 times in a row, until something
> happens and you have to do the reset. 
> 
> It's been 2 weeks of trial and error to finally find out it's an iOS bug.
> Where can we report it?

Thanks for testing this out- it seems like this bug has been present for a very long time. I'm not sure where else this can be raised but Apple are present in this thread and almost certainly should be aware of it- whether or not they will be able to or willing to fix it is another matter!

[NielsSec]

Hoping to hear anything from Apple on this. Is this currently being worked on?

There doesn't seem to be an acceptable workaround for now. We use the video element to show users their camera stream for a barcode scanner. Having the video play in a small element without clipping anything doesn't seem to reliably fix the issue. In some cases the camera video still won't play. Very frustrating because this has a big impact on user satisfaction.

Restarting the iOS device fixes the issue temporarily, but this is not a feasible workaround for users.

[Fred S]

For us PWA camera often returns a black feed. Always works in browser but PWA returns black.

[Fred S]

Created attachment 466394 [details]
Camera on PWA returns black image

[Chris]

Can confirm still exact same problem on iOS 16.5, easily replicated as per comment 12

[Eric Pascal]

I have the exact same bug, easy to reproduce on Iphone 11 bug a lot harder on iPhone X, I have a truncated video also running to have it fill the whole screen.
Need to close and reopen several times the application to reproduce but seems to come back after a time. 
Thank you for the feedbacks if I find a solution I will post-it.

[Eric Pascal]

(In reply to youenn fablet from comment #10)
> If someone can easily reproduce the issue, can you check what the video
> track muted value
> (https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/muted) is?
> I would expect it to be muted=true.

the muted is true for me

[Eric Pascal]

(In reply to youenn fablet from comment #5)
> > I'm having the EXACT same problem and I've literally been banging my head
> > against a wall for weeks now. The mediaStream shows that it has a track and
> > it's 'live', not 'muted' and 'enabled' but the camera icon on the top-right
> > either doesn't show or it just shows the red icon and not the green 'dot'
> > and the camera definitely does not work (just black).
> 
> If the camera icon does not show up, the track should be ended.
> Can you provide a sysdiagnose ([e-mail]) in the case the track is
> not ended and video element does not display it?
> 
> > I've also noticed you can instantly 'kill' the camera by simply pulling down the control center from the top of the screen.
> 
> For this one, the track readyState should get to ended, the ended event
> should happen. You should be able to restart capture.

the stream readyState is 0 when the problem occurs

[Eric Pascal]

I noticed that in this state if I call 

stream=await navigator.mediaDevices.getUserMedia({ video: { facingMode: 'environment' } })

in the console, the camera turns on then off and a second time it turns on 

Yet the stream is not displayed in the browser, tried to recreate video tag. 
Did many test, it seems that the browser is in a specific state. 

But now the camera indicator is on.

[Eric Pascal]

I noticed in that case that the indicator is red recording camera indicator, but the green dot is not displayed. When it works, the green dot is there but the red recording camera is not there.

[Eric Pascal]

Good news, I added a <input type="file" name="picture" accept="image/*" capture="user"></input>

in the page and clicked on it once.

And the stream began to work again and now I'm unable to have the problem again, it was persistent.

[Chris]

(In reply to Eric Pascal from comment #30)
> Good news, I added a <input type="file" name="picture" accept="image/*"
> capture="user"></input>
> 
> in the page and clicked on it once.
> 
> And the stream began to work again and now I'm unable to have the problem
> again, it was persistent.

I’ve just tried this and it doesn’t work for me, red icon comes back but the feed stays dead, testing on an iPhone 12.

Either way, it’s definitely not a suitable solution for a production application!

Is anyone besides youenn looking into this problem from Apple?

This can reliably be reproduced with the following device:

Model Number: MXCX2VC/A
iOS Version 16.5

Method: 
1) Open up an PWA that uses the camera.
2) Use the camera (however the PWA uses it, ultimately calling navigator.mediaDevices.getUserMedia()). It works normally.
3) Go to the app selection carousel (via swipe up from bottom, or double-tapping home button)
4) Swipe up on the PWA app's preview to close the app.
5) Open up the PWA app again
6) Go to the camera. It will be black/not showing. The following is returned from a call to navigator.mediaDevices.getUserMedia({ audio: false, video: true }):

MediaStreamTrack: {
contentHint: ""
enabled: true
id: <a-uuid-redacted>
kind: "video"
label: "Front Camera"
muted: true
onconfigurationchange: null
onended: null
onmute: null
onunmute: null
readyState: "live"
}

[Eric Pascal]

(In reply to rooke from comment #32)
> This can reliably be reproduced with the following device:
> 
> Model Number: MXCX2VC/A
> iOS Version 16.5
> 
> Method: 
> 1) Open up an PWA that uses the camera.
> 2) Use the camera (however the PWA uses it, ultimately calling
> navigator.mediaDevices.getUserMedia()). It works normally.
> 3) Go to the app selection carousel (via swipe up from bottom, or
> double-tapping home button)
> 4) Swipe up on the PWA app's preview to close the app.
> 5) Open up the PWA app again
> 6) Go to the camera. It will be black/not showing. The following is returned
> from a call to navigator.mediaDevices.getUserMedia({ audio: false, video:
> true }):
> 
> MediaStreamTrack: {
> contentHint: ""
> enabled: true
> id: <a-uuid-redacted>
> kind: "video"
> label: "Front Camera"
> muted: true
> onconfigurationchange: null
> onended: null
> onmute: null
> onunmute: null
> readyState: "live"
> }

Thank you, I confim the same observations.
I would add that it reproduces very easily the same way on iPhone 11/12, less likely in iPhone X. It seems that when the network connection is fast, that the javascript loads fast (workers) it reproduces faster. If you close completely and reopen rapidly the application, it can be easily reproduced too.

Just to add to the information available, and provide a detection method, you can subscribe to the HTMLMediaElement's events (e.g. <video muted="true" />). In a normal situation, the events follow this order:

play 
waiting 
loadstart 
progress 
suspend 
durationchange 
loadedmetadata 
loadeddata 
canplay 
playing 
canplaythrough
timeupdate (repeatedly for every frame)

When the PWA camera issue rears its head, the events are cut off at 'suspend', i.e.:

play 
waiting 
loadstart 
progress 
suspend 
<then nothing>

This is the method to detect when you're in that situation. Just timeout on any of the missing 'expected' events, e.g. canplay:

let timeoutId: NodeJS.Timeout;

// set timeout of 3 seconds to wait for oncanplay
timeoutId = setTimeout(() => {
  // The video didn't get to 'canplay'
}, yourPreferredTimeoutInMillis);

videoElement.oncanplay = () => {
  // clear the timeout because oncanplay was called
  clearTimeout(timeoutId);
};

[Chris]

(In reply to rooke from comment #34)
> Just to add to the information available, and provide a detection method,
> you can subscribe to the HTMLMediaElement's events (e.g. <video muted="true"
> />). In a normal situation, the events follow this order:
> 
> play 
> waiting 
> loadstart 
> progress 
> suspend 
> durationchange 
> loadedmetadata 
> loadeddata 
> canplay 
> playing 
> canplaythrough
> timeupdate (repeatedly for every frame)
> 
> When the PWA camera issue rears its head, the events are cut off at
> 'suspend', i.e.:
> 
> play 
> waiting 
> loadstart 
> progress 
> suspend 
> <then nothing>
> 
> This is the method to detect when you're in that situation. Just timeout on
> any of the missing 'expected' events, e.g. canplay:
> 
> let timeoutId: NodeJS.Timeout;
> 
> // set timeout of 3 seconds to wait for oncanplay
> timeoutId = setTimeout(() => {
>   // The video didn't get to 'canplay'
> }, yourPreferredTimeoutInMillis);
> 
> videoElement.oncanplay = () => {
>   // clear the timeout because oncanplay was called
>   clearTimeout(timeoutId);
> };



This is really helpful, thank you

I’d been doing something similar already with a chained function call that executes after a timer is set to say the camera couldn’t be loaded. If the function succeeds and it progresses past “suspend” then the timer is cleared and the camera is displayed.

Being able to detect the problem was half the battle but obviously having an actual fix for this is the dream! In the meantime a work around to detect the issue and then get the camera working again without user input would be great, too…

[Chris]

Bug is still present in 16.6, tested on iPad 6th Gen and iPhone 12 Mini.

[Fabien R]

Bug is still present in 17.2 beta, tested on iPhone 12.

[Chris]

For a major bug that's existed since at least iOS 14- I'm shocked this still has no 'Assignee'

[Andre]

(In reply to Chris from comment #35)
> (In reply to rooke from comment #34)
> > Just to add to the information available, and provide a detection method,
> > you can subscribe to the HTMLMediaElement's events (e.g. <video muted="true"
> > />). In a normal situation, the events follow this order:
> > 
> > play 
> > waiting 
> > loadstart 
> > progress 
> > suspend 
> > durationchange 
> > loadedmetadata 
> > loadeddata 
> > canplay 
> > playing 
> > canplaythrough
> > timeupdate (repeatedly for every frame)
> > 
> > When the PWA camera issue rears its head, the events are cut off at
> > 'suspend', i.e.:
> > 
> > play 
> > waiting 
> > loadstart 
> > progress 
> > suspend 
> > <then nothing>
> > 
> > This is the method to detect when you're in that situation. Just timeout on
> > any of the missing 'expected' events, e.g. canplay:
> > 
> > let timeoutId: NodeJS.Timeout;
> > 
> > // set timeout of 3 seconds to wait for oncanplay
> > timeoutId = setTimeout(() => {
> >   // The video didn't get to 'canplay'
> > }, yourPreferredTimeoutInMillis);
> > 
> > videoElement.oncanplay = () => {
> >   // clear the timeout because oncanplay was called
> >   clearTimeout(timeoutId);
> > };
> 
> 
> 
> This is really helpful, thank you
> 
> I’d been doing something similar already with a chained function call that
> executes after a timer is set to say the camera couldn’t be loaded. If the
> function succeeds and it progresses past “suspend” then the timer is cleared
> and the camera is displayed.
> 
> Being able to detect the problem was half the battle but obviously having an
> actual fix for this is the dream! In the meantime a work around to detect
> the issue and then get the camera working again without user input would be
> great, too…

Still not working on 16.5.1 :(

Can you show an example of your code how you fixed it with a workaround? I tried a lot but nothing worked for me.

[Chris]

(In reply to Andre from comment #39)
> (In reply to Chris from comment #35)
> > (In reply to rooke from comment #34)
> > > Just to add to the information available, and provide a detection method,
> > > you can subscribe to the HTMLMediaElement's events (e.g. <video muted="true"
> > > />). In a normal situation, the events follow this order:
> > > 
> > > play 
> > > waiting 
> > > loadstart 
> > > progress 
> > > suspend 
> > > durationchange 
> > > loadedmetadata 
> > > loadeddata 
> > > canplay 
> > > playing 
> > > canplaythrough
> > > timeupdate (repeatedly for every frame)
> > > 
> > > When the PWA camera issue rears its head, the events are cut off at
> > > 'suspend', i.e.:
> > > 
> > > play 
> > > waiting 
> > > loadstart 
> > > progress 
> > > suspend 
> > > <then nothing>
> > > 
> > > This is the method to detect when you're in that situation. Just timeout on
> > > any of the missing 'expected' events, e.g. canplay:
> > > 
> > > let timeoutId: NodeJS.Timeout;
> > > 
> > > // set timeout of 3 seconds to wait for oncanplay
> > > timeoutId = setTimeout(() => {
> > >   // The video didn't get to 'canplay'
> > > }, yourPreferredTimeoutInMillis);
> > > 
> > > videoElement.oncanplay = () => {
> > >   // clear the timeout because oncanplay was called
> > >   clearTimeout(timeoutId);
> > > };
> > 
> > 
> > 
> > This is really helpful, thank you
> > 
> > I’d been doing something similar already with a chained function call that
> > executes after a timer is set to say the camera couldn’t be loaded. If the
> > function succeeds and it progresses past “suspend” then the timer is cleared
> > and the camera is displayed.
> > 
> > Being able to detect the problem was half the battle but obviously having an
> > actual fix for this is the dream! In the meantime a work around to detect
> > the issue and then get the camera working again without user input would be
> > great, too…
> 
> Still not working on 16.5.1 :(
> 
> Can you show an example of your code how you fixed it with a workaround? I
> tried a lot but nothing worked for me.

Hi Andre- there is no fix... currently the only way to get the camera back is to restart the iPad/iPhone or wait (for quite a long time, apparently) and close/re-open the home screen app

If you want to detect when the camera can't be loaded you can do something like this in JS:

======================
  var cameraFailTimer
  cameraStarting = true
  const constraints = {
    audio: false,
    video: { 
      facingMode: 'user'
    }
  }
  navigator.mediaDevices.getUserMedia(constraints)
    .then((mediaStream) => {
      cameraView.srcObject = mediaStream
      clearTimeout(cameraFailTimer)
      cameraFailTimer = setTimeout(function(){
        // Camera isn't working - do something on screen
        cameraStarting = false
        
      }, 12000)
      cameraView.onloadedmetadata = () => {
        cameraView.play().then(function() {
          // Camera is working - continue as normal
          clearTimeout(cameraFailTimer)
          cameraStarting = false
          callback(true)
        })
      }
    })
    .catch((err) => {
      // Camera isn't working - do something on screen
      cameraStarting = false
      callback(false)
    })
======================

[youenn fablet]

Pull request: https://github.com/WebKit/WebKit/pull/15370

[ssjblue197]

if your app doesn't need to use service worker then remove it, and it will work perfectly. I checked and found that even if you register a service worker that does nothing, the same problem will occur. This error is caused by ios operating system.

[Mariano Goni]

That's the whole point of the thread. PWA's use service workers.I had to resort to not using one an degrading the functionality of the app (like not being able to sent instant notifications to the system).

[Eric Pascal]

(In reply to ssjblue197 from comment #42)
> if your app doesn't need to use service worker then remove it, and it will
> work perfectly. I checked and found that even if you register a service
> worker that does nothing, the same problem will occur. This error is caused
> by ios operating system.

I think this may be due to the speed of initialization of PWA that doesn't need to load from network and thus go very fast. My issue appears mainly when I launch camera quickly at start, but not always :(

[Eric Pascal]

Apparently a patch has been submitted, check the description it's kinda suttle, the bugs seems to come from the OS but a workaround has been implemented.
Don't know when it will but present in Safari

[Chris]

It’s been submitted as pull request but that’s one request amongst 590 others so who knows when it could be merged and be present in the live code

[EWS]

Committed 265986@main (bbf602136b81): <https://commits.webkit.org/265986@main>

Reviewed commits have been landed. Closing PR #15370 and removing active labels.

[Chris]

I can see the PR has been merged successfully (thanks youenn!) - do we know how long before this will be included in the safari code in iOS?

[Matt]

I've been struggling with the same issue (iOs 16.5.1 on Iphone 14) and like Tim F this is critical to my business that a solution is quickly deployed for this... 

One question: Comment 42 suggests that if you don't register the service worker then the issue doesn't occur.  That isn't my experience, but maybe I'm doing something wrong, are you sure?

[Chris]

(In reply to Matt from comment #49)
> I've been struggling with the same issue (iOs 16.5.1 on Iphone 14) and like
> Tim F this is critical to my business that a solution is quickly deployed
> for this... 
> 
> One question: Comment 42 suggests that if you don't register the service
> worker then the issue doesn't occur.  That isn't my experience, but maybe
> I'm doing something wrong, are you sure?

I don’t think it has anything to do with service workers tbh. My app doesn’t register one at all and I still have this problem when it’s in the “added to Home Screen” environment

[Matt]

Thanks Chris, aligns with my experience.  I've tried not registering and also removing sw.js completely from the file structure but makes no difference.

[Chris]

Fix didn't make it into 16.6 it seems- bug occurred for me immediately (iPhone 12 Mini)

[Eric Pascal]

(In reply to youenn fablet from comment #41)
> Pull request: https://github.com/WebKit/WebKit/pull/15370

Could you tell us how long it will take to be integrated in safari iOS ?

[youenn fablet]

I'll try to update this thread when this becomes available in iOS beta.
I don't think it is available yet in any iOS beta.

[Mariano Goni]

Don't know why the Status can say that, but here again to communicate that now, it doesn't work even without a service worker.

Without a service worker and just with add to the home screen, the camera was opening fine. Today I just tested and the app is unusable, the camera closes instantly. 

Still works on the Ukrainian browser "Bluefy", so one wonders, if it is better to rely on a software maintained by people that are undergoing a war? . I think yes, it's more reliable than to have Apple make bugs randomly appear.

[Chris]

(In reply to Mariano Goni from comment #55)
> Don't know why the Status can say that, but here again to communicate that
> now, it doesn't work even without a service worker.
> 
> Without a service worker and just with add to the home screen, the camera
> was opening fine. Today I just tested and the app is unusable, the camera
> closes instantly. 
> 
> Still works on the Ukrainian browser "Bluefy", so one wonders, if it is
> better to rely on a software maintained by people that are undergoing a war?
> . I think yes, it's more reliable than to have Apple make bugs randomly
> appear.

this bug has been present at least since iOS14 and perhaps even further back than that- certainly I've experienced it for 2 years now since I first launched my affected product.

The problem (hopefully) has been resolved now, we're just waiting for the code to appear in the OS

[Fabien R]

I just installed iOS 17.4 and the bug no longer seems to be present. I tried to reproduce the bug but I can't anymore.

[Tim F]

How can you download iOS 17.4 when the latest version is iOS 16.6?

[Tim F]

(In reply to Fabien R from comment #57)
> I just installed iOS 17.4 and the bug no longer seems to be present. I tried
> to reproduce the bug but I can't anymore.

How can you download iOS 17.4 when the latest version is iOS 16.6?

[Fabien R]

It's available in beta

[Chris]

(In reply to Fabien R from comment #57)
> I just installed iOS 17.4 and the bug no longer seems to be present. I tried
> to reproduce the bug but I can't anymore.

Just tested this myself and unfortunately the bug is still there.
I’m assuming you mean version 17.0 Beta release 4

[Mariano Goni]

Can you confirm if you are testing with or without service worker installed?

[Mariano Goni]

On iOS 17.0 (beta) still present, and even got worse with a simple page just trying to open the camera only (added to home screen).

[Chris]

(In reply to Mariano Goni from comment #62)
> Can you confirm if you are testing with or without service worker installed?

Yep no service worker at all

Testing on an iPad 7th Generation.

Initially I thought it might be resolved but after exiting the app and then returning to it half an hour or so later (after using the Netflix app) the bug immediately occurred

[Mariano Goni]

Try installing free browser "Bluefy" and see if it works or not. Browser has a fullscreen option too.

[poincare]

I have a PWA where the camera is also used. This problem has been going on for years.

[Mariano Goni]

Update from BETA 17: I cleaned up safari cache (history now) and the camera started working again, with no issues. Haven't tried with a service worker yet. Will post results when checked.

[Mariano Goni]

Checked with service worker installed, it works.
It may only start failing if the camera is incorrectly closed. 
In that case, clearing safari cache will reset it.
Hope this fix survives future updates!!!

[Chris]

Until youenn has confirmed that the code from his fix is present in the iOS build we have to assume this is not fixed still.

I'm testing again now but I did successfully recreate the bug last week when testing on iOS 17.0 beta release 4.

[Chris]

(In reply to Chris from comment #69)
> Until youenn has confirmed that the code from his fix is present in the iOS
> build we have to assume this is not fixed still.
> 
> I'm testing again now but I did successfully recreate the bug last week when
> testing on iOS 17.0 beta release 4.

Again, I was able to recreate the bug very easily by opening the home screen app once and using the camera, closing it (cleanly), using Netflix for 20 mins and then re-opening the home screen app. Camera fails immediately

[Andre]

I tested it on an iPhone Se 2020 with IOS 17 beta 4 and still not working with serviceworker

[Mariano Goni]

Check Settings/Safari/Advanced/Feature Flags to allow service workers and a lot of other flags like permissions api

[poincare]

Is the issue still present in ios 17 beta 5? Anyone testing it?

[Andre]

I am testing the camera with the latest beta update on an iPhone SE 2020 with a pwa and a registered serviceworker. For now it seems to work for me. I am testing further but until now no problem anymore.

[youenn fablet]

*** Bug 234509 has been marked as a duplicate of this bug. ***

[Philipp Barth]

iPhone 12 mini IOS 16.6.1 bug still present for approx 7-10 tries, then gone for some tries (opening and closing standalone webapp) then reappears for approx 10 tries.
SW registered
muted = false

problem appears exactly as described above.

on
iphone SE 1st GEN iOS 15.7.3 
NO SW
muted= false

bug doesn't occur at all

does anyone still have trouble with this?

[Chris]

(In reply to Philipp Barth from comment #76)
> does anyone still have trouble with this?

It's been fixed in iOS 17+

[Steven]

I had this exact same issue that plagued me for months. When I told my users to update to iOS 17.5, it started working again.

But now I get reports that it fails again.

I tested on my own ipad with iOS 17.5.1 and I was able to see a different error this time with

A MediaStreamTrack ended due to a capture failure.

Same thing, have to restart the iPad to fix the problem...

This is also a critical portion of my business. Anybody else started to experience this issue?

[Chris]

(In reply to Steven from comment #78)
> I had this exact same issue that plagued me for months. When I told my users
> to update to iOS 17.5, it started working again.
> 
> But now I get reports that it fails again.
> 
> I tested on my own ipad with iOS 17.5.1 and I was able to see a different
> error this time with
> 
> A MediaStreamTrack ended due to a capture failure.
> 
> Same thing, have to restart the iPad to fix the problem...
> 
> This is also a critical portion of my business. Anybody else started to
> experience this issue?

I was thinking just yesterday that this thread might come back up in my email notifications and it has!

I've seen it myself (on 17.5.1 iPhone 15) where after a permission deny the camera never revives again until after a restart.

I was really hoping it was a one off but sounds like I'm going to have to start testing again....

[Steven]

> I was thinking just yesterday that this thread might come back up in my
> email notifications and it has!
> 
> I've seen it myself (on 17.5.1 iPhone 15) where after a permission deny the
> camera never revives again until after a restart.
> 
> I was really hoping it was a one off but sounds like I'm going to have to
> start testing again....

I will keep an eye out as well because the ugly workaround is having the app run on the browser instead of shared on the home app.

The funny thing is that my PWA is being used on the Web, but I also have a mobile app that shares the same code for the camera functionality, but this app I released it with React Native inside a WebView (react-native-webview) which is also using WebKit and I never experience any issue. Only if used within WebKit on the browser as a shared home screen app.

[youenn fablet]

@Chris, @Steven, have you tried the latest iOS 18 betas?
If so, and it reproduces there, please open a new bug, noting this is specific to Home Screen web apps.
You can also send me a sysdiagnose privately at [e-mail].

Thanks,
   Youenn

[Steven]

(In reply to youenn fablet from comment #81)
> @Chris, @Steven, have you tried the latest iOS 18 betas?
> If so, and it reproduces there, please open a new bug, noting this is
> specific to Home Screen web apps.
> You can also send me a sysdiagnose privately at [e-mail].
> 
> Thanks,
>    Youenn

Thanks for the quick follow up Youenn.

I have not yet tried iOS 18 betas as I am currently trying to get you log files while the camera crash is happening because I am not sure how to reproduce the bug yet.

I was able to generate a sysdiagnose file, but I am trying to figure out where I should be looking for in order to see if I correctly captured the problem during the analytics session. I will send you the sysdiagnose dump privately.

Thanks

[Chris]

(In reply to Steven from comment #82)
> (In reply to youenn fablet from comment #81)
> > @Chris, @Steven, have you tried the latest iOS 18 betas?
> > If so, and it reproduces there, please open a new bug, noting this is
> > specific to Home Screen web apps.
> > You can also send me a sysdiagnose privately at [e-mail].
> > 
> > Thanks,
> >    Youenn
> 
> Thanks for the quick follow up Youenn.
> 
> I have not yet tried iOS 18 betas as I am currently trying to get you log
> files while the camera crash is happening because I am not sure how to
> reproduce the bug yet.
> 
> I was able to generate a sysdiagnose file, but I am trying to figure out
> where I should be looking for in order to see if I correctly captured the
> problem during the analytics session. I will send you the sysdiagnose dump
> privately.
> 
> Thanks

I've still not done any debugging yet but I've replicated the problem repeatedly now but simply changing the camera permission to Deny and then back to Allow.

Even just doing a permissions query while the permission is set to Deny- like this: 

navigator.permissions.query({ name: 'camera' })

Is enough to permanently break it - only a device restart brings it back to life.

So you don't even need to do a getUserMedia call- just flipping the permission to Deny and back to Allow will cause the bug

[Chris]

Further update- after updating both my iPhone 15 and iPad 6th Gen to 17.6.1- I’m unable to replicate the issue at all now.

Fingers crossed it was a problem specific to 17.5(1)

[Mariano Goni]

Bug reappeared on iOS 18.01 
Camera works on browser, shuts off after seconds in webapp (added to home screen)

can someone open a new bug for this?

[Jeroen]

We have currently three known users with this bug on the following devices:
IPhone 13,       iOS 18
IPhone 15,       iOS 17.6.1
IPhone 14 PRO,   iOS 18.0.1


Error in console : "A MediaStreamTrack ended due to a capture failure"
Camera works in browser, shuts off after seconds in PWA (added to home screen)
There is no way to restore this (restart phone, update IOS, reinstall PWA, clear history and cache of safari).


So this is still not fixed!

[Jeroen]

(In reply to Jeroen from comment #86)
> We have currently three known users with this bug on the following devices:
> IPhone 13,       iOS 18
> IPhone 15,       iOS 17.6.1
> IPhone 14 PRO,   iOS 18.0.1
> 
> 
> Error in console : "A MediaStreamTrack ended due to a capture failure"
> Camera works in browser, shuts off after seconds in PWA (added to home
> screen)
> There is no way to restore this (restart phone, update IOS, reinstall PWA,
> clear history and cache of safari).
> 
> 
> So this is still not fixed!

Also we updated one device to iOS 18 Public Beta / iOS 18.1, and that fixed it..
Don't know if it was the update self that fixed it or just the fact that it was updated.

[Wilde Mossel]

Also would like to +1 this by reporting a regression on this issue: occurs on specifically iOS 18.0.1 again, on a PWA added to home screen. It wasn't noticed on 18.0.

Problem now is worse though, as it doesn't start or show the camera at all anymore. Shutting down the app, or even reinstalling the PWA nor rebooting the device also doesn't fix it this time. It basically bricks the app.

[Mariano Goni]

Update: on iPhone 13 pro and iOS 18.01 after restarting the phone, it works correctly.

[Jeroen]

(In reply to Jeroen from comment #87)
> (In reply to Jeroen from comment #86)
> > We have currently three known users with this bug on the following devices:
> > IPhone 13,       iOS 18
> > IPhone 15,       iOS 17.6.1
> > IPhone 14 PRO,   iOS 18.0.1
> > 
> > 
> > Error in console : "A MediaStreamTrack ended due to a capture failure"
> > Camera works in browser, shuts off after seconds in PWA (added to home
> > screen)
> > There is no way to restore this (restart phone, update IOS, reinstall PWA,
> > clear history and cache of safari).
> > 
> > 
> > So this is still not fixed!
> 
> Also we updated one device to iOS 18 Public Beta / iOS 18.1, and that fixed
> it..
> Don't know if it was the update self that fixed it or just the fact that it
> was updated.

Update: after updating the IPhone 15 to iOS 18.0.1 it was resolved for that device, but we also had this issue on a device with 18.0.1 so it's not fixed in that version but something reset a state with the update..

[shier]

(In reply to Mariano Goni from comment #89)
> Update: on iPhone 13 pro and iOS 18.01 after restarting the phone, it works
> correctly.

on iPhone 15  and iOS 18.01 after clear cache and restarting the phone, it works correctly.