So I am running into an issue. I have certain fields that I store within the request from page to page, because each page requires different fields to be populated within a collector that I used cross-page. The problem is the back button.
If I click the link to take my to my login page, the server populates the collector from the request with the appropriate pagename and event name, etc., to allow me to navigate to the login page. (Certain things have to load, so it has to go through a servlet). However, on that page, there are static modules for ads and whatnot, so clicking on one of the ads will take you to a separate, static page that does not require these attributes to access. In Chrome, Safari and FF, if I click the back button after accessing this static page, the browser asks me to reload the request to be able to view the page. In IE8, however, there is no page reload. It just kicks me back to the page, and does not populate the request, and it crashes with my sorry page.
I need to know if there is a way to populate the request on the back button click, and how to do so. Otherwise, my servlet is throwing a null pointer when trying to access the fields because they are all null in the request. Any help would be greatly appreciated. I am not even sure if this is at all possible.
I guess you are using POST requests to navigate to each page. POST should be used only to send some user action different from page view - login, buying something, changing settings, etc. The browsers require the user to confirm that they want to revisit a page using POST, before that implies state change. See What is the difference between POST and GET?
For simple content pages, where the user does not take action, it's better to use GET requests. Also, it is much more common to use request.getSession() to get and store the user fields on the server side. That is, you only send them once, and then look them up for each request. Look up for tutorials on session tracking in java.
Related
I am making a chrome extension that fetched JSON data from CoinMarketCap.com API and currently I have it running in the background script. I'm not 100% sure what the purpose of the page is really. I was wondering if I could simply fetch the data from the popup script after I click a button within my popup?
Each button represents a different coin. I basically want to get the price of a chosen coin and display it on whatever page the user is on when they double click the coin in a text article. Eventually I want to make it so you can double click any coin and have it show a live price conversion while you're on the web-page.
The point of a background page is to be always available (running if persistent: true, woken up / recreated for registered events if persistent: false).
A popup's lifetime is determined by its visibility. The moment the user clicks away and closes it, the page is closed (as if the tab with it was closed), so it can no longer process any events and its state is lost.
As long as:
The data you need fetched is to be received/processed while the popup is open
Any state you need to persist between popups being shown can be stored in chrome.storage
Then you don't need the background page to do the fetching. Popup page has the same level of access to Chrome APIs.
However, consider this scenario: suppose you want the data to be ready as soon as popup is opened (at least, you want it to be fresher than "since last time"). You may want to do periodic updates even while the popup is closed to refresh the data. You can only do that reliably with a background page (and, say, chrome.alarms API). Then you can cache the latest available data in chrome.storage and use that in the popup.
Background pages have their uses as some code that can run periodically regardless of user actions, and to be able to always react to events.
According to Changes to Cross-Origin Requests in Chrome Extension Content Scripts now you have to do your fetches in Background Script. Not in Content Script.
Here's what happens:
Page loads (a timeline view)
User scrolls down to the bottom
More timeline content is loaded via AJAX
The URL is set to a new value with history.pushState(). If this URL is accessed directly, it loads the timeline so that it includes all content that's been loaded dynamically so far.
The user clicks a link in the timeline
The user then clicks the back button in the browser.
My question: when the back button is pressed, will the browser do a fresh load of the url provided via pushState() (which may involve a large performance hit if they have gone a long way down the timeline)? I'm hoping that instead it will update its page cache somehow when pushState() is called to include the DOM with the dynamic content added, and then reload that instead.
If it doesn't do any automatic cache magic like that, is there any way to make it do so in order to improve performance? It seems wasteful to reload a large number of posts every time the user clicks away from the timeline. Also, as they scroll, the URL is constantly updated so it would be a fresh load of all posts every time they click away, not even using normal browser caching.
I've looked for information, but can't seem to find anything that says how pushState() modifies the cache, if at all.
When I login to a site, which is a "learning system" at my university, I have found that I cannot open a new tab with the same site open. When I do so, somehow the site is aware and displays the following message?
How on earth does the site know what tabs I have open on my computer? As far as I know, the front-end code shouldn't have any access to my private browser information. What accessible information could this site be using to determine that I have another tab open already?
I am accessing the site using a private computer, and the site being accessed isn't on a local network, it is being accessed through the internet. Therefore there is no internal monitoring software that could be causing this. I am using Google Chrome 24 Beta for Mac.
One way to do this is via cookies and ids. Firstly, you are logged in to the site and have a session on there. This is managed using cookies; whenever you visit a page on the site, your browser will send a cookie which normally contains some kind of id. That way the server can identify any request coming from you, is really from you. So, in this case, both your original tab and your new tab will send the same cookie.
Secondly, it can also add another, different id (call it the page id), to any link or form you submit on the site. So a form on a page might contain the id 1234, and any links will also contain that id. Each new page you visit might contain a new id. So at any point, the site knows that next request from your browser (identified by the cookies) should also contain this other id. If you navigate around the site in a normal way, clicking on links, submitting forms, this will be true and all will be good.
Cases when your next request would NOT submit the expected, second id are:
you hit the back button (you would be sending an old page id)
you open a new tab (this depends on the browser, but if it opens the
same page you are already on in the original tab, it would be sending the current page
id, not the next page id, which the server expects)
Either way, you send a request with a page id the server doesn't expect and it can make a best guess as to what you did.
They track your mouse cursor movement while visiting their website. It's a great way to get the attention of a visitor. They put some query programmatically when you move your mouse and when you wish to close.
It's good UX.
Another way the site may know that you have another tab open is through broadcasting channels. To put it simply, broadcasting channels are a means for windows, tabs, etc; to communicate (correct me if I am wrong). Here is a simple implementation:
//Channel to post and receive messages from
const bc = new BroadcastChannel("Check-tabs");
//On message receive
bc.onmessage = (event) => {
if (event.data === `First tab?`) {
//Post that there is already a tab open
bc.postMessage(`Tab already open`);
}
//Check if a tab is open
if (event.data === `Tab already open`) {
alert(`Another tab is already open.`);
}
//Posts message to check whether another tab is open
bc.postMessage(`First tab?`);
Is there a method of forcing browser to refresh what URLs to load while going back in the browser history?
In a nutshell: There is a (slow) item search. On top of this item search there are additional AJAX filters that replace the item results of this search (it's another item search with extra parameters in the URL). There is a multiple of those filters that can be applied to a search. Eventually the user clicks on an item they're interested in or adds it to the cart or whatever other action.
By default, if they click back in the browser, it will load the initial search without the additional AJAX filters applied. That's understandable.
To have a proper back behaviour, I've used the jQuery.history.js plugin. I can see very nicely the URLs in the address bar change properly, but it never "reloads" that URL, instead, it tries to force loading previous page and AJAXing the rest. At least that's my understanding.
So even though the address bar will show a correct search link, on which if I were to press enter the correct results would load, but the browser never refreshes that link.
Now, I'm sure I could call the AJAX filters again if I had to, but I'm hoping there is a way of forcing a refresh when the person clicks back in their browser.
I'm not even sure if what I'm asking for is possible.
Say if I am on page 1 , I enter my form data and go to page 2 , But wait I forgot something and I need to go back. FireFox and Safari ask me if I want to resend my form data.
But IE being IE it just goes back and does not show the page.
Is there away around this when I click back it keeps the data and the page appears.
Sorry I cannot give a link but the process for u to go through on my site to get to this part would take you a while.
My suspicion is that your talking about a wizard form. Where each part of the form is a page and you can go backwards and forwards through the pages.
the back button has always caused problems for developers on the web and this is probably the most annoying.
You can stop the IE back button issue by redirecting on the server to the next page when you receive a form post rather than just delivering the form back to the browser. Doing this means that the browser considers each page to have been a get and stops asking you if you want to resubmit the form.
to do this simply make each form post to itself and then return a redirect to the next page of the wizard. I'd give examples but I'm not sure what language you are using on the server.
the other alternative is to use javascript to create a wizard from your form see this jQuery wizard form demo.
create a new back button besides the submit button and when a user clicks on either one you call a javascript function which modifies the form action either to the next page or the previous page.