OpenTok is saying Safari 13 ScreenSharing is supported - opentok

The tokbox code for checking screensharing support is
OT.checkScreenSharingCapability(function (response) {
console.log('checkScreenSharingCapability response = ', response);
if (!response.supported || response.extensionRegistered === false) {
// This browser does not support screen sharing
console.log('screen share not supported');
}
});
The output in Safari 13 I get is
checkScreenSharingCapability response =
extensionInstalled: undefined
extensionRegistered: undefined
extensionRequired: undefined
supported: true
supportedSources: {screen: true, application: false, window: true, browser: false}
Therefore, it says it's supported, and does not work (the documentation says it's not supported). This is the same response that Chrome (supported) returns, so the resposne itself seems wrong using opentok/client 2.16.3

Related

How to fix 'TypeError: process.hrtime is not a function' in nativescript?

I am building a nativescript (+Angular) app with aws-amplify. Particular while using the S3 Storage API from aws-amplify, I get following error:
AWSS3Provider - get signed url error TypeError: process.hrtime is not a function. (In 'process.hrtime()', 'process.hrtime' is undefined)
I am using the following polyfills
(window as any).global = window;
(window as any).process = {
env: { DEBUG: undefined },
};
In my code, I check if process is not undefined.
if(typeof process !== 'undefined') {
Storage.get('fileassets/asset.txt')
.then(result => alert(result))
.catch(err => alert(err));
} else {
alert("process is undefined");
}
There is no alert raised, but it seems the native code S3Provider relies on process.hrtime, that can't be resolved in nativescript non{N} environment
I expect that aws-amplify API is successfully executed, as It have no control to hack that to avoid calling process.hrtime.

Firefox does not allow initiating unreliable WebRTC dataChannels?

In this example I'm using simple-peer, although I have tested with other implementations as well as my own. This seems to be an issue with creating the data channels.
The example from the github page of simple-peer has been slightly modified and used: https://github.com/feross/simple-peer
var init = location.hash === '#1';
var config = {reliable:true, maxRetransmits:0, ordered:false};
var p = new SimplePeer({ initiator: init, trickle: false, channelConfig: config })
console.log(p);
p.on('error', function (err) { console.log('error', err) })
p.on('signal', function (data) {
console.log('SIGNAL', JSON.stringify(data))
document.querySelector('#outgoing').textContent = JSON.stringify(data)
})
document.querySelector('form').addEventListener('submit', function (ev) {
ev.preventDefault()
p.signal(JSON.parse(document.querySelector('#incoming').value))
})
p.on('connect', function () {
console.log('CONNECT')
console.log(p);
console.log(p._channel);
if(init){
for(let i=0;i<100;i++){
p.send(JSON.stringify(i));
}
}
})
var rec = 0;
p.on('data', function (data) {
rec++;
console.log('data: ' + JSON.parse(data));
if(!init){
p.send(data);
}
if(rec >= 100){
console.log("got all");
}
})
When initiating the connection using Firefox(61.0.2 x64), the connection is forced to reliable, even when trying to set it to unreliable using unreliable:false, ordered:false and maxRetransmits:0. Only the ordered property is properly used.
When checking the connection object, the maxRetransmits and maxRetransmitTime settings are not exposed. If you connect to the Firefox connection using Chrome, both maxRetransmits and maxRetransmitTime will be set to 65535 in Chrome.
If you initiate the connection using Chrome, and connect using Firefox, the connection will be opened as unordered and unreliable in both Chrome and Firefox as well as having 0 maxRetransmits in Chrome.
Is this a bug, or am I missing something in setting up the connection to support unreliable data channels when initiating the connection using a Firefox browser?
Yes, this is a very unfortunate bug in Firefox tracked here that leads to 0 values being ignored for both maxRetransmits and maxPacketLifeTime. It has been fixed in Firefox 62. If you have to support Firefox < 62, you can work around this by setting maxPacketLifeTime to 1. But you should only do this in Firefox since older Chrome versions do not support maxPacketLifeTime. Yes, it's a mess.
Please note that there is no reliable member in the RTCDataChannelInit dictionary. There is also no maxRetransmitTime attribute on the RTCDataChannel interface. Both have been removed a long time ago.

Angular2 post request despite a XMLHttRequest error

I send a request to a remote API. It takes a little time for API to proceed on its side.
After this little waiting time, i can see in network tab a HTTP 200. In the response, I got the proper intended information. Everything on the API side works fine.
BIT on the console, I can see I encountered a XMLHttpRequest Error.
Why, especially if I have a XMLHttpRequest Error, the POST is completed with 200? Shouldn't it be "blocked" by Angular2?
The unintended result is: my file is correctly uploaded and handled by the API, but in Angular2, it triggers the ERROR part of my call.
If I use https://resttesttest.com/ for example, it seems to encounter the same error but it doesn't finalize the POST:
Oh no! Javascript returned an
HTTP 0 error. One common reason this might happen is that you
requested a cross-domain resource from a server that did not include
the appropriate CORS headers in the response.
Angular 2 Code for this call
this.http
.post(this.documentUploadAPIUrl, formData, options)
.subscribe(
res => {
this.responseData = res.json();
console.log(this.responseData);
console.log('Uploaded a blob or file!');
},
error => {
console.log('Upload failed! Error:', error);
}
);
try to set withCredential attribute of xmlHttpRequest to true, this will send credentials managed by the browser, in angular 2 you can do like this
import { RequestOptions } from '#angular/http';
this.http
.post(this.documentUploadAPIUrl, formData, this.post_options)
.subscribe(
res => {
this.responseData = res.json();
console.log(this.responseData);
console.log('Uploaded a blob or file!');
},
error => {
console.log('Upload failed! Error:', error);
}
);
post_options() {
return new RequestOptions({ method: 'post', withCredentials : true });
}

