Develop Reference

Trying to open external application in Browser prevents receiving socket.io emits

Lets rewrite my problem:
I will not provide any code because it would cost me too much payed worktime to extract the certain code samples from my project. On top of that i think its not code related, but browser/browser-security related.
When Chrome (Or Edge) tries to open an external application (No matter what application), an alert box pops open that asks if Chrome should open the external application.
Regardless if i open it or cancel the alert box, at this very moment all socket.io communication from my backend server isnt received anymore.
Before trying to open the external application or after a page refresh, everything runs fine.
Thats my problem, i apologise if some may not be able to understand the problem without me providing any code samples. I just hope someone comes by who already had that kind of problem and knows how to fix it.

I managed to go around this problem. I open my link to the external application directly in a new tab, which transfers the Alert Box to the newly opened tab.
The alert box seemed to have caused the error. When it opens in another tab, my main tab can still receive the backend emits.
Thanks for everyone who stumbled over this^^

Can a javascript code continue running throughout different web pages?

I am trying to code a javascript that runs throughout different web pages. The script should type something into a search bar, click search, click a result, then save each result text into an array. It looks something like:
function returnresults(queries){
arrayofcontent = [];
for each query {
type query in searchbar;
submit search;
result[0].click(); // go to first result
arrayofcontent.push(pagecontent.innertext);
}
return arrayofcontent;
}
The issue is that the script seems to be stopping after the script clicks search, which makes me think that the script is unloading itself when moving to another page, even though I'm typing the script directly into the javascript console in Google Chrome. Does anyone know how to tell Google Chrome to keep running the script even after moving between pages?

Short answer: No.
When you examine what's happening in a browser tab (including working with the console), you are only able to inspect what's loaded in that tab. If you navigate to another page in that tab, everything that was in memory from the last page is thrown out and the new page content is loaded.
What you need is to store the state of the script and then retrieve that state on the other page. Storing state can be done in many different ways (cookies, localStorage, sessionStorage, server-side databases) and you'll need to decide which is right for your architecture and use case.

if you want to inject your script to different web pages you can do that by developing a chrome extension . A extension enables to inject your script depending on your logic
here is the link to get started
https://developer.chrome.com/extensions/getstarted

Modernizr querying my page again after it has loaded?

Just noticed that the Controller for a page on my website was hit twice during a single refresh - checking the Network panel indicates that a second GET request (with no additional querystring parameters) was initiated by Modernizr.
Does anyone knows why this happens?

Redirect inside iframe in webview blocked in iOS

I'm currently working on a web application that is loaded inside an iframe inside a webview in a mobile app. As the user clicks a button, I perform an AJAX request, and once I get a successful response, I need to redirect the user to another page, by modifying window.top.location.href. This works in most situations, but in a certain iOS app, the redirect is not performed in a fair amount of cases.
I've tried to search for information about this, but given the peculiar setup, I haven't really been able to find anything. I don't control the iOS app, only the application running inside the iframe, so it's fairly hard to debug.
When the redirect fails, it does so silently. If I inspect the network traffic of the app, I can see that there's no request being made to the URL I try to redirect to.
My current hypothesis is that the redirect is being blocked as a security measure because it's not a direct result of a user interaction. You click on a button, the request is made, then the redirect happens a second or two later (depending on how long the request takes). I have tried to verify this in two ways:
Tap the screen in random, non-interactable spots while the reuqest is being made. If there is some kind of simple timer that is reset any time you interact with the device, to determine whether or not the redirect should be allowed, then tapping should make the redirect work. As far as I can tell, that is the case, but it's hard to verify that it isn't caused by something else.
Introduce an artificial delay before the redirect. So even if the request is done after 500ms, I wait an additional five seconds before doing the redirect. This should cause the redirect to fail consistently. Doing this also seems to support my hypothesis, but again, it's hard to know if that is the reason.
Has anyone else experienced this issue? If so, is my hypothesis correct, and did you come up with another workaround than adding a "Click to continue" button to actually do the redirect? Is there any documentation on this behavior anywhere?

I've faced the same issue. Emulation of a click does the trick:
document.getElementById('linkElementID').click();

How can i disable page reloading on history back?

I dont want to page reload when going to history back on my web pages.
When visitors are click back button on browser or press backspace key, my pages are reload. How can i disable reloading on history back or how can i activate real caching?
Thanks...

This behaviour stems from the browser's MO, not from your end.

you cannot prevent page reload. If your problem is POST pages relaoding, with messages alerting the user that POSTED data should be resend then you should look at "Redirect after Post" principle with 303 redirect on POST. It can fix some of theses behaviors.
The second thing you should look at is the cache headers you are sending with your pages responses, use PageSpeed extension of firebug or other tools, you'll have good hints on what headers you are actually sending and what setting you could adjust. When your cache headers are fine you'll see that some pages won't be recall and that some queries from the browser are not generating real GET+response 200 but 304-unchanged responses and headers queries. And if you go deeper on the analysis you'll find that the way the browser cache is working depends a lot of the browser.

The page is not reloaded when following a HTML bookmark within the same document. That is, all the browsing must happen using Javascript only and URL must stay the same until the # character. To handle the Back button correctly, you may need to use the onpopstate event. If you don't want any changes to the URL, you can use history.pushState().
If Javascript is not supported by the browser, you can do some tricks using CSS :target selector -- or just navigate the user to another page with reloading.
Note: I did not code a page like this, it is just my guess after reading an API reference page.