I have used a:visited CSS for my web application, but the browser remember its history for unlimited time.
How can I set this time till the browser is closed?
That is a browser setting, nothing you can influence with CSS.
Alternatives:
Make the links “different” for each browsing session, f.e. by appending a random GET parameter/query string value, or
do not use :visited in the first place, but keep track of clicked links via JavaScript and sessionStorage or a cookie, and then set a class on those elements every time a page is loaded, to achieve the formatting you want for that state.
You can't. How long a browser keeps a URL in its history is entirely up to the browser and there are no APIs that allow a website to influence it.
Related
If I create a widget and embed it in an <iframe> on a site that is from a different domain, how much data about the parent page can the widget read?
Obviously there's no DOM access, but is there any access to other information, such as whether the parent page has a parent, or what the url of the parent page is?
Normally the content of an iframe served from a different domain cannot access the parent in any way. It's like loading the page in a different browser tab.
However, even if served from a different domain, there is a possible man-in-the-middle attack which wil allow access to the parent DOM. This is easier than it sounds -- anyone who has administrative control over a public WiFi access point could carry out this attack (think Starbucks, hotels, airports.)
It is possible to protect against this attack using the HTML5 iframe sandbox attribute -- see below.
The man-in-the-middle attack works as follows. Suppose your page loads off http://yoursite.com and the iframe goes to http://badsite.org
first http://badsite.org redirects to http://yoursite.com/badpage
This is the step that requires a man-in-the-middle attack. The attacker must either be able to get between the user and yoursite.com, or control the answers to your DNS lookup. The goal is to serve the content of http://yoursite.com/badpage from the attacker's site, not your actual site.
The attacker can then serve whatever malicious code they like from the (fake) http://yoursite.org/badpage. Because this is in the same domain as the main page, it will have access to the parent DOM.
The HTML5 iframe sandbox attribute seems to be the way to avoid this. You can read the spec, but the best description might be here.
This seems to be supported on Chrome, IE10, FireFox, Safari.
The spec says that if the "allow-same-origin" attribute is not set, "the content is treated as being from a unique origin." This should prevent your child iframe from accessing any part of the parent's DOM, no matter what the browser thinks the URL is.
Sandbox also lets you disable scripts, pop-ups, the ability to change the top level URL, and other things.
I did a little google search, and it turns out that normally you cannot access the internal guts of the Iframe if the the content is another domain (same origin policy), however there's an article here which can give you some ways around that.
I have some questions about the :visited pseudo-class:
Based on what do browsers decide when the :visited pseudo-class should be applied to a hyperlink?
Do they take this information from the browser's page history or is it stored per-session or somewhere else?
Is it possible (for the developer of a web page) to control for how long the :visited pseudo-class should be applied to hyperlinks?
(Note: I'm not trying to solve an actual problem, I'm just wondering how it works)
It's applied when a link has been visited based on the browser history. Clearing your history will clear the visited state. There's no "timeout", as far as I know.
It's usually stored in the browser's page history (not per session, except in the case of some sort of privacy mode perhaps).
It simply checks if that link exists in the history, if so it's :visited. As far as I'm aware, you can't control how long it's applied in any way.
You can kind of control it to your advantage by changing the link itself when its target changes. For example, I've seen some message board software that would append the message count to its topic links on the front page, so that the links you have visited would become unvisited when a new message appears in them.
The :visited argument is stored in a users history file, and can only be removed locally.
There is no way to controll that from a server
why do you want to set a timeout for it? maybe there is another way to get what you need.
what you can do is create a random parameter in your link like:
http://www.yourdomain.com/?<random argument>
this way the link always difers, is directed to the same link and then you just throw away the parameter.
#edit yes, it is possible, if you set a cookie and the per user check the last time the cookie was set per link(include the parameter), and if time > the time you want, refresh the parameter
well almost everything has been covered except one thing.
when does it get applied?
when the target page has its onload event. so not immediately.
if you open the link in a new tab in the backgorund you will see some delay before it switches its style. tahts exactly the time the external page takes to load and for the browser to store history/trigger the change.
It only applies to hyperlinks (<a href>), and when an entry is found in the browser history (not session).
My web-app records users via webcam and microphone. I want to use HTML/JS for the controls and content, so I created two separate Flex modules:
* A "Webcam Setup" module that lets you choose your camera and mic input devices
* A "record" module that lets the user record and submit the recording
When I embed either of these on the page, since they access the user's Camera/Mic object, Flash shows the Privacy dialog that says "[mysite] is requesting access to your camera and microphone. If you click Allow, you may be recorded."
The problem is, if I answer Yes in the Setup module, and later add the Record module to the page using Javascript, it again shows the Privacy dialog.
Is there a way to avoid the second privacy popup?
I would think that saying "Yes" for [mysite] would store that permission for at least that session, but apparently not.
What I've tried
I tried combining them into one SWF, adding it to the page once and moving the DOM element with jQuery's append() function when needed. When I move it, however, it reloads and asks me again.
Imagine if [mysite] was, say, blogger.com or livejournal.com (or, if it were still around, geocities.com). Would you want a "yes" response on that site to be good for every page under that domain?
Rememeber, just because you promise (cross your heart & hope to die) not to abuse the security hole you request, doesn't mean they can allow you to have that security hole.
Eventually, I found a usable workaround, similar to what I originally tried (above).
I combined the setup and record modules into one SWF. I first show the setup screen. When the user hits the Continue button on my page, Javascript calls a function in the SWF to swap to the Record screen.
I then move the <div> containing the Flash object to another location on page using absolute positioning, and resize the object.
Previously, I was trying to use jQuery's append() function to move the div within the DOM, and that was causing the SWF to reload. Just changing position and size does actually work.
You could build the "record" component to simply send and receive signals using an API you've created for your "setup" component (which has already been authorized, meaning one auth & two swfs) by using the LocalConnection class:
http://livedocs.adobe.com/flex/3/langref/flash/net/LocalConnection.html
This seems far closer to best practice than the other implementations mentioned, which smell a bit hacky and would probably confuse anyone who may inherit the codebase in the future.
For a specialized purpose with Aweber regarding a newsletter subscription, I have a page loading a nested IFRAME inside, and both reside on the same domain. (Many other stackoverflow posts talk about different domains, but this question deals only with the same domain.) I need a cross-platform way (including browsers as old as the dawn of IE6) for the two to communicate.
For example, someone fills out name and email and clicks a checkbox, and the hidden IFRAME next to the checkbox sits in a setInterval() loop watching for that. When it receives notification, it grabs the name and email and does a form post.
I thought at first that I could just drop a cookie in the parent page, and then the IFRAME child could then sit in an interval watching for that cookie. But my tests show that this won't work. The cookie gets created -- but the IFRAME can't see it. So, I tried the meta-refresh technique in the IFRAME, and again it couldn't see that cookie for some reason.
The only solution I can come up with is that the parent page will take the checkbox click (we use jQuery) and do an AJAX data push to the server into a database. The IFRAME can then check on an interval back to the server via AJAX to see if the database value has changed, and react to it if so. But this seems like an over-engineered solution and I'm looking for an easier alternative that works cross-platform, even in earlier browsers from the timeframe of IE6 and forward.
It's much more simple: In the iframe, you can access the parent variable, which contains the parent window. So you can use parent.document to find the form, read the values, etc.
I asked a question on what is style.css?ver=1 tag?. I learned that developers use style.css?ver=1 to let browsers read updated css, but W.Craig Trader pointed out that is is not good.
My question is, what is the best way to force a browser to read updated css without style.css?Ver=1 format?
Your server should take care of it. It will tell the browser when the file was last modified, and if the browser's cache is out of date, it will download the new version.
More in depth, each time the page loads, the browser does a head request on each item in the page (stylesheets, images..), which the webserver responds to by only sending the HTTP headers without the body, there is a header that specifies when the file was last modified (and possibly more about cache control), and if the browser's cache has a version of the file older than what the webserver says it has, it reloads that content.
An option is to version the filename, like style-1.1.css.