I'll start this off with I have researched a bit, but no solution that solves what seems like it should be a simple JQM modification.
I have a wine review webapp that has the following view user flow:
http://5buckchuck.com/
Wine type > Wine list > Wine Details > Wine review (redirect via django backto ) > Wine Details updated from review
What I want to happen is when the user presses the back button it should go back to the wine list. What currently happens is the the Wine Detail view is reloaded. It takes pressing back three times to get back to the Wine List. :-(
My thoughts to solve this were two:
Splice the last 3 items from the history stack, if the last items in the history stack was Wine Review. I had a hard time trying to introspect the last history object to get the pageURL. I have a feeling that this solution is a bit too fragile though.
var last_hist = $.mobile.urlHistory.getActive();
last_hist.data.pageURL;
The second thought was to override the back button behavior so that the back button from the Wine Detail view would always go back to the Wine list view
$('div#wine_detail').live('pageshow',function(event, ui){
$("a.ui-btn-left").bind("click", function(){
location.replace("/wines/{{wine.wine_type}}/#");
});
});
There is probably a better way to do this, but I'm a bit out of ideas.
Update:
So I continue to hack on this with somewhat negligible results. On thing I have found was this is what I basically need to work: window.history.go(-3)
from the console it does exactly what I need.
So I tried binding it the the back button like such:
$('div#wine_detail').live('pageshow',function(event, ui){
var last = $.mobile.urlHistory.stack.length - 1;
var last_url = $.mobile.urlHistory.stack[last].url;
var review_url = /review/g;
if (last_url.match(review_url) )
{
$('div#wine_detail a.ui-btn-left').bind( 'click', function( ) {
console.log("click should be bound and going back in time...")
window.history.go(-2);
});
}
else
{
console.log('err nope its: ' + last_url);
}
});
No dice, something interupts the transaction...
I'd prefer not to splice/pop/push with the urlHistory. How about redirect on pagebeforechange like so:
$(document).on("pagebeforechange", function (e, data) {
var overrideToPage;
// some for-loop to go through the urlHistory TOP>DOWN
for (var i = $.mobile.urlHistory.activeIndex - 1; i >= 0; i--) {
// this checks if # = your target id. You probably need to adapt this;
if ($.mobile.urlHistory.stack[i].url = $('#yourPageId').attr('id')) {
// save and break
overrideToPage = $.mobile.urlHistory.stack[i].url;
break;
}
// set new Page
data.toPage = overrideToPage;
}
});
This captures your back button changePage call and redirects to the page you want. You could also just set data.toPage = winelist directly of course.
I'm only doing this with #internal pages, but it shoudn't be so hard to set this up with winelist.html etc.
For more info, check the event page in the JQM docs
Why not have a back button in the header section of your page? Something like this:
<div data-role="header">
<a data-direction="reverse" data-role="button" href="#winelist" data-icon="back">Back</a>
<h1>Wine Detail</h1>
</div><!-- /header -->
I wrestled with this recently as well. After thinking about it, I realized I could rewrite my JQM application to use Pop Up "windows" for those pages that I didn't want in my history. This ended up being an easier and cleaner fix than mucking around with browser history.
Now users can intuitively use the browser back button, and I don't have to code application back buttons.
The only thing you have to ensure is that the popups don't themselves make it into the browser history, so make sure to set the "history" option to false like so:
$('#some_popup').popup( { history: false } );
Okay so the solution was close to the update I posted. The issue with the previous solution was that there were to many things bind-ed to the "Back" button. While my new bind action may have been working sometimes, the other actions would take place too, I tried unbind() but still no worky.
My solution is a bit of smoke and mirrors. I check to see if the the previous page was the review page and then if so, I swap out the old back button for my new faux button with the history back step like so:
$('div#wine_detail').live('pageshow',function(event, ui){
var last = $.mobile.urlHistory.stack.length - 1;
var last_url = $.mobile.urlHistory.stack[last].url;
var review_url = /review/g;
if (last_url.match(review_url) )
{
$('a.ui-btn-left').replaceWith('<span class="ui-btn-inner ui-btn-corner-all"><span class="ui-btn-text">Back</span><span class="ui-icon ui-icon-arrow-l ui-icon-shadow"></span></span>');
$('#time_machine').bind( 'click', function( ) {
console.log("click should be bound and going back in time...")
window.history.go(-3);
});
}
else
{
console.log('err nope its: ' + last_url);
}
It looks exactly the same, and no one is the wiser. it could probably be improved by using the the jQm method pagebeforeshow so user could never see the swap. Hope this helps someone.
If you have the situation that you want the close button refer to an arbitrary (not the last) page, you could also change first to the target page and open the dialog afterwards. Therefore the close button at the dialog will open the target page.
// First: change to the target page
$.mobile.changePage('#target_page');
Afterwards open the dialog like this.
// Second: change to the dialog
window.setTimeout(
// for some reason you have to wrap it in a timeout
function(){
$.mobile.changePage('#dialog');
},
1
);
Now you can open the dialog and the close button will open #target_page.
Advantages:
solution works for single dialogs rather than removing all close buttons from all dialogs
seamless integration on a single point of code
history manipulation is not needed
I have seen similar issues before when using jquery mobile and it is addressed in the documentation. When setting up your Javascript "at the beginning of your page" use pageinit instead of ready or maybe in your case pageshow. I think this will address your issue without having to workaround the history queue.
Related
my goal is to hide the content of my homepage when someone visits. onClick to begin button the content should be shown. Content should stay open when user goes to other page and comes back to homepage. But it will be hidden when user closes the window and opens up the homepage again. To achieve this goal I have put the following code but it keeps the content open even when user closes and opens the window. So please help me out.
if (! localStorage.noFirstVisit) {
// hide the element
$("#content").hide();
// check this flag for escaping this if block next time
localStorage.noFirstVisit = "1";
}
Another issue is when the content shows the design gets little messed up(by widening the divs, bringing horizontal scroll)
$(".roll-button").click(function(){
$("#content").show();
});
I would highly appreciate if you check website, suggest me fix or show me proper way to achieve this goal. url:iamicongroup.com
You can totally use sessionStorage to detect whether it is new tab(window) or not.
When you first visit this page, set sessionStorage.noFirstVisit = "1";.
After you go to another page and back, sessionStorage.noFirstVisit is still "1".
But when you close the tab or browser and open the page newly again, sessionStorage.noFirstVisit will be undefined.
Documentation is here
The documentation also provide the difference between sessionStorage and localStorage.
I would suggest reading this: Detect Close windows event by Jquery
It goes over window unloading (beforeunload), which I believe is what you're after. You can set/unset your localstorage values there based on certain criteria being met; for example:
$(window).on("beforeunload", function() {
if(localStorage.noFirstVisit = "1" {
// do something
localStorage.noFirstVisit = "[someValue]"
}
else {
// do something
localStorage.noFirstVisit = "1"
}
})
Another issue is when the content shows the design gets little messed up(by widening the divs, bringing horizontal scroll)
how about adding something like 'ng-cloak' in angular, to avoid the undesirable flicker effect caused by show/hide.
when clicking the roll-button, it prevents the divs from showing unfinished..
i want disable browser back button and refresh button. in angular
example my source
page source :
"use strict";
.controller("wizardSecondController", function($scope, $state, $stateParams, wizardManager) {
$scope.$on("$viewContentLoaded", function(event, data) {
});
i want prevent browser back and refresh .
please answer .
If you want to disable browser back button in angular, please try out the following code. It may help.
$scope.$on('$locationChangeStart', function(event, next, current){
event.preventDefault();
});
It's not a very straight forward thing in Angular.js but you can use JavaScript function - window.onhashchange to disable to back button.
Take a look at this link, you might get better ideas.
Use javascript event
window.onbeforeunload = function(e) {
var dialogText = 'Dialog text here';
e.returnValue = dialogText;
return dialogText;
};
refer
I shall give you advice as to disabling the back button:
Strictly speaking it isn't "possible" if using standards, but there are workarounds.
There is the window.history object which includes a small API.
But it doesn't allow you to double check for states/pages before the user surfed to your site. Obviously for security reasons and not by accident or missing implementation.
There's various checks for the usage of navigating back in the history and several posts about that topic, but none is helpful as to when it comes to the point the user leaves your page and goes beyond your accessible history.
As to that, check on the events
onhashchange
onpopstate (be aware IEs implementation thereof is half-baked, even in IE11 --> in my case it didn't respond to mouse interaction, only to js history.*()
If you want to catch the user on your site for some hopefully incredibly good purpose:
Create a duplicate entry of your home page on the first homepage-hit via window.history.pushState and instantly window.history.forward() --- (this works especially well and unnoticable on SPAs)
Reiterate that procedure every time the user navigates to your homepage/lowest_level_parent_state ...
Et voila ...
In my case I can't even escape our page if I hold down the backspace button ...
Another convenient option would be to put the page into fullscreen mode if feasible :)
Cheers, J
I'm currently using Backbone.Marionette to create a SPA and in one of the views it is possible for the user to navigate away with unsaved changes. I can control some of these events, like buttons and menu options within the view that would take the user away, but some others would require to manipulate either Backbone.Router or work with the DOM events directly.
I already tried listening to beforeunload (doesn't work as the application is still loaded) and hashchange (doesn't work as you cannot stop the browser from navigating away). These solutions (1, 2, 3) don't work in this case, the Javascript is never unloaded.
Changing the Backbone.Router seems to be the best option, but because of how it is initialized I don't think it is possible to introduce this feature or at least I cannot find a way of doing it. This solution, for example, doesn't work because hashchange is not cancelable (you cannot call stopPropagation on it), and this other solution doesn't work because navigate is not defined on the Backbone.Router object.
Any suggestions?
I've managed to find a solution to this, although some more work is required. For this solution, I am assuming that you keep track when a view is dirty.
There are 4 main ways of moving out of a view;
Click on a link on the view
Click on link outside the view
Click on refresh or external link
Click on back/forward on the browser
1. Application link
This is the easiest case. When you click on your own link, you have to check if your view is dirty. For example, I have an in-app back button that is handled by a historyBack function. On the view:
historyBack: function() {
if (this.isDirty) {
answer = confirm("There are unsaved changes.\n\nDo you wish to continue?")
if (answer) {
this.isDirty = false
window.history.back()
}
}
else {
window.history.back()
}
}
2. Links outside your view
This type of interaction can be handled by extending the Router prototype's execute method, not the navigate method as proposed in other places.
There should be a variable somewhere accessible by the Router that stores the state of the view. In my case, I'm using the Router itself and I update this variable every time I change the dirty flag on the view.
The code should look something like this:
_.extend(Backbone.Router.prototype, {
execute: function (callback, args, name) {
if (Backbone.Router.isDirty) {
answer = confirm "There are unsaved changes.\n\nDo you wish to continue?";
if (!answer) {
return false;
}
}
Backbone.Router.isDirty = false
if (callback) callback.apply(this, args)
}
}
3. Refresh or external link
Refresh and external links actually unload your Javascript so here the solutions based on beforeunload (see question) actually work. Wherever you manage your view, I use a controller but let's assume it's on the same view, you add a listener on show and remove it on destroy:
onShow: function() {
$(window).bind("beforeunload", function (e) {
if (this.isDirty) {
return "There are unsaved changes.";
}
}
}
onDestroy: function() {
$(window).unbind("beforeunload");
}
4. Back/Forward on the browser
This is the trickiest case and the one I haven't figured out completely yet. When hitting back/forward, the user can navigate out of the app or within the app, both cases are covered by the code on 1 and 3, but there is an issue I can't figure out and I will create another question for it.
When hitting back/forward, the browser changes the address bar before calling the router so you end up with an inconsistent state: The address bar shows a different route to the application state. This is a big issue, if the user clicks again on the back button, after saving or discarding the changes, she will be taken to another route, not the previous one.
Everything else works fine, it shows a pop up asking the user if she wants to leave or continue and doesn't reload the view if the user chooses to stay.
I have a problem brought about by a specific client requirement in nopCommerce.
I have a page - lets say page1 - which shows a block image which you then have to click through to get to the main part of the page (no matter how much I try to dissuade them from the extra click they are adamant - basically it's a 'glamour shot' before going to the main product grid/category page).
I have this JavaScript for the page load:
switch(window.location.pathname) {
case "/store/page1":
$(".category-page").hide();
break;
etc. (there are other functions for other things)
Followed by:
$(".landing_click").click(function () {
$(".landing_page").hide();
$(".category-page").show();
});
This all works great and displays the product grid (category page) as it should after clicking through the main image. However after viewing an individual product from the grid (going through to product details) clicking the back button on the browser takes you back to the first stage of the page1, so you have to click through the splash image/glamour shot again to get to the product grid.
To me this is logical and it is working as it should, but I need to find a way so that when the user is clicking the back button out of a product, it goes back to the product grid. Like this:
Is this possible with JavaScript? It needs to use the browser back button rather than a specific other button, although I could add one of those in addition as well.
If it were a straightforward website it would be relatively easy, but I am confined by the limitations of nopCommerce and the way the Category pages function, hence why I am looking for a JavaScript answer if possible so I can simply adapt what I already have.
Thanks
I would use location.hash to do it like this:
switch(window.location.pathname) {
case "/store/page1":
if(window.location.hash == "#landing") {
$(".landing_page").show();
$(".category-page").hide();
}
else {
$(".landing_page").hide();
$(".category-page").show();
}
break;
//The rest here
}
Followed by:
$(".landing_click").click(function () {
window.location.hash = "#category";
$(".landing_page").hide();
$(".category-page").show();
});
Now when you are in the product details page, a click on the back button will move you to /store/page1#category loading the category page directly.
My problem is a bit more complex than using the following simple JavaScript code:
window.onbeforeunload = function (e) {
return 'Are You Sure?';
};
On an e-commerce web page I would like to remind the user that he has items in the shopping cart so that he can change his mind before
closing the browser tab/window
navigating to another domain
The JavaScript method above does not solve my problem because it is evoked even when the user navigates within the domain.
Short:
User tries to close window -> Show dialog
User changes www.mydomain.com/shoppingcart url to www.google.com in the browser's address bar -> Show dialog
User navigates to www.mydomain.com/checkout with the checkout button or presses the back button in the browser -> Do NOT show the dialog
It's not possible to tell if a user is pressing the back-button or closing the tab and you don't have access to their intended location.
It is possible to stop the dialog from showing if an internal link is clicked though:
(function(){
function isExternal( href ) {
return RegExp('https?:\\/\\/(?!' + window.location.hostname + ')').test(href);
}
var returnValue = 'Are you sure?';
document.documentElement.onclick = function(e){
var target = e ? e.target : window.event.srcElement;
if (target.href && !isExternal(target.href)) {
returnValue = undefined;
}
};
window.onbeforeunload = function(){
return returnValue;
};
})();
Sorry there's no technical solution to your "problem."
It's not an accident when a user decides to leave your site, i.e. by typing a new URL, so stopping them to say "Hey, you haven't checked out yet" is kind of pointless.
I would suggest letting the visitor leave your website freely and simply remembering their information (DB, Sessions vars, etc). In terms of eCommerce that is the polite way of keeping customers.
If someone wants to leave your website, they will. Double-checking beforehand will likely only irritate the customer and lessen your chance of their return.
Since the beforeUnload-event object does NOT contain the location the user is trying to go to, one "hack" to do this would be to add click listeners to all links on your site, and disable the unload-listener in that handler. It's not very pretty, and it will probably not work if the user navigates with the keyboard, but it's my best guess at the moment.
It sounds like you'd need to use an onbeforeunload and then modify all your internal links to disable it. Probably the thing to do for the latter would be a jQuery event; making the actual hrefs run through JS would be terrible, not least because it'd defeat search engine crawling.
I was looking into this too, reason being we have some really stupid end users who fill out a whole web form then don't press the save button.
I found this is u r interested, seems like a good solution:
https://web.archive.org/web/20211028110528/http://www.4guysfromrolla.com/demos/OnBeforeUnloadDemo1.htm