I'm doing something like:
fetch(url, ...)
.then(...)
.catch(e => {
// Handle error here
});
On Firefox, however, whenever I navigate to a another page too quickly (ie. without all requests finishing), it will throw an error, which will trigger error handling in the UI
TypeError: "NetworkError when attempting to fetch resource"
I've found the discussion around this topic here, but it falls short of providing a workaround for the time being.
https://bugzilla.mozilla.org/show_bug.cgi?id=1280189
Wondering if there is any way to detect an abort by the browser, and handle it gracefully.
I've seen similar questions, but all those seem to be related with CORS, and are a different problem that this one.
Edit: reproduction in the before mentioned ticket:
window.onbeforeunload = function(event) {
console.log("navigating away")
};
console.log("starting")
fetch("https://jsfiddle.net/").then(x => {
console.log("fetched")
}).catch(e => {
console.log("caught", e)
})
window.location = "https://jsfiddle.net/";
Returns:
caught TypeError: "NetworkError when attempting to fetch resource."
After some back and forth I managed to implement Inch High abort controller approach - developer.mozilla.org/en-US/docs/Web/API/AbortController
Related
I implemented the navigator.share() function in my code. It works on the first call, but when I try to call it again through the same event, I get the NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
I found out that this is usually caused by navigator.share() not being directly called by user input, formerly also if called in a fetch callback. However, today it should be allowed as part of a fetch callback. The behaviour is also strange considering that it works on the first try and just fails on consecutive ones.
Any ideas would be highly appreciated.
Most probably you are not catching the exception the API throws when the user cancels the share. I just tried canceling and then sharing again for a random article on my blog, and it worked. Here is the code I use:
const share = async () => {
try {
await navigator.share({
title: '',
text: `“${document.title}” by #tomayac:`,
url: document.querySelector('link[rel=canonical]').href,
});
} catch (err) {
console.warn(err.name, err.message);
}
};
Problem:
I am seeing following error in my browser console, I don't want a solution to resolve this error.
I want a solution to remove from the browser console.
GET https://logo.clearbit.com/objectivepartners.com net::ERR_ABORTED 404
I came to following solution which can handle consoling but while using fetch
it is not working:
console.defaultError = console.error.bind(console);
console.errors = [];
console.error = function(){
if (!arguments[0].includes("404")) {
console.defaultError.apply(console, arguments);
}
console.errors.push(Array.from(arguments));
}
fetch("https://logo.clearbit.com/objectivepartners.com").then(response => {
if (response.ok) {
console.log("okay");
}
}).catch(error => {
console.error("404"); // WILL NOT SHOW IN BROUSER CONSOLE
console.error("error"); // WILL SHOW IN BROWSER CONSOLE
});
Here,
I want if arguments include 404 then do not console it in the browser.
But on the fetch request failure, it includes 404 still it consoling, that I do not want to be happening
could it be possible that when fetch fail i can disable using in this code (by changing) or any other way?
Unfortunately, I didn't find any solution to resolve at the client-side or using javascript.
But I resolve this by creating an endpoint to API side and giving URL to that API to check that URL is valid or not, based on API response I handled in fetch
I'm using Firebase-Firestore on Javascript (web) with a Progressive web app. I ran into this error:
INTERNAL ASSERTION FAILED: Got result for empty write pipeline
Because Firebase runs asynchronously with XHR requests, it was difficult to determine the exact source of the error - it seemed like any onSnapshot, set or update was throwing this error for me.
And after that first error came a flurry of other errors:
INTERNAL ASSERTION FAILED: AsyncQueue is already failed: Error: FIRESTORE (5.3.0) INTERNAL ASSERTION FAILED: Got result for empty write pipeline
I thought my operation was pretty normal - just using the API set(), update() , onSnapshot() functions when it happened.
It's not a mission critical error - the code runs fine, but I'm hit with a couple thousand errors when I open debug, so it's prohibitive in that regard.
For my PWA I was using a cache-first, web-reupdate model which returns cachedResponse but also fetch()es the response and caches the fetched response.
Anyone have any insights?
It was the PWA! Using the PWA, I was catching all GET requests, including Firebase's own GET's. Filtering to ensure CORS requests don't return from cache fixed the problem.
To solve this, I added this code to my PWA:
self.addEventListener("fetch", event => {
if (event.request.method == "GET") {
event.respondWith(
(async function() {
const cachedResponse = await cache.match(event.request, {
ignoreSearch: true
});
// Returned the cached response if we have one, otherwise return the network response.
if (cachedResponse && event.request.type!="cors") {
//AVOID CORS FOR THINGS LIKE FIREBASE
updateCache(event);
return cachedResponse;
} else return await updateCache(event);
})()
);
} else {
event.respondWith(fetch(event.request));
}
});
If you're new to the PWA space, want to get a jump start to ANY PWA project, or want to just 'share notes', the repo with the full comprehensive PWA file is here: https://github.com/acenturyandabit/genUI/blob/master/Javascript/pwa.js
I've personally put a lot of time into this so I hope it helps :)
To make a long story short:
I'm building node app which making a request with https (the secure version of http). Whenever I miss-configure my request options, I'm having this error:
Node.js Hostname/IP doesn't match certificate's altnames
Great... except of the fact that the entire request code is wrapped with a valid try..catch block (which works just fine.. checked that already). The code is basically something like this:
try
{
https.request(options, (response) =>
{
// no way I making it so far this that error
}).end();
}
catch(ex)
{
// for some reason.. I'm not able to get here either
}
What I intend to do is to simply handle that error within my try..catch block
After reading some posts I've learned that this behavior is mainly because the tls module is automatically process the request and therefore making this error - this is a nice piece of information but it doesn't really help me to handle the exception.
Some other suggested to use this option:
rejectUnauthorized: false // BEWARE: security hazard!
But I rather not... so.. I guess my questions are:
Handling an error with a try..catch block should work here..right?
If not - is this behavior is by-design in node?
Can I wrap the code in any other way to handle this error?
Just to be clear - I'm not using any third-party lib (so there is no one to blame)
Any kind of help will be appreciated
Thanks
You need to add an 'error' event handler on the request object returned by https.request() to handle that kind of error. For example:
var req = https.request(options, (response) => {
// ...
});
req.on('error', (err) => {
console.log('request error', err);
});
req.end();
See this section in the node.js documentation about errors for more information.
I am getting error with status 302
But while trying to log error in catch I am getting 200
post(url, data, successCallBack, errCallback) {
return this.http.post(apiDomain + url, JSON.stringify(data), {
headers: this.headers
}).catch(this.handleError).subscribe(
(res) => {
successCallBack(res.json());
},
(err) => {
errCallback(err);
}
);
}
private handleError(error: any) {
let errMsg = (error.message) ? error.message :
error.status;
console.log(error.status); // log is 200
console.log(error)
console.error(errMsg);
return Observable.throw(errMsg);
}
Requirement I want to send another post call on redirect URL redirects.
How to get Redirect URL.
Need help.
Late answer I know, but for anyone stumbling across this.
The short answer is you can't as the browser handles 302's itself and won't tell angular anything about that. What you can do is set-up an interceptor style class that monitors what is going on.
Google for angular2 http interceptor or similar, it's a little beefier than your example above and can monitor every XHR connection. An example is here:
https://www.illucit.com/blog/2016/03/angular2-http-authentication-interceptor/
What this now allows is that any connection will come through your interceptor. As we won't be able to monitor 302s, we have to think about what might happen. For example in my example the request suddenly changes the url to something with my auth in it.
Great so my 1st bit of pseudo code would be:
if (response.url.contains('my-auth string')) {
redirect....
}
I can also see on the headers provided that instead of application/json I've suddenly gone to text/html. Hmm, that's another change I can check for:
if (response.url.contains('my-auth string') && response.headers['content-type'] == 'text/html') {
redirect....
}
You may have other parameters you can check, however these were good enough to detect a redirect for me. Admittedly this is with respect to being redirected to login and not another example, hopefully you get enough distinct changes check for you to decide whether you have got a 302.