In javascript, how can I uniquely identify one browser window from another which are under the same cookiedbased sessionId - ajax

The users of my web application may have more than one browser window open and pointed to the same page. I would like the state of certain things in the page (loaded via ajax) to be retained across postbacks. I can either store in a cookie or on my server. Either way, I can't think of how I can distinguish each window.
For example, say user Bob has two browser windows open to the ListOfSomething page. Each list has a LoadedPageNumber attribute which I need to persist. Otherwise users always end up on page 1 when they refresh. Bob might have loaded browser window 1 and pointed it to page 5 and then loaded browser window 2 and pointed it to page 14. If I just store the attribute based on session id, Bob will get page 14 in window 1 if he refreshes it.
Note that my state variables are actually much more complex than this simple example and my inability to persist them could lead to big problems (weaknesses in my app).
I need some kind of browser window id or something. It of course needs to be a cross-browser solution (IE6+, Wekbit?+, FF2+)
Any ideas?
Note on relevance: Keep in mind that this is useful also for the case where you're mixing older forms based pages with newer AJAX enabled items. Sometimes you need to postback the forms and you don't want to loose some client side state values.

you could set your own window name, the exact syntax escapes me right now, but you can use the current time and session id to create a unique id on window load, then use that id
This would be done the same way you set a name in the javascript window.open() function, (but you can do it to self, instead of new window)
googling shows:
self.window.name = myclass.getUniqueWindowId( thisSession );
UPDATE
Regarding your need to save this from refresh to refresh, i did some tests and it looks to save it from refresh to refresh. Using Firefox 3, on initial load, the window name is blank, and pressing CTRL+R over and over, and the window name was populated. i then commented out the setting the name code and reloaded and it still retained the name.
<script type="text/javascript">
alert( self.window.name );
self.window.name = "blah";
</script>
UPDATE
I have to make noticed the comment below on jQuery's 'jquery-session' plugin, which really works and offers way more than what's discussed here.
Although, one should also make it clear that it relies on HTML5's Web Storage, not supported by older IE versions.
Corporate still depends heavily on IE 7 ('and below' here in Brazil).
Based on self.window.name, THE solution for everything non-compliant to HTML5, I offer the following code snippet as a cross-browser solution:
<script src="http://code.jquery.com/jquery-latest.min.js" type="text/javascript"></script>
<script language="javascript" type="text/jscript">
//----------------------------------------------------------------------
//-- guarantees that window.name is a GUID, and that it would
//-- be preserved whilst this window's life cicle
//----------------------------------------------------------------------
//-- window.name will be set to "GUID-<SOME_RANDOM_GUID>"
//----------------------------------------------------------------------
$(window).load(
function () {
//----------------------
var GUID = function () {
//------------------
var S4 = function () {
return(
Math.floor(
Math.random() * 0x10000 /* 65536 */
).toString(16)
);
};
//------------------
return (
S4() + S4() + "-" +
S4() + "-" +
S4() + "-" +
S4() + "-" +
S4() + S4() + S4()
);
};
//----------------------
if (!window.name.match(/^GUID-/)) {
window.name = "GUID-" + GUID();
}
}
) //--------------------------------------------------------------------
</script>
I found the GUID function here (for which I proposed some code clean-up).

You can use HTML5 session Storage ,just generate an unique id and set it on the session storage !
what is cool about that each window or tab has its own session storage.
for example :
if we run the following on 3 windows:
window 1:
sessionStorage.setItem('key' , 'window1');
window 2:
sessionStorage.setItem('key' , 'window2');
window 3:
sessionStorage.setItem('key' , 'window3');
sessionStorage.getItem('key' ); <<< this will return corresponding value on window!
window 1:
sessionStorage.getItem('key' ); returns window 1
window 2:
sessionStorage.getItem('key' ); returns window 2
window 3:
sessionStorage.getItem('key'); returns window 3
I believe you are trying to save a variable (separately on each tab/window).
sessionStorage works as charm.
The only problem you may face that browser should support HTML 5.

What about having your server randomly generate an ID and have that stored in the page (some javascript variable) when it's served? Then just include that ID in the ajax request. It wont' help on a browser refresh, but as long as the user leaves that page in place (and just lets the ajax stuff do its thing) it should work fine.

