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);
}
});
}
Related
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
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
In my Nativescript app, the application starts with the login page. On iOS everything looks good, but on android, the username field is focused and the keyboard is showing. Is there a way to prevent this from happening?
So far I have tried:
Getting a reference of another element (a label) and calling lbl.focus() in the page's onLoaded event
getting a reference of the username textfield and calling txt.dismissSoftInput() and txt.android.clearFocus()
None of this worked. Is there another way to hide the keyboard when the page is loaded?
Thank you
I guess the username field is either textview or textfield. If so, try this on loaded callback:
var myTextview = page.getViewById("myTextView");
myTextView.dismissSoftInput();
So I ended up implementing a different solution. This may not be the best approach, but it serves its purpose in my case and I wanted to share it for those of you that face a similar scenario.
in page's loaded event I included this code:
if (page.android) {
var un = page.getViewById('username');
var p = page.getViewById('password');
un.android.setFocusable(false);
p.android.setFocusable(false);
setTimeout(function () {
un.android.setFocusableInTouchMode(true);
p.android.setFocusableInTouchMode(true);
}, 300);
}
The key here is the setTimeout function (Thanks Emil Oberg for pointing me to the right direction). As far as I understand, here is what is happening:
The page loads and we call setFocusable(false) on the only 2 text fields to prevent Android from setting the focus on them
Then we wait 300ms to allow Android to do its initialization
When the timeout executes, call setFocusableInTouchMode(true) to allow the fields to gain focus.
At this point the page is loaded without any fields to be in focus and with the keyboard hidden. If the user taps any of the fields the keyboard will appear and they can proceed to log in as usual.
As I mentioned, this may not be the best, or correct, approach, but works for me. Hope this can save someone the time to research the issue.
You want to clear the focus of the field in the loaded callback:
var searchBar = page.getViewById('my-search-bar-id');
if (searchBar.android) {
searchBar.android.clearFocus();
}
What about combining both tips above?
onClear(args) {
const searchBar = <SearchBar>args.object;
if (isAndroid && searchBar.android != undefined){//avoid random unpleasant error
setTimeout(() => { // the key here was this timeout
searchBar.android.clearFocus();
}, 1)
}
}
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.
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.