I have come across several posts about how to handle Javascript being disabled while/before the page is being loaded. However, is there any way to detect Javascript being disabled by the user after the page has loaded in order to hide content at the last minute?
Use a dead man switch on setInterval. If it doesn't trip the trigger, then you need to hide that content before the no javascript gremlins destroys it. How can you hide it without javascript? Have a competitive process going between CSS animations, and Javascript. Such that if javascript is not present the CSS animations (to hide the content), win out. And lo, the content waseth hiddeneth.
Attempt to an send an HTTP request to your server? If that ping doesn't arrive, javascript could be disabled.
Use a noscript tag to inform the user of various things in the event that javascript is disabled, such as the fact that the user has javascript disabled
Put a form in a noscript tag to ask a user to tell you that javascript is disabled, or otherwise to send feedback about their browsing experience to your site without javascript
Check if the UserAgent header contains Lynx?
You can find out if a particular user had disabled JS on his browser by using cookies. You can assume that your JS sets a cookie with some key-value pair like js-enabled=true
When the page gets loaded next time, if cookie does not contain js-enabled key then you know that JS is disabled on the page and server returns the content accordingly.
Now, your question:
After the page has loaded in order to hide content at the last minute?
Say even if you know JS is disabled on the browser, how will you hide the content. You again need JS to be executed to manipulate the DOM which is not possible I think when JS is disabled. So one of the solutions can be when your server knows that JS is disabled then return the page which does not have that content which you want to hide
There is a way to show a warning when javascript is disabled before loading: Write a div element with a warning that jscript is disabled and hide it with jscript while loading the webpage. It is not possible to show a warning when javascript is disabled, because javascript is needed to change any part of a webpage.
if your app can stand the hit of doing log checks - I would, say every minute or so, use ajax to call
the backend - which will then log a time. if the backend checks and the last log time is substantially off - then shut down the app.
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'm working on an extension that's supposed to use the content of the page to determine whether to show an interface to the user.
The ways to show an interface, if I'm correct, are using a browser action or a page action.
And neither can be triggered programmatically. But content scripts could be written to inject an equivalent GUI into the webpage.
So, does it make sense to modify the DOM using content-scripts to display an interface as a substitute for page action? It seems like an obvious work around to me, and I'm sure there are good reasons to not let page actions be triggered programmatically.
Well, modifying DOM must be done by only Content Scripts, as that is the reason they exist.
Want to fetch any data from current page, alter anything in the page, add new UI in the page - whatever, content script will help you do that.
It has nothing to do with Page script Or Browser Script.
YES, you can not programatically trigger page/browser action. It has to be done by explicit clicking.
But if you want to open a UI by clicking a chrome extension, then there is a popup js for that.
I'm building a Google Chrome extension at the moment and I have a question about when to use an event page.
A quick look at the Chrome extension docs shows that Google really want its developers to use event pages, if possible.
My extension currently uses a background page, but I was wondering if I should switch to an event page?
This is what my extension does:
When matched with a particular website, it injects a script that adds buttons for the user to access extra functionality.
Most of this extra functionality consists of doing fairly computationally expensive operations on user-entered data - this is all done in the background page (it is all it does).
When a user wants to run these operations on their data they press a button and this passes a message, from the injected script to the background page, which then passes a message back containing the results of its operations.
Essentially, all the background page is doing is waiting for message passing from an injected script in one particular website and then running some operations. Since it doesn't need to be active all the time, this suggests that I should be using an event page.
Can anyone confirm if this would be a good idea for me? Or are there reasons why I should stick to a background page?
Allowing the background page to suspend (chrome.runtime.onSusend) is great, because it will free up system resources. The page will automatically be launched when a matching event happens (chrome.tab.onUpdated etc). I can't think of any compelling reason to use a persistent background page. You can always store any long term state in chrome.storage.local or indexedDb, etc.
I am developing a web site where users can change settings which they have to confirm before taking effect.
The confirmation is done by a link I send them via E-Mail. In the HTML of the website I use this little snippet:
<script type="text/javascript">window.name="mysite";</script>
And in the HTML emails I use
Click me
But Chrome is always opening new tabs instead of opening them all in one.
Is this even possible or is it forbidden for some reasons?
Webmail platforms such as Gmail tend to modify some of the HTML code of an email due to security reasons.
They obviously remove any javascript code the email could have. But they also change (or add if none) the target property of every anchor element and set them to target="_blank" in order to avoid the user to be taken out of Gmail (in this case).
Unfortunately every webmail platform has their own behavior, therefore, what you want to do is not gonna work on every webmail platform.
If what you want to do is prevent the user from having multiple tabs of the same page opened, (*please refer to Update 1) it comes to mind you could use web sockets to close the previous tab once the user enters in the URL sent by email. Have a look at socket.io for example.
Update 1
There's no way to do this using WebSockets. There's no possible way to close a window that wasn't opened using javascript, and it can only be closed by it's parents.
That is a very interesting idea. I like it. Alas, it appears that, in modern browsers, you can no longer close a window you didn't open through javascript. So if you aren't allowed to run javascript in the email, the best you can do is to redirect the original page to a "thank you" page and leave it hanging around in the browser's tab (but no longer waiting on conformation). Like this:
PleaseConfirm.html:
window.name="need_redirected";
Confirm.html:
var w = window.open("", "need_redirected");
if (w)
w.location="ThankYou.html";
Of course, for old IE, I'd still try to close the old window in ThankYou.html:
window.top.close();
You can still try to set the target, of course, just in case it works, and you can always try putting an onclick attribute on your tag for the same reason:
click here
But that seems to be the best you can do. Bummer.
Neither of the other two answers work, but this one probably will:
In the initial tab, listen for an onstorage event, with a certain key being created, e.g. "userHasConfirmedEmail". When the event occurs, window.top.close().
In the new tab, create that key.
Credit goes to Tomas and his answer.
If I don't implement any updateready event handler and don't call swapCache(), does that mean that the browser will always use the first (oldest) downloaded version of the application?
If no, then why is the swapCache() method needed?
Swapcache makes sure that "subsequent" calls to cached resources are taken from the new cache.
Subsequent meaning after swapcache.
To see this in action try setting the src property of an img dynamically after the
swapcache call in the updateready event (so that the browser loads it at that particular
time). Make sure this image is not already loaded elsewhere in the page since that will
distort this test.
Now change the image and change the manifest files (to force reloading the cached files).
Reload the page in your browser.
You should now see the new version of the image in your rendered page.
Now comment out the call to swapcache.
Make a change to the manifest file and reload the page and thus all resources.
Refresh the page again (to make sure you have a version from the new cache).
Now change the image again and change the manifest.
Again reload the page: now you see the old version of the image.
In the last case, the browser finished loading the new versions in cache, but since
swapcache was not called, the image was still taken from the old cache.
If you do not do any dynamic loading of resources in your page, the swapcache has no effect.
In particular, if you reload the page in the updateready event handler calling swapcache
first has no effect since reloading the page will get it from the new cache anyway.
I have an app with a pretty large cache (>100mb). This takes a particularly long time to swap the cache in (and pretty much locks the browser while this is happening). So I display a message indicating that the app is updating (please wait...), then call swapCache(), then display a new message when it's done indicating completion.
Not sure if this answers your question (as to why it's necessarily needed), but I think it provides a valid use case for swapCache() at least.
Let's imagine 2 different scenarios.
You call location.reload() when the new content is available. The page will reload using its all-new content. applicationCache.swapCache() is not needed in this case.
Your user continues to interact with your page, without any reload. This interaction causes an asset to load dynamically. For the sake of argument, let's imagine that it's a rollover image, and let's imagine that you have just updated this rollover image. Without applicationCache.swapCache(), your user will continue to see the old rollover image. After applicationCache.swapCache(), s/he will see the new rollover image.
So applicationCache.swapCache() without a reload says: "Keep the page looking the way it was when it was loaded, but use any new assets now, as soon as the page asks for them".
The SwapCache method provides a mechanism for the application to be in control of how an when updates are applied. In regular HTML apps, it can be difficult to determine if the correct JS is present on the clients browser.
Also browser implementations vary on when a cache would be updated, I found the iPhone particularly stubborn. swapCache put me back in control of how my app is updated i.e. I could choose to automatically apply the patch or let the user choose when to apply etc.
I was wondering the same thing. I seem to be able to trigger a successful update by just calling "window.applicationCache.update()". If the manifest file has been modified, the 'download' event is triggered, then eventually the "update ready".
When I reload it, it appears to have been applied. I don't seem to need to call swapCache(). I have provision for calling it from the app, but so far have not noticed any effect on the update process.
Calling update() basically eliminates one reload, AFAICS.
swapCache will switch from the previous set of resources listed in the cache manifest (when the running webapp was loaded) to the new set. You are doing this in response to an updateready after all, which signals that a new manifest has been loaded.
This is not to be confused with loading individual resources, for which the usual browser caching policies still apply. In other words you will swap set of resources, but individual resources need their own cache management to ensure they're reloaded when you need them to.
I haven't tried this yet, but it would seem to suggest structuring the code as an "update controller" javascript file that handles the update process, and javascript sources with a versioned filename (or URL) with known entry points.