In a JSF application, I want to remove a session-scoped managed bean when the user closes their browser window. I've used a link before that executes the following:
session.removeAttribute("<nameOfManagedBean>");
This seems to do the trick nicely. However, I'd like this same code to run even if a user clicks on the "X" on their browser.
Is their some way of detecting this event properly on any browser?
In any browser? No. Even getting this to work in some browsers (major browsers, assuming javascript is on, etc...) is no piece of cake because it's not that easy to distinguish between user closing the window altogether, navigating to another site or even another page of your application.
Perhaps you can use session timeout instead? Either by setting it directly via setMaxInactiveInterval() method or - if you only want to remove this single bean while leaving the session itself intact - by periodically checking getLastAccessedTime() via background thread and removing the bean once timeout reaches whatever value you deem necessary.
As an aside, I have solved this problem specifically for Internet Explorer 6.0 (the browser I am supporting for my client...yes, my head hurts too after reading that sentence...) utilizing the ICEFaces JSF Framework. I have written up a description here.
Related
So I'm looking for a work-around the whole blocking off opening local files from the browser. What I'm thinking is, I could have some script that, when it is activated, it initiates a set of keys that activate a shortcut that opens up the specific local file with that shortcut assigned.
I may be crazy, but is this possible?
Unfortunately, I don't think this is possible on the browser-side of things, which is what I'm assuming you're talking about?
The short answer is that browser shortcuts cannot be triggered through JavaScript.
You could try to directly navigate to the file in JavaScript by navigating to a file://..../ path, though I'm almost certain that this is not permitted as it would be a huge security flaw in the browser.
Recently, we found that Firefox had made a change towards plugins, such that the user will be temporarily blocked from running them if they are not using the latest version. Our site requires Flash to play sound and interact with the user's webcam/microphone, so we need to do whatever we can to ensure they're not getting these warnings.
One way suggested to me is to create a small Flash control, and wait for it to tell Javascript that it's been initialized. If not (and the user is using Firefox) then they are taken to a page prompting them to update. This may work, but I worry about its reliability, and about running it on every page in our site.
Alternatively, I've been researching a way to use Javascript to detect versions, without making a Flash control. I not only need the user's current version of Flash, but also the version Firefox will expect - and I haven't found an autonomous way of doing so. I don't want an admin to have to change a small value each time Adobe releases a new version. Does anyone have any advice how I could find Flash's latest available version, or an alternate way to solve my problem?
I recommend you have a look at SWFOject and the Express Install option which should ease upgrading considerably.
I just noticed someone upvoting this question, so I thought that I would provide my eventual solution, which I think reduced the impact of a recent issue where Firefox blocked the most recent edition of Flash, pending Adobe's fix.
Basically, I went with a variation on the second paragraph in my question. It does not direct the user to a new page; instead, it opens a dialog over the current page that explains it's having issues communicating with Flash. (It does not specifically say "Your Flash is out of date" because this can also happen if the browser is hiding flash under a Yes/No user dialog). It also contains a small fake flash object, with the idea being that if the browser wants to display a security warning, accept prompt, etc., it can do it inside that space.
The dialog goes away on its own if said Flash control ends up making its callback to JavaScript. It also installs a variable under sessionStorage so we don't bother checking for it again (Flash takes enough time on some computers that you might see the dialog for a split second).
http://i.imgur.com/s4ZQI.png (Can't post image because I'm a new user)
Age old question; is there any way to make a piece of JavaScript safe to use on Internet Explorer without having the security warning popup box. The JavaScript I'm using is simply a drop-down sub-menu that appears when you hover over a link.
If it's something to do with the way the JavaScript is coded, I can link if needed.
Thanks
Assuming that your problem is caused by testing pages from your local disk (and not through some really esoteric scripting) either:
Run a web server and test your pages on that
Give your pages the mark of the web
The point being to run them in a security context that allows scripts to execute.
Background
Detection of hash change in the URL and fixing the forward/back button are two requirements for libraries that deal with Ajax history. There's two schools of thought for implementing these libraries. You can have a poller constantly check the URL (bad browsers don't have the onHashChange event). Or you can use a hidden iFrame to add points in your browser history. One may think the hidden iFrame is better than polling, but the hidden iFrame does not update the outer browser's URL. So if a user wanted to share her current state in the web application, she would always be sharing her initial state.
Question
Is there any technique for Ajax history that both doesn't require polling and also updates the main browser's URL?
How about a combination of the two techniques? change the url, as well as use the iframe. ignore hashChanged (on good browsers), and just parse the hash code on dom:ready
Looking at your comments from the original question, I would recommend using the iframes method for IE and polling for other browsers.
Check out Real Simple History if you are looking for a library that handles this specifically and you want a basis to help roll your own.
If you are just looking for the functionality of keeping your page's state in an Ajax UI, dojo supports this with the dojo.hash() shim. This method creates the onhashchange event for browsers that do not support it and manages the state of your back button. It uses a mix of polling and iframes depending on the browser (iFrames are used specifically in IE versions < 8).
Okay so it's sorta pointless considering that even if there was support for this you could still open more than one instance if you have more than one browser installed, but I was wondering anyway.
Just to emphasize what others have said, No. This is entirely a server-side problem.
I hope not. This restriction would be a pain to users and only underline a problem in the Web Application Infrastructure.
JavaScript and HTML are rendered and run within the browser and have no control over the browser itself. It would be quite dangerous to give them the ability to manipulate and restrict the behavior of the browser.
What are you trying to achieve by restricting them?
If it is a webapp they need to log into I would just restrict a user from being logged in more than once at a time. Other than that would wouldn't want to restrict their opening of the actual window