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.
Related
I'm adding a blocking modal (ie one that covers the screen and prevents interaction while an API call is processing) to my company's design library.
As part of that, I modified our modal so that clicking on the grey backdrop will NOT hide the blocking modal, but I want to make sure that doesn't violate accessibility guidelines. I haven't been able to find anything online about this. Does anyone know if this this violates accessibility requirements?
Short Answer
The answer is 'it depends'. Basically if the modal is not dismissable in any way it becomes a 'keyboard trap' and so would violate WCAG.
However if you structure it correctly a modal that blocks the page while an API loads is perfectly valid (and can't be dismissed while the page is loading), but there are a few things you need to do to make sure this is accessible.
1. Make sure that when this modal loads, nothing else on the page is focusable.
The biggest issue I see on most modals is that they allow focus outside of them.
You can't just stop users using the tab key as that is not how most screen reader users navigate the page (they use shortcuts for headings (h1-h6), hyperlinks etc.).
For this reason make sure your modal sits outside of your <main> and the hide your <main> and other major landmarks that contain information with aria-hidden="true" and by adding tabindex="-1" to them so nothing is focusable.
Obviously this depends on your document structure so you would need to test it, but a properly structured HTML document will work with the above method.
2. Make sure that a screen reader user knows that the page is busy and something is loading.
There are a couple of ways to do this. The best is to use an aria-live region
Adding aria-live="polite" and aria-busy="true" to the section you are updating is one way (if you are updating one part of the page).
However in your circumstances I would make a section within the modal aria-live="assertive" and not use the aria-busy (as you will be hiding all the content in step 1 so aria-busy would not be applicable).
I would then update the message every second or two for long loads (i.e. 'loading', 'still loading', 'nearly loaded' etc. Or better yet a loading percentage if your script allows.)
Once the page content has loaded, you do not need to say 'loaded' instead make sure you have a heading for the section or page that has a tabindex="-1" added on it that accurately describes the content that has just been loaded in.
Once the load completes, programatically focus this heading and the user will know that the load is complete.
3. Make sure that if the API call fails you feed something meaningful back to screen readers
When your API call fails (notice I said when, not if!) make sure your JavaScript can handle this in a graceful way.
Provide a meaningful message within your modal aria-live region that explains the problem. Try to avoid stating error codes (or keep them short, nothing worse than hearing a 16 digit string on a screen reader for an error code), but instead keep it simple such as 'resource busy, try again later' or 'no data received, please try again' etc.
Within that region I would also add one or two buttons that allow to retry / go back / navigate to a new page depending on what is appropriate for your needs.
4. For long load times, let the user know what is happening.
I covered this in point 2 but just to emphasise it, make sure you feedback to users that things are still loading if there is a long load time by updating your aria-live region.
Nothing worse that wondering if the page has loaded and the developers forgot to tell you.
5. Give the option to cancel an API call so it doesn't become a keyboard trap.
Obviously the big problem with a whole page modal is it is a 'keyboard trap'.
To ensure this isn't an issue make sure you provide a cancel button.
Make sure it is clear that this will cancel the loading of the page, but don't rely on JavaScript alone.
Instead make this a <a> styled like a button that either points to the current page or the previous page (yet again depending on your needs) and add role="button".
Then intercept this click with JavaScript so that it can function like a button.
The reason for this is that when your JavaScript fails (yet again - when, not if) the user still has a way to get to a meaningful page, thus avoiding a keyboard trap.
This is one of the few times you should use an anchor as a button, as a fallback!
By doing this you ensure that the user always has a way to escape the modal.
You may also consider allowing a user to use the Esc key to close / cancel but that is yet again down to you and your circumstances.
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.
I am developing a web page and I am testing it using httpd web server and Firefox. That page is a simple serach engine - providing key words and relevant items will be displayed using AJAX.
My question comes here, every time I click those items to go to another page and try to come back using the browser’s back button, all the contents disappeared and I have to search again.
How can I keep those items?
Take a look at google.com and what happens when you type but do not press enter.
Then read this
Modify Address Bar URL in AJAX App to Match Current State
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.