Loading screen remains till clicked on
Sparkmasterflex opened this issue · 11 comments
Hello,
I implemented BBCore in our system a while ago and within the last week or so the loading screen never goes away unless the user clicks on it.
Did something change?
It appears that it's ready after a short while because my camera goes on, I can see my green light on my MacBook
Keith is this happening just in Chrome perchance?
On Wed, Feb 3, 2016 at 5:29 PM, Keith Raymond notifications@github.com
wrote:
Hello,
I implemented BBCore in our system a while ago and within the last week or
so the loading screen never goes away unless the user clicks on it.Did something change?
[image: screen shot 2016-02-03 at 2 27 56 pm]
https://cloud.githubusercontent.com/assets/726129/12801657/5f167acc-ca82-11e5-9d0a-669fa9c985ae.pngIt appears that it's ready after a short while because my camera goes on,
I can see my green light on my MacBook—
Reply to this email directly or view it on GitHub
#1.
PATRICK MCDAVID
VP of Technology
[image: BombBomb | Face to Face with more people, more often]
W: BombBomb.com http://www.bombbomb.com
[image: BombBomb | Face to Face with more people, more often]
It looks like Chrome's throttling "feature". Normally there's a play button, so that's odd. Either way, to stop the throttling feature from happening: Ensure the flash content is loaded from the same domain/protocol and/or ensure the resolution of the frame is at least 398x298.
Otherwise, the intended behavior from Chrome's point of view is for the user to interact(e.g., click) the flash object before allowing it to run in full.
@bbCharles and @spicykoala thanks for the replies.
Yes it appears to be chrome. It works in firefox as expected. So where does that leave us?
Are you able to request the frame at a larger size? The issue is related to the resolution. The same domain option isn't applicable here - but if you include the frame at a resolution larger than or equal to 398x298 the problem should go away.
Or are you already including it a size larger than that? If that's the case then this issue may be different - do you have a link to the issue to help us troubleshoot?
This has to do with Chrome thinking the small flash object is an Ad and
disabling it until the user touches it.
On Thu, Feb 4, 2016 at 11:35 AM, Spicykoala notifications@github.com
wrote:
Are you able to request the frame at a larger size? The issue is related
to the resolution. The same domain option isn't applicable here - but if
you include the frame at a resolution larger than or equal to 398x298 the
problem should go away.—
Reply to this email directly or view it on GitHub
#1 (comment).
So... how do I set the resolution?
Or better yet, is there another way around this? The widget is the size we need it at.
You can pass in height/width in as options. It will set the frame size of the flash object (the resolution of the video created won't change). I don't think there's another way around it, it's an intended Chrome "feature" that auto-pauses flash objects that aren't deemed as essential. Chrome determines this based on resolution and domain-policy, the latter of which wouldn't apply to this scenario. Does that all make sense?
I tried adding the height/width to options of startVideoRecorder() and no dice.
$('.init-bombbomb').click(send_bombbomb)
function send_bombbomb(e) {
api = new BBCore(accessToken: <key>)
api.startVideoRecorder({
target: $('.bb-container'),
width: 400,
height: 300,
function(vid_info) {
...
});
}
And it is still not getting past the Loading screen.
Just wanted to follow up on this. We're doing some final testing on the new recorder and have added a more helpful overlay for when flash is being throttled so the user won't be confused. I'll look at the API issue as well to see if there are any bugs causing the width/height to not be respected.
This has been resolved with improvements made to the flash component.