Google does this thing where on search results after you've visited a search result page and don't find what you and and click "back" to the Google Results there's then a "Hide results from xxxxxxxxxxx.com".
This doesn't happen till you're back on Google's page because I can see the effect. How is this done? Is it a onFocus on the window with a record of you having clicked that search result or something?
I guess they simply just track how much time you spent on the result website and if you didn't spend much time there, they will assume you didn't find what you want? So in overly simplistic way:
When you click a search result, save a timestamp and the target website url in a cookie. This can be done by a simple onclick handler, it fires before you are taken to the new site.
You click back and the time is checked against the clicked time and the url is added to remove results from xxxxx.com if the time spent is < y seconds.
Then again I am just guessing and as I cannot get this functionality to work for me, I cannot find out to be even remotely sure. But If I ever had to implement something like this, this would be something I would explore first.
Notice the search URL: it's http://www.google.com/#sclie.... The page doesn't actually reload, the results are loaded with Ajax. When you press Back, however, it does reload, or rather, onload and related events are raised again.
Related
I am loading results in with ajax with an infinite scroll, however, when you click an item in the list and navigate away from the page, then click the back button, you are back at the top of the list.
I can't figure out how to make the user return to the position they left off.
See the site I am working on:
https://www.studenthouses.com/search/manchester/
Scroll down a few times, then click a property, then click back and you will see what I mean.
I can't remember the result position and load them in because it would take too long, so really I need the browser to remember the DOM when it comes back to the page, or cache it some how.
Is there a solution to this?
Many thanks
Sure there is and it's a piece of cake. Well, it's a cookie, actually :)
You don't need much to solve this problem.
First, get some cookie here: Cookie API
Second, you'll have to encode the data in the cookie somehow. If you have multiple pages like that one, you'll have to separate them somehow or use a key-value pair and store something like this:
manchester=3522
Whenever you enter the page, load the cookie, wait the page to be fully unrolled (you use AJAX or similar, you'll have to wait for the page being unrolled, window.onload won't do).
If there is no cookie, skip this step:
scroll the page down to the offset you have loaded from the cookie: scrollTo
Next, whenever the page is scrolled, modify the cookie. To avoid thrashing you'll want to do this in a polling manner. Use setInterval() at maybe 500 milliseconds and check if the user changed the scrolling position. If he did, save the cookie with the new value.
I am supporting an e-commerce app, which pretty much makes and submits orders.
A user found that if they submit their order, and press back really quickly, they can cause an error condition.
I want to prevent this. When the user clicks submit, I want to bind some kind of event to the browser's back button that instead will redirect them to the Index page. However, after about two hours of Googling (including a few StackOverflow topics), I have not found any clear way of influencing the behavior of the back button.
I briefly attempted to use history.pushState(), but as the HTML 5 documentation mentions, that will not cause a redirect; it merely alters the displayed URL/state.
Similarly, the history.onpopstate event appears unhelpful, because it occurs whenever a state is removed from the history listing; I'm looking for an event that occurs whenever the history listing is traversed backwards.
Question: Does an event for the browser's back button, or at least a way to prevent this particular stupid user trick exist?
You can't listen to the browser back button because it's outside of your reach (it's not part of the DOM).
What you can do is fix the previous page so that it detects if you've used the back button.
Without more information I can't give you any tips on how to achieve that.
Also, an error condition is not necessarily a bad thing. Just make sure it's clear what is happening: the error message should make sense.
Wrong answer...
Instead listen to window.onBeforeUnload and ask the user if he knows what he is doing. Return false if not. This is usually done via a confirm dialogue
I've found variants of this problem on Stack Overflow but nothing my matches my specific circumstance. Hopefully someone has some insight.
Right now I'm working on a web application where there is a button (technically an anchor tag) that spawns a list of items when pressed. The issue is, if the user presses this button rapidly twice in a row, the list will be spawned twice-- the button is meant to clear the list before spawning it to prevent duplication, but something about the way the scripts interact is causing this bug. The button spawns the list by making an ajax call to a server.
Now, I've tried fixing this bug by flipping a boolean value to 1 when the button is pressed, and making the button do nothing until it is 0 again. This seems not to work regardless of where in the code I set the value to 0 again: I've tried putting it at the end of the ajaxGet function, as well as after page load, but neither solution works.
Ideally, I would like a way for the button to become enabled as soon as the page is completely finished loading and rendering. Ultimately, what's needed is a way of preventing the user from pressing the button twice in a row. I've considered using a timer for this, but I'd prefer not to have to resort to that.
Any ideas? Let me know if you would like code snippets.
===========================================
EDIT: Thanks everyone for your answers! I used a variant of Fibrewire's answer to solve the problem, and it works great. At the beginning of the method that the button calls, I put the following code:
if (actionsDisabled == 1) {
return;
}//if
else {
actionsDisabled = 1;
setTimeout("actionsDisabled=0;", 1000);
}//else
Where actionsDisabled is a global boolean. It might not be as airtight as it could be (in particular, you'd hit a problem if the list took more than a second to load), but it's elegant and functional, and has the added bonus of reducing server requests (if traffic ever became a problem, you could restrict calls to once every 5 or 10 seconds or whatever). Thanks again!
you can disable the button after the first click
Disabling the button after once click
and if you need the user to be able to click the button again in the future you can use the setTimeout() method to re enable it after a brief pause
http://www.w3schools.com/jsref/met_win_settimeout.asp
I'm creating an HTML and Javascript client for running in browser which talks to REST API. I'm using RouteMap to set my URLs. So I've kept a convention something like this
http://mysite.com/#/{ResourceName}/[edit|view|list]/[Id]/
I've set just one route and I'm grabbing these parameters in the function bounded to hashchange. Most of the things work fine. Just two issues and I'm stuck because of them.
If the user clicks on the same link twice, hashchange event doesn't fire. Yes, hash has not changed so obviously it won't fire. But there should be something which can be done and I'm missing that.
If I change something in the UI (like bring up new divs and hide some) for which I don't want to change the hash link, I loose that history and can't go back by clicking the back button properly.
Any help will be grateful.
For #1, you probably want to attach a handler to the link click event. That way you can tell if the link is being clicked. When I use onhashchange, I always attach something to the click event to assist polyfills for onhashchange, so at least I can tell when it's failing.
For #2, I want to point out that having automatic stuff change the user's history is problematic. You could fill someone's history with minute, meaningless hash changes. I recommend only changing the history when the user actually interacts. Short of that, HTML5 does offer pushState and popState. Reference
I have this odd bug that causes a 302 redirect to another page on my site and I can't seem to track the source. The bug is very random and hard to track.
I have 2 or more dropdowns on a page for users to select from. Selecting from the first loads the second, second loads third etc. This is done thru posting back on the onchange event, all .net.
Additionally through jquery onblur is wired up to the change event. I'm not sure why but I'm guessing that whomever wanted to unselect the dropdown after a selection was made, most likely to prevent a scrolling mouse wheel from changing the selection and causing several post backs.
When I unhook the onblur the bug goes away but I need to know whats going on. Some how onblur is causing a sequence of events that results in a 302 redirect without even getting to the server. This would suggest a javascript location change. How can I stop at the location change and see what js is triggering this?
Any suggestions ?
Thank you.
A redirect is an instruction to the browser, not the page, so JavaScript can't see it.
Are you sure it's a 302 causing the location change? I would start by loading your favorite dev tools (I like chrome) and see if you are actually getting a 302.
If you are getting a 302, you're going to have to post some server side code. If not, I would place some js debug points and go from there.