I am using url hash to scroll the page. What i am doing is, say i have 2 pages :
Page1 and Page2
First i navigate from page1 to page2 and set the url hash than my url will become :
http://localhost:48785/page2#id
I am setting hash using this code:
window.location.hash = "id";
Than i press browser back button and went to previous page i.e. page1. Upto this point everythings work fine.
The Issue occure when i set hash twice on page2. Like:
http://localhost:48785/page2#id
http://localhost:48785/page2#id2
Now when i press browser back button, it just navigate back and forth between hash #id and #id2.
Why the back button not taking me to the previous page i.e. page1 after setting hash twice on page2 ?
That's the way the browser back button is supposed to work. It goes back to the last url change in the browsers history.
it looks like you can use history API like it described here http://www.thecssninja.com/javascript/stealing-history-api
enter link description hereyou can History API and try and remove the history from the browser so that you can get out of the loop
Because HTML5 : 6.6.9 : Navigating to a fragment identifier says:
When a user agent is supposed to navigate to a fragment identifier, then the user agent must run the following steps:
Remove all the entries in the browsing context's session history after the current entry. If the current entry is the last entry in the session history, then no entries are removed.
This doesn't necessarily have to affect the user agent's user interface.
Remove any tasks queued by the history traversal task source that are associated with any Document objects in the top-level browsing context's document family.
Append a new entry at the end of the History object representing the new resource and its Document object and related state. Its URL must be set to the address to which the user agent was navigating. The title must be left unset.
Traverse the history to the new entry, with the asynchronous events flag set. This will scroll to the fragment identifier given in what is now the document's address.
This is done so that links within a document can be backed out of in the same way that links between documents can. User confusion might result if hitting the back button only served as an undo for some link navigation and not others, especially when scrolling can cause a complete change in the content displayed.
Related
I have a line of code:
location.href = 'payments/basic.php';
It works fine, but a user can simply press the Esc key to cancel the operation. I tried to use an event listener to prevent the Esc key from being pressed, but it only works while the user is on the initial page. As soon as they are being redirected, it stops working and they can quickly press the Esc key or the big X beside the address bar in their browser to cancel the redirect.
Is there a way I can completely prevent that?
Edit:
The reason I want to do this is that upon login, they are automatically sent to the index page. I have a flag in my DB which checks if a user has made payment. And then on the index page, I have a little script that queries the DB to check if the flag is true or false. If it's false, they are immediately notified that they are being redirected to make their payment. If at this point of redirection, they cancel, they will be able to remain on the Index page without payment.
I think the only way to prevent the Esc key from stopping navigation is to not navigate away from the original page at all. Instead of doing
location.href = 'payments/basic.php';
make an XHR or fetch request to basic.php, and populate the current document with the results, instead of loading an entirely new document - just like how a SPA works.
(You will almost certainly want to make some changes to basic.php - eg, have it return easily-parseable JSON containing the data to populate the page with instead of an HTML document)
Regarding the edit
upon login, they are automatically sent to the index page
If at this point of redirection, they cancel, they will be able to remain on the Index page without payment.
If you're trying to prevent access the the original page, then just don't serve the original page until you've checked the flag in the database. Don't serve the index page to begin with until you've validated the user's credentials. If they aren't authorized, redirect them in PHP (not in JS) to the payments page. No need to mess with the user's escape key.
Why not do it the other way around?
Default to the payment page, if payment is already made, then redirect to index. lol.
My Setup
I am using react router 4 in my application and am trying to achieve something along the lines of adding hashes to certain routes on pages, that will save the state of the page so user can link to said state.
So for example - I have products I am listing that have many variants, when the user selects a variant, I add a hash + the variant ID to the URL, so like myapp.com/cars/truck turns to myapp.com/cars/truck#red, this allows users to link to that specific variant, which is what I want.
My problem
My problem arises when the user navigates to a page and selects a few variants, then tries to navigate backward. Because I change the hash, each back step hits the previous variant in the browsers history.
So if
the user lands on home myapp.com/
navigates to myapp.com/cars/truck
then selects the red variant => myapp.com/cars/truck#red,
then blue myapp.com/cars/truck#red => myapp.com/cars/truck#blue
When they press the back button on the browser they will go back to myapp.com/cars/truck#red, when the desired effect is they go back to the previous page omitting the variant and hash changes, which would be myapp.com/.
I understand this is the browsers behavior, but what I am wondering is if there is a way to let users link directly to the variant links, and also have it so pressing the back button after the described scenario takes the user back to the previous page (in that scenario it's myapp.com/). Perhaps re-thinking how I am doing this, I am open to any suggestions.
I am using react (16) and react router (v4) for this if this helps. Happy to show any code if needed, please let me know. Thanks for reading!
Try replaceState, it will update the URL without adding a history entry:
history.replaceState() operates exactly like history.pushState()
except that replaceState() modifies the current history entry instead
of creating a new one. Note that this doesn't prevent the creation of
a new entry in the global browser history.
e.g.
history.replaceState(null, 'Red Truck', '/truck#red')
I am working on a Chrome extension, I want to detect when the user has typed a URL. I know about:
chrome.tabs.onUpdated.addListener(eventLisenerObj.onUpdated);
But, it gets called whenever the URL is changed (e.g. when the page is auto reloads, or user clicks on a link, etc.)
I desire to be able to determine that the URL was changed only by the user typing a URL.
You can get this information using the webNavigation.onCommitted(MDN) event. The event listener receives a property transitionType(MDN), which will be different values(MDN) based on the cause of the navigation. Which values you trigger on will depend on exactly what you are desiring. For what you describe, you will probably want 'typed'(MDN), but potentially also 'generated'(MDN), 'keyword'(MDN) and/or 'keyword_generated'(MDN).
The list of possible values is explained on Chrome's History API page (they are listed on the Chrome webNavigation page, but not explained there) (On MDN: TransitionType) (text from the Chrome History API page):
"link"
The user got to this page by clicking a link on another page.
"typed"
The user got this page by typing the URL in the address bar. Also used for other explicit navigation actions. See also generated(MDN), which is used for cases where the user selected a choice that didn't look at all like a URL.
"auto_bookmark"
The user got to this page through a suggestion in the UI — for example, through a menu item.
"auto_subframe"
Subframe navigation. This is any content that is automatically loaded in a non-top-level frame. For example, if a page consists of several frames containing ads, those ad URLs have this transition type. The user may not even realize the content in these pages is a separate frame, and so may not care about the URL (see also manual_subframe(MDN)).
"manual_subframe"
For subframe navigations that are explicitly requested by the user and generate new navigation entries in the back/forward list. An explicitly requested frame is probably more important than an automatically loaded frame because the user probably cares about the fact that the requested frame was loaded.
"generated"
The user got to this page by typing in the address bar and selecting an entry that did not look like a URL. For example, a match might have the URL of a Google search result page, but it might appear to the user as "Search Google for ...". These are not quite the same as typed(MDN) navigations because the user didn't type or see the destination URL. See also keyword(MDN).
"auto_toplevel"
The page was specified in the command line or is the start page.
"form_submit"
The user filled out values in a form and submitted it. Note that in some situations — such as when a form uses script to submit contents — submitting a form does not result in this transition type.
"reload"
The user reloaded the page, either by clicking the reload button or by pressing Enter in the address bar. Session restore and Reopen closed tab use this transition type, too.
"keyword"
The URL was generated from a replaceable keyword other than the default search provider. See also keyword_generated(MDN).
"keyword_generated"
Corresponds to a visit generated for a keyword. See also keyword(MDN).
To differentiate some types of transitions, in addition to the transitionType values, you will also want to look at the TransitionQualifier(MDN). The possible values are (from the Chrome documentation, which are described somewhat differently on MDN):
"client_redirect"
One or more redirects caused by JavaScript or meta refresh tags on the page happened during the navigation.
"server_redirect"
One or more redirects caused by HTTP headers sent from the server happened during the navigation.
"forward_back"
The user used the Forward or Back button to initiate the navigation.
"from_address_bar"
The user initiated the navigation from the address bar (aka Omnibox).
You can have a look at $locationChangeSuccess.
You can get the path like this:
var loc = $location.path();
Then on change of loc you can attach your function.
On product list page in pressing the reference "buy" , I add the article to cart with a help of Ajax and put down Article Id to document.location.hash.
When I delete the article from the cart and return with a help of the button "back" in the browser , I need to delete product Id from location.hash on product list page.
Is it possible?
Nope. You can't modify history in browsers by design, imagine what security impacts that would have? You could, for instance, push something in to the history and issue a history.back() to send the user wherever you want!!
You must handle the back-button stuff in the session server side with some state controller.
Add: when user hits the back button, the page is retrieved from cahce or from the server, depending on the header information etc. The browser has already rendered the page whenever your code will start running. Modifying the location object then would result in an additional page load/reload. If you KNOW that the ID is invalid, there's no need to delete it from the location hash, you might handle that within the server code.
I'm looking for a way to update the url in the status bar..
I have a gallery, and when you click your way through the gallery I want the image ID to show up in the URL, so that the user can link directly to the image..
I've read about using hash and so. but as far as I've tried it, that "ruins" the history.
If I click the back-button in my browser the previous image would be shown.
Is it possible to add or update a URL parameter, without ruining the history?
Thanks in advance
Use location.replace to replace the current location:
Replace the current document with the one at the provided URL. The difference from the assign() method is that after using replace() the current page will not be saved in session history, meaning the user won't be able to use the Back button to navigate to it.
Do it simply this way, when switching to images, add a hash to the url, for example:
location+='#image-'+image_id
your location will become
http://example.org/images/#image-3
instead of the initial
http://example.org/images/
and onload, check if location.hash is not empty, and matches with ^image-(\d+)$ (regular expression pattern), if it matches, do the usual thing you'd have done if a user clicks on image with id (\d+).
To preserve history, use reallysimplehistory.