It's a long time ago, but the answer of Roy Rico helped me today, so I want to share my experience. To handle page refresh and page backbutton uses, I am doing it like that:
Your server checks if the browser sends the GUID with his request (only works with ajax or form submit)
If it is not there (browser refresh, backbutton) it just sends back a page with a small JavaScript script. This script creates the GUID and puts it into the window.name storage as described above. After that the script creates a form with the GUID as hidden field and submits it to the server. The action attribute uses the same URL as before (window.location.href)
--> Now the server recognizes the GUID and can deliver the content as needed.
Here is my code (the GUID I create on the server for security reasons, the syntax "${gUid} is from freemarker and just inserts the Guid from the server):
<script>
$(window).load(
function () {
if (!window.name.match(/^GUID-/)) {
window.name = "GUID-" + "${gUid}";
}
$('<form action='+window.location.href+' method="POST"><input type="hidden" name="X-GUID" id="X-GUID" value='+window.name+'></form>').appendTo('body').submit();
}
);
</script>
Hope that helps someone
By the way, this technique should only be used on "NON SEO PAGES", because of the need of JavaScript to get the content. But in general SEO pages have no need of identifying the tab session.
Of course nowadays you can make use of the HTML5 session storage, but I don't want to rely on that, because I also need older browser to work well.

In fact, with new Web Locks API you can acquire actual internal window id (a.k.a. clientId). LockManager.query() can provide info on held locks including owner's id. Might not work in some iframe context due to security restrictions, but in top window should generally be good.
function getCurrentWindowId() {
return new Promise((resolve) => {
let lockName;
tryGetLock(); // one attempt should almost always be enough
function tryGetLock() {
// generate some random lock name
lockName = 'get-self-id-' + (Math.random() * 0xffffffff >>> 0);
navigator.locks.request(lockName, { mode: 'exclusive', ifAvailable: true }, withLock);
}
function withLock(lock) {
// unsing setTimeout(0) here to execute client's code after releasing the lock
if (lock)
return navigator.locks.query()
.then(({ held }) => held.find(lock => lock.name === lockName).clientId)
.then(clientId => setTimeout(resolve, 0, clientId));
else {
// unlucky - just try another lock
setTimeout(tryGetLock, 0);
return Promise.resolve();
}
}
});
}
//usage
getCurrentWindowId().then(clientId => {
// do something with id
});
Works in Firefox 96 and Chrome 97. It feels like shame to make such awkward constructs just to get information that should be readily available.

window.name can be overwritten by custom javascript libraries, datetimepickers etc.
Instead of window.name I suggest you to use the DOM head meta tag to store your id
<html><head><meta id="windowID" content="{YOUR ID}">
After page is loaded, you have to load everything via ajax in that window, then you can attach this ID to every request as a header (or data) value. For example in JQuery with this code:
$(document)
.ajaxSend(function(event, jqXHR, ajaxOptions) {
jqXHR.setRequestHeader('windowID',
document.getElementById('windowID').content);
})
To use this solution, you have to have access to custom header values on server side. For example in Java servlet:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String windowName = request.getHeader("windowID");
If you store paging, sorting, filtering etc. information on server side as session attribute, you should store them separately attached to the separate window ID-s.

Related

logout and click back takes me to authenticated pages in Safari browser [duplicate]

Got an issue with safari loading old youtube videos when back button is clicked. I have tried adding onunload="" (mentioned here Preventing cache on back-button in Safari 5) to the body tag but it doesn't work in this case.
Is there any way to prevent safari loading from cache on a certain page?
Your problem is caused by back-forward cache. It is supposed to save complete state of page when user navigates away. When user navigates back with back button page can be loaded from cache very quickly. This is different from normal cache which only caches HTML code.
When page is loaded for bfcache onload event wont be triggered. Instead you can check the persisted property of the onpageshow event. It is set to false on initial page load. When page is loaded from bfcache it is set to true.
Kludgish solution is to force a reload when page is loaded from bfcache.
window.onpageshow = function(event) {
if (event.persisted) {
window.location.reload()
}
};
If you are using jQuery then do:
$(window).bind("pageshow", function(event) {
if (event.originalEvent.persisted) {
window.location.reload()
}
});
All of those answer are a bit of the hack. In modern browsers (safari) only on onpageshow solution work,
window.onpageshow = function (event) {
if (event.persisted) {
window.location.reload();
}
};
but on slow devices sometimes you will see for a split second previous cached view before it will be reloaded. Proper way to deal with this problem is to set properly Cache-Control on the server response to one bellow
'Cache-Control', 'no-cache, max-age=0, must-revalidate, no-store'
Yes the Safari browser does not handle back/foreward button cache the same like Firefox and Chrome does. Specially iframes like vimeo or youtube videos are cached hardly although there is a new iframe.src.
I found three ways to handle this. Choose the best for your case.
Solutions tested on Firefox 53 and Safari 10.1
1. Detect if user is using the back/foreward button, then reload whole page or reload only the cached iframes by replacing the src
if (!!window.performance && window.performance.navigation.type === 2) {
// value 2 means "The page was accessed by navigating into the history"
console.log('Reloading');
//window.location.reload(); // reload whole page
$('iframe').attr('src', function (i, val) { return val; }); // reload only iframes
}
2. reload whole page if page is cached
window.onpageshow = function (event) {
if (event.persisted) {
window.location.reload();
}
};
3. remove the page from history so users can't visit the page again by back/forward buttons
$(function () {
//replace() does not keep the originating page in the session history,
document.location.replace("/Exercises#nocache"); // clear the last entry in the history and redirect to new url
});
You can use an anchor, and watch the value of the document's location href;
Start off with http://acme.co/, append something to the location, like '#b';
So, now your URL is http://acme.co/#b, when a person hits the back button, it goes back to http://acme.co, and the interval check function sees the lack of the hash tag we set, clears the interval, and loads the referring URL with a time-stamp appended to it.
There are some side-effects, but I'll leave you to figure those out ;)
<script>
document.location.hash = "#b";
var referrer = document.referrer;
// setup an interval to watch for the removal of the hash tag
var hashcheck = setInterval(function(){
if(document.location.hash!="#b") {
// clear the interval
clearInterval(hashCheck);
var ticks = new Date().getTime();
// load the referring page with a timestamp at the end to avoid caching
document.location.href.replace(referrer+'?'+ticks);
}
},100);
</script>
This is untested but it should work with minimal tweaking.
The behavior is related to Safari's Back/Forward cache. You can learn about it on the relevant Apple documentation: http://web.archive.org/web/20070612072521/http://developer.apple.com/internet/safari/faq.html#anchor5
Apple's own fix suggestion is to add an empty iframe on your page:
<iframe style="height:0px;width:0px;visibility:hidden" src="about:blank">
this frame prevents back forward cache
</iframe>
(The previous accepted answer seems valid too, just wanted to chip in documentation and another potential fix)
I had the same issue with using 3 different anchor links to the next page. When coming back from the next page and choosing a different anchor the link did not change.
so I had
House 1
View House 2
View House 3
Changed to
House 1
View House 2
View House 3
Also used for safety:
// Javascript
window.onpageshow = function(event) {
if (event.persisted) {
window.location.reload()
}
};
// JQuery
$(window).bind("pageshow", function(event) {
if (event.originalEvent.persisted) {
window.location.reload()
}
});
None of the solutions found online to unload, reload and reload(true) singularily didn't work. Hope this helps someone with the same situation.
First of all insert field in your code:
<input id="reloadValue" type="hidden" name="reloadValue" value="" />
then run jQuery:
jQuery(document).ready(function()
{
var d = new Date();
d = d.getTime();
if (jQuery('#reloadValue').val().length == 0)
{
jQuery('#reloadValue').val(d);
jQuery('body').show();
}
else
{
jQuery('#reloadValue').val('');
location.reload();
}
});
There are many ways to disable the bfcache. The easiest one is to set an 'unload' handler. I think it was a huge mistake to make 'unload' and 'beforeunload' handlers disable the bfcache, but that's what they did (if you want to have one of those handlers and still make the bfcache work, you can remove the beforeunload handler inside the beforeunload handler).
window.addEventListener('unload', function() {})
Read more here:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/Using_Firefox_1.5_caching

How to get the current tab's history in a Web Extension in Firefox?

Is there an API that makes it possible to get the current tab's history in a Web Extension in Firefox? Just like when clicking and holding on the Back button, a dropdown will appear to show the current tab's history.
No. You cannot ask for the list for a certain tab by default.
You can, however, listen for the tab events onUpdated, onCreated etc. Using the tabId which stays the same, you can keep a list of URLs in a background script (background.js) which is always running if the addon is enabled.
You would do it like this:
let arr=[]; // At the top of background.js
browser.tabs.onCreated.addListener(handleCreated); // Somewhere in background.js
function handleCreated(tab) {
let tabId = tab.id;
if(arr[tabId]==null) arr[tabId] = [];
arr[tabId].push(url);
}
function getHistoryForCurrentTab(){
function currentTabs(tabs) {
// browser.tabs.query returns an array, lets assume the first one (it's safe to assume)
let tab = tabs[0];
// tab.url requires the `tabs` permission (manifest.json)
// We will now log the tab history to the console.
for(let url of arr[tab.id]){
console.log(url);
}
}
function onError(error) {
console.log(`This should not happen: ${error}`);
}
browser.tabs.query({currentWindow: true, active: true}).then(currentTabs, onError);
}
The above code is a proof of concept. Some improvements you will need to consider: implement onClosed which resets the tab history for that id (arr[tabId] = null), implement onUpdated (will be needed for sure, same logic as in handleCreated).
Links:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs

LightSwitch Tabbed screen in Browse template

I have a screen where we have 4 tabs, each tab should be displayed as per the login priority.
Ex:Department,Role,Employee,Screen are the tabs.
Each tab is having buttons to add,edit,remove the data.
by default when i log with any user its going to the first tab, but not all the users are having the first tab as their requirement.
how can i resolve this to do it dynamically in html client application
As covered towards the end of the following LightSwitch Team blog post, you can programmatically change the tab by using the screen.showTab method:
Creating a wizard-like experience for HTML client (Andy Kung)
However, in order to use this showTab API command when your screen is loading, its use needs to be delayed until the screen has fully displayed. This can be achieved in your screen's created method by using a combination of the jQuery mobile pagechange event (as the LightSwitch HTML Client uses jQuery mobile) and a setTimeout with a zero timeout (to delay the showTab until the loading screen is rendered).
The following shows a brief example of how you can use this approach to dynamically set the initial screen tab:
myapp.BrowseScreen.created = function (screen) {
var initialTabName = localStorage.getItem("Rolename") + "Tab";
$(window).one("pagechange", function (e, data) {
setTimeout(function () {
screen.showTab(initialTabName);
});
});
};
Based on your earlier post it appears that you're using LocalStorage to track your logged in user and their role.
On this basis, the above example assumes that the user's role will be the factor dictating the tab they are shown when the screen loads (the screen is named BrowseScreen in the above example).
It also assumes that your tabs are named after each employee role (suffixed with the text 'Tab') e.g. a user who is assigned the role 'DepartmentManager' would be directed to a tab called 'DepartmentManagerTab'.
Whilst slightly more involved, if you'd prefer to avoid the pagechange and setTimeout it's possible to customise the LightSwitch library to introduce a new navigationComplete screen event. This new event is ideal for executing any operations dependent upon the screen having fully rendered (such as navigating to a different tab using the showTab function).
If you'd like to introduce this additional event, you'll need to reference the un-minified version of the LightSwitch library by making the following change in your HTML client's default.htm file (to remove the .min from the end of the library script reference):
<!--<script type="text/javascript" src="Scripts/msls-?.?.?.min.js"></script>-->
<script type="text/javascript" src="Scripts/msls-?.?.?.js"></script>
The question marks in the line above will relate to the version of LightSwitch you're using.
You'll then need to locate the section of code in your Scripts/msls-?.?.?.js file that declares the completeNavigation function and change it as follows:
function completeNavigation(targetUnit) {
msls_notify(msls_shell_NavigationComplete, { navigationUnit: targetUnit });
var screen = targetUnit.screen;
var intialNavigation = !screen.activeTab;
var selectedTab = targetUnit.__pageName;
if (screen.activeTab !== selectedTab) {
callNavigationUnitScreenFunction(targetUnit, "navigationComplete", [intialNavigation, selectedTab]);
screen.activeTab = selectedTab; // Set at the end of the process to allow the previous selection to be referenced (activeTab)
}
}
function callNavigationUnitScreenFunction(navigationUnit, functionName, additionalParameters) {
var screenObject = navigationUnit.screen;
var constructorName = "constructor";
var _ScreenType = screenObject[constructorName];
if (!!_ScreenType) {
var fn = _ScreenType[functionName];
if (!!fn) {
return fn.apply(null, [screenObject, navigationUnit].concat(additionalParameters));
}
}
}
You can then use this new event in your screens as follows:
myapp.BrowseScreen.navigationComplete = function (screen, navigationUnit, intialNavigation, selectedTab) {
if (intialNavigation) {
var initialTabName = localStorage.getItem("Rolename") + "Tab";
screen.showTab(initialTabName);
}
};
This event fires whenever a navigation event completes (including a change of tab) with the initialNavigation parameter being set to true upon the initial load of the screen and the selectedTab parameter reflecting the selected tab.
Although modification to the LightSwitch library aren't uncommon with some of the more seasoned LightSwitch developers, if you decide to go down this path you'll need to thoroughly test the change for any adverse side effects. Also, if you upgrade your version of LightSwitch, you'll need to repeat the library modification in the new version.

Back button not updating hash in iframe on IE

I have an application that uses a combination of the onhashchange event (for new browsers) and the hashchange plugin by Ben Alman (for old browsers) to track the history while making ajax calls or actions. Works like a charm in all browsers, back and forward buttons let the user navigate the actions that get recorded by changing the hash. So far so good. Now our page will be hosted in an iframe on a clients page in a diff domain(cross domain). Chrome kind of works but if you put to many changes in the history it stops working at some point (we can live with that). IE dosen't work at all. When I navigate our application by clicking on links and updating the hash new history items get created in the parent page but when I hit the back button the hash in the nested page is not updated therefore the hashchange event never fires. Anyone solved this problem before? Many thanks
Initialize the hash change event handling
if ("onhashchange" in window && !($j.browser.msie && $j.browser.version == '7.0')) {
window.onhashchange = function() {
var params = parseHash(location.hash)
if (params.tabId) {
if (getSelectedTabId() == params.tabId) return;
reloadPage(params.tabId);
}
};
}
else {// Plugin for older browsers
$j(window).bind('hashchange', function() {
var params = parseHash(location.hash)
if (params.tabId) {
if (getSelectedTabId() == params.tabId) return;
reloadPage(params.tabId);
}
});
}

Is it possible to open custom URL scheme with Google Chrome?

I have protocol (like http) with scheme managed with 3rd party App registered in Mac OS X.
I.e, x-someapp://someaction or something like that.
How can I open this URL with Google Chrome?
By default, Chrome starts searching in Google engine instead launching App and passing URL handling to it...
Safari launches some registered App. And it is right thing.
Firefox and Opera asks what to do... and I can launch App also.
But Chrome... Doesn't ask.
I even tried to write some HTML page with JavaScript inside to send XHttpRequest:
function _httpExecuteCallback()
{
if (httpRequestCallbackFunction != null) {
if (httpRequest.readyState == 4) {
if (httpRequest.status == 200) {
httpRequestCallbackFunction();
httpRequestCallbackFunction = null;
}
}
}
}
function _httpGet(url, callbackFunction)
{
httpRequest = false;
httpRequestCallbackFunction = callbackFunction;
httpRequest = new XMLHttpRequest();
httpRequest.onreadystatechange = _httpExecuteCallback;
httpRequest.open('GET', url, true);
httpRequest.send(null);
}
_httpGet('x-someapp://test',function(){})
No results also...
The current accepted solution has a problem with Chrome for SSL https. Watching the console log, Chrome blocks the request because it thinks the custom url protocol is not secure:
[blocked] The page at reports blah blah ran insecure content from customproto//blah blah
Here is a solution (this took me a few days to research):
<input type='button' value='Test Custom Url' onclick='exec()'>
<script>
function submitRequest(buttonId) {
var d = (window.parent)?window.parent.document:window.document
if (d.getElementById(buttonId) == null || d.getElementById(buttonId) == undefined) return;
if (d.getElementById(buttonId).dispatchEvent) {
var e = d.createEvent("MouseEvents");
e.initEvent("click", true, true);
d.getElementById(buttonId).dispatchEvent(e);
}
else {
d.getElementById(buttonId).click();
}
}
function exec(){
var d = (window.parent)?window.parent.document:window.document
var f = d.getElementById('customUrlLink')
if (f ) {f.parentNode.removeChild(f);}
var a = d.createElement('a');
a.href = 'mycustomproto://arg1';
a.innerHTML = "Link"
a.setAttribute('id', 'customUrlLink');
a.setAttribute("style", "display:none; ");
d.body.appendChild(a);
submitRequest("customUrlLink");
}
</script>
This code will not work for IE. I've found using this technique IE limits the argument of the custom protocol to less than 1000 where as using the iFrame technique IE will allow 2083 chars.
The only way to overcome the url limit in javascript is chuck the data and call multiple times. If anyone wants to take a stab at that, please let me know how it goes. I would like to use it.
To handle long urls in the executing app, pass a token into the app and have it go get the data from a url GET.
So for right now I am using one function for Chrome/FF and another function for IE.
These links helped me develop this solution:
https://superuser.com/questions/655405/custom-protocol-handler-not-working-in-chrome-on-ssl-page
Simulating a click in jQuery/JavaScript on a link
(wish I had known this a few days ago....hope this helps someone)
==================================================
Update: (8hr later)
==================================================
Jake posted a great solution for chrome: https://superuser.com/questions/655405/custom-protocol-handler-not-working-in-chrome-on-ssl-page
This works in chrome only:
window.location.assign("customprotocol://");
It will fail in an iframe so this is working:
var w = (window.parent)?window.parent:window
w.location.assign(service + '://' + data)
==================================================
Update: (weeks later)
==================================================
All of the examples of opening the custom protocol, including my own, have a "://" in the url. And this is what is causing the SSL warnings.
Turns out the solution is to change "://" to ":"
so do this:
src="x-myproto:query" .....
and the SSL warnings will go away.
==================================================
Follow: (after months of production use)
==================================================
This has been working well for chorme. Detect the browser and if chrome do this:
var w = (window.parent)?window.parent:window
w.location.assign('myproto://xyzabcdefetc')
For IE and other browsers I do something slightly different.
Note that browsers do impose a limit on how much data you can put in custom url protocol. As long as your string is under 800 chars this seems to be the magic number for which works in all browsers.
It looks like it's Google's locationbar parsing which is getting in the way.
The browser, however, does seem to handle custom URL schemes properly. Try this in your locationbar:
javascript:document.location = 'myscheme://whatever'
Any link on your page that uses the custom scheme should also do the right thing.
I found the solution that works with Chrome.
I use the IFRAME-way.
Example (with JQuery):
$("body").append('<span id="__protoProxy"></span>');
function queryWord(aWord)
{
var protoProxy = document.getElementById('__protoProxy');
if (protoProxy)
{
var word = aWord.replace('"','\"');
protoProxy.innerHTML = '<div style="display:none;"><iframe src="x-myproto://query?' + word + '"></iframe></div>';
}
}
queryWord('hello');
Here's a solution that also includes a redirect to the App Store / Play Store if the user doesn't have the app. It uses a setTimeout for this. It also makes use of an iframe to support more browsers. So this works on Chrome, and any other mobile browser. We use this as my company, Branch. Just modify the two links below to correspond to your URI and App Store link.
<!DOCTYPE html>
<html>
<body>
<script type="text/javascript">
window.onload = function() {
// Deep link to your app goes here
document.getElementById("l").src = "my_app://somepath";
setTimeout(function() {
// Link to the App Store should go here -- only fires if deep link fails
window.location = "https://itunes.apple.com/us/app/myapp/id123456789?ls=1&mt=8";
}, 500);
};
</script>
<iframe id="l" width="1" height="1" style="visibility:hidden"></iframe>
</body>
</html>
Again, this should work on any browser, thanks to the iframe.
If Chrome does not recognize the URL scheme, it defaults to a search.
This is what I see in Safari:
alt text http://img62.imageshack.us/img62/6792/clipboard02oh.jpg
and in Firefox:
alt text http://img138.imageshack.us/img138/9986/clipboard04xk.jpg
I believe the reason why Chrome defaults to search is that there are special google searches that use the colon.
E.g:
define: dictionary
filetype:pdf google chromium
This is one of the annoyances I have with Firefox, I have to jump to the "search box" rather than the address bar to execute these types of searches. Since Chrome does not have a separate search box like Firefox, IE and Safari have, this functionality is required.
Ajax requests won't get you around this.
Some weeks later ....
Looks like window.location.replace('myscheme://whatever') has full cross-browser support , works with chrome,firefox,safari,edge,opera see https://developer.mozilla.org/en-US/docs/Web/API/Location/replace

Resources