Error handling in Angular2

I'm working on an Angular 2 service returning data from a restful WebApi backend.
I'm trying to make it gracefully handle the service not being available however I'm getting unexpected information in the error responses.
Here's the code
update(fund, transactionId:string, showToastOnError: boolean, useCorrectUrl: boolean) {
let options = this.getStartCall();
options.headers.append("transaction-id", transactionId)
let url = fundsUrl + (useCorrectUrl ? "" : "breakTheUrl");
return this._http.put(url, JSON.stringify(fund), options)
.map(res => res.json())
//.retry(5)
.catch(errorResponse => {
let res = <Response>errorResponse;
let err = res.json();
let emsg = err ?
(err.error ? err.error : JSON.stringify(err)) :
(res.statusText || 'unknown error');
this._logger.log(emsg, "The fund was not updated", LogLevel.Error, showToastOnError);
return Observable.throw(emsg);
})
.finally(() => this._spinnerService.hide());
}
When I look at the network traffic I see the 404 error as expected.
My problem is in my catch function.
Here's the value's I'm seeing:
JSON.stringify(errorResponse)
{"_body":{"isTrusted":true},"status":200,"statusText":"Ok","headers":{},"type":3,"url":null}"
errorResponse.json()
bubbles: false
cancelBubble: false
cancelable: false
currentTarget: XMLHttpRequest
defaultPrevented: false
eventPhase: 2
isTrusted: true
isTrusted: true
lengthComputable: false
loaded: 0
path: Array[0]
position: 0
returnValue: true
srcElement: XMLHttpRequest
target: XMLHttpRequest
timeStamp: 1460990458693
total: 0
totalSize: 0
type: "error"
__proto__: XMLHttpRequestProgressEvent
Am I doing something wrong here or is this a bug in Angular2 beta 15?
Most of time, you have such a value for an error when the onerror callback is called on the underlying XHR object. See this line in the source code: https://github.com/angular/angular/blob/master/modules/angular2/src/http/backends/xhr_backend.ts#L70.
That said, it shouldn't occur for a 404 status code but rather on an error like net::ERR_NAME_NOT_RESOLVED.
404 status code is handled by the onload callback: https://github.com/angular/angular/blob/master/modules/angular2/src/http/backends/xhr_backend.ts#L37.
I made a test with the beta15 and I can't reproduce your problem.
See this plunkr: https://plnkr.co/edit/SB3KLZlbJT3wm9ATAE0R?p=preview.

FireFox marketplace in-app payments

I have added FireFox Marketplace in-app payments to my game pathuku using fxPay.
Everything seems to be working when i use the fakeProducts setting below:
fxpay.configure({fakeProducts: true});
When i try to use fxPay in Live i get the following in my console:
message
23:30:46.305 "opening" "GET" "to" "https://marketplace.firefox.com/api/v1/payments/https%3A%2F%2Fwww.pathuku.com/in-app/?active=1"1 fxpay.min.js:1:4761
error
23:30:46.681 "XHR error event:" error { target: XMLHttpRequest, isTrusted: true, lengthComputable: false, loaded: 0, total: 0, currentTarget: XMLHttpRequest, eventPhase: 2, bubbles: false, cancelable: false, defaultPrevented: false, timeStamp: 1432593046679000 }1 fxpay.min.js:1:4078
error
23:30:46.690 "Error getting products:ApiRequestError: received XHR error for path: /payments/https%3A%2F%2Fwww.pathuku.com/in-app/?active=1"1 main.js:1:10765
_eo/b.e5.fxpay.checkForPurcs/<() main.js:1
z() fxpay.min.js:1
A() fxpay.min.js:1
x() fxpay.min.js:1
t() fxpay.min.js:1
j() fxpay.min.js:1
A http OPTIONS request is made to
https://marketplace.firefox.com/api/v1/payments/https%3A%2F%2Fwww.pathuku.com/in-app/?active=1
The url seems to be working, but i don't understand why only a OPTIONS request is being made?
My game url is
https://marketplace.firefox.com/app/pathuku/
https://www.pathuku.com
Any help would be very welcome
This problem was being caused by the orignal JSON library, it added functions to the Object.prototype. This in turn caused the fxpay serialisation code to break. As JSON has been added to most browsers, I removed the reference to the old libabry and everything is now working.

Resources