For more information about this, have a look at David Baron’s post, the bug and the post on the security blog.

For many years the CSS :visited selector has been a vector for querying a user’s history. It’s not particularly dangerous by itself, but when it’s combined with getComputedStyle() in JavaScript it means that someone can walk through your history and figure out where you’ve been. And quickly – some tests show the ability to test 210,000 URLs per minute. At that rate, it’s possible to brute force a lot of your history or at least establish your identity through fingerprinting. Given that browsers often keep history for a long time it can reveal quite a bit about where you’ve been on the web.

At Mozilla we’re serious about protecting people’s privacy, so we’re going to fix this problem for our users. To do so we’re making changes to how :visited works in Firefox. We’re not sure what release this will be part of yet and the fixes are still making their way through code review, but we wanted to give a heads up to people as soon as we understood how we wanted to approach fixing this.

These changes will have some impact on web sites and developers, so you should be aware of them. At a high level here’s what’s changing:

  • getComputedStyle (and similar functions like querySelector) will lie. They will always return values as if a user has never visited a site.
  • You will still be able to visually style visited links, but you’re severely limited in what you can use. We’re limiting the CSS properties that can be used to style visited links to color, background-color, border-*-color, and outline-color and the color parts of the fill and stroke properties. For any other parts of the style for visited links, the style for unvisited links is used instead. In addition, for the list of properties you can change above, you won’t be able to set rgba() or hsla() colors or transparent on them.

These are pretty obvious cases that are used widely. There are a couple of subtle changes to how selectors work as well:

  • If you use a sibling selector (combinator) like :visited + span then the span will be styled as if the link were unvisited.
  • If you’re using nested link elements (rare) and the element being matched is different than the link whose presence in history is being tested, then the element will be drawn as if the link were unvisited as well.

These last two are somewhat confusing, and we’ll have examples of them up in a separate post.

The impact on web developers here should be minimal, and that’s part of our intent. But there are a couple of areas that will likely require changes to sites:

  • If you’re using background images to style links and indicate if they are visited, that will no longer work.
  • We won’t support CSS Transitions that related to visitedness. There isn’t that much CSS Transition content on the web, so this is unlikely to affect very many people, but it’s still worth noting as another vector we won’t support.

We’d like to hear more about how you’re using CSS :visited and what the impact will be on your site. If you see something that’s going to cause something to break, we’d like to at least get it documented. Please leave a comment here with more information so others can see it as well.

171 comments

Post a comment

  1. YuriKolovsky wrote on November 11th, 2010 at 7:57 am:

    @Sebastian
    The problem comes from javascript being able to share a users history using css, now I was appalled with the solution of just disabling :visited all together in the new firefox 4, just having some color changes means nothing.

    Current: Global History->Sitewide CSS->Sitewide Javascript->Site
    Should be: Sitewide History->Sitewide CSS->Sitewide Javascript->Site

    Makes more sense to me, now why would Mozilla not implement this? Either they are stupid, which I doubt is the case, or there is some other reason not to implement it, something that you and I don’t know, I just wish some Mozilla developer would share their insight.

    Reply

  2. cw3theophilus wrote on November 12th, 2010 at 7:10 am:

    I am Web Designer and I am appalled at this solution to the privacy problem. I use :visited everyday to set apart links in my site that the user has been to so that the user doesn’t get confused or lost with what they have visited and what not.I also use it with JS to write a new CSS rule to show which page the user is currently on. Especially in my nav bar.
    Many times I need to use opacity, gradient backgrounds, borders, font-weight, text-decoration and background images to set them apart.
    I do not care about getComputedStyle as I practically never use it.

    My suggestion is to either limit :visited to links in the same domain – I mean who cares if a site can see which pages in their site you have visited; they can anyway do the same thing with google analytics – or to disable getComputedStyle completely as only very advanced sites and applications ever use it.

    If this feature is not updated and fixed I will not be upgrading to FireFox 4 but will be sticking with version 3 even if I can’t use all the nice HTML5 features.

    Reply

    1. André wrote on December 15th, 2010 at 1:48 am:

      Well you can stick with FF3 if you want, but the users will be moving on to ff4 (or the compatible mozilla seamonkey 2.1), and that is what counts.
      Personally I am very pleased that bandwidth-robbing special effects such as images are being abandoned.
      It you can’t produce decent effects with foreground, background, border, and outline colours you’ll be left behind by others that can.
      And Mozilla (and eventually other) users will appreciate the benefits of better privacy and less wasted bandwidth.
      As well as fewer overly complicated web pages.

      Reply

    2. e.r. wrote on June 7th, 2011 at 1:50 pm:

      yes.. i hate that new limitation.. now i have to save in a db which link was clicked by a user to hide it afterwards.. change it to domain limitation!!!!!!

      Reply

  3. Gary Hvizdak wrote on November 15th, 2010 at 11:07 pm:

    Presently I use a:visited { background-color : transparent; }. I just reloaded Google Chrome after having un-installed it many months ago and discovered that some of my links are blacked out after having been visited. All of the affected links have a background color set via the :link pseudo class. Interestingly, links that set the :visited background color to the same :link background color don’t have this issue.

    So I\m wondering if this new Chrome bug is related to the proposed Firefox :visited change?

    Reply

  4. ARCN wrote on December 10th, 2010 at 8:59 pm:

    I hear IE 9 is going to have a “no follow” browser button one can engage. Can FF not have the same thing without having to do all the other stuff you have mentioned?

    Reply

  5. Paul wrote on December 12th, 2010 at 1:06 am:

    You guys really don’t get it do you? No one cares if web developers upgrade or not to Firefox 4. Users will and developers will have to cope with these changes so stop boycotting instead try to come up with constructive ideas. Most people saying they won’t upgrade sound like little kids who got their candy stolen.

    You might be affected (a niche of the web developing world will probably feel the impact of this change because most only use color), but users do not care, as they did not care about IE6. You did not use IE 6 yet 65% of your users did, did you stop fixing bugs for it back then? This thing in Firefox will not even be a bug, it will be a well documented security feature described even before the official launch. Most normal users WILL upgrade to FF4 and no one will care how you feel about that. BE F-ING CONSTRUCTIVE OR SHUT UP.

    I have been a web developer for more than 6 years and I really don’t think that having to code to this limitation will actually hurt me.

    Reply

    1. ray wrote on December 25th, 2010 at 5:17 am:

      Well said.

      Reply

  6. awsdert wrote on December 12th, 2010 at 4:06 am:

    I think that this is a good change, I mean all you should need for indicating a visited element is a change of color and what would a good developer need with the users entire history. Furthermore to get a user’s site-wide history for the session the server can simply be program to create a list for each session, then the list can be used later by scripts that need it (with a user-h.php or something similar to pass the list to JavaScript via AJAX.)

    Reply

  7. Joe Honton wrote on December 13th, 2010 at 8:32 pm:

    Before taking this step, please consider the Electronic and Information Technology Accessibility Standards (Section 508), published in the United States Federal Register on December 21, 2000, to wit:

    § 1194.21 (g) Applications shall not override user selected contrast and color selections and other individual display attributes.

    § 1194.21 (i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

    § 1194.22 (c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

    Reply

  8. awsdert wrote on December 22nd, 2010 at 1:32 pm:

    While those are important to consider it is also important to consider your target audience, for example a gaming site is unlikely to be visited by the blind and would normally have been designed with colour-blind people in mind.

    Reply

    1. Andrew wrote on December 28th, 2010 at 9:56 pm:

      Not to mention that CSS has nothing to do with user selected colors. That is something you set in firefox’s settings, and I’m pretty sure that firefox doesn’t let CSS over ride this anyway.

      Reply

  9. YuriKolovsky wrote on January 4th, 2011 at 1:39 pm:

    @Paul
    What truly IS important is if firefox is taking the right path here, because in my opinion they will be fixing this so far “small feature” for a long time to come…

    Reply

  10. Crystobal Lions wrote on January 9th, 2011 at 1:23 pm:

    I am a Fire Fox user and I am appalled that some developers are after so many years still functionally security illiterate. Developers, if you cant fix your golden code or go along with a secure framework or support a secure browser then step out of the way and let those who intelligently error on the side of security.

    Really, If you insist in bow to the pixel whore Babylon java script gods where security is a non thought or after thought at best, do it the privacy of your own local variable.

    Reply

    1. Kafpauzo wrote on April 20th, 2011 at 2:09 am:

      I hate this change. I want to use FF4 but because of this change. I’ll have to keep using FF3.

      Why? Well, it’s because the web is a confusing and cluttered space, and it’s hard to keep track of things you visited already. It’s frustrating to click a link, wait, oh noes, I visited this already, and then go back and doing it over again. It’s a guessing game with this change. A lot of developers keep visited links the same color as normal ones to keep the website clean and consistent.

      I use Stylish. Made my own script to add a slight glow around links I’ve visited. It overrides developers styles. It’s made my browsing of the internet way more efficient. I can visually see where I’ve been. It’s less frustrating.

      There are better ways to protect privacy. This seems like a lazy approach. Please change it back to how it was, and find a better way. It affects users as well, not only developers. A better fix would be to set the default history cache to only keep 1 or 2 days of history.

      I really want to use FF4 as my default browser. This change is making me stay on an older version.

      Reply

      1. Paul Rouget wrote on April 20th, 2011 at 2:55 pm:

        @Kafpauzo You don’t get it. What your describing is not Firefox current behavior. Re-read the article. getComputedStyle is lying, but that doesn’t change anything for the end-user, who will still see the link “purple”.

        Reply

        1. nomail wrote on May 5th, 2011 at 2:01 am:

          FWIW, i have a bookmarklet that outlines visited links/images, it no longer works — this new feature should have been optional. I appreciate firefox looking out for my privacy by default, but I don’t appreciate losing the choice — i understand its part of the philosophy to have less configuration options, but dammit, we need to have more :)

          Reply

          1. FLskydiver wrote on May 8th, 2011 at 7:37 pm:

            Don’t like this isn’t a user option. I use a bookmarklet to hide text and image links I’ve already visited and Firefox 4, which I’ve just updated to, kills it.

            Please allow us to choose not to use this “feature”!

  11. sdfpokdfsj wrote on January 15th, 2011 at 6:02 am:

    Keeping the old behavior within the current domain like someone else mentioned sounds like a good idea.

    Reply

  12. stfuandrtfm wrote on January 21st, 2011 at 2:25 pm:

    It’s about time someone has taken the initiative to enforce function (security) over form. I don’t give a rats hind end about the color of the hyperlinks as to whether or not i’ve been on a page, and if the only solution you can come up with is to use a method that can spill my computers guts to the highest bidder, then please, send me your URLs to your pages so I know not to ever visit them again. It’s developers like you who have let the masses of targeted advertising reign the web.

    Reply

  13. Peter wrote on January 23rd, 2011 at 6:36 pm:

    Quick spontaneous post before I forget: If you can only change color, then you lose some accessibility. If for example all unvisisted links are bold and visited are of normal weight then it is much easier to see for someone with a degree of color-blindness.

    And I really don’t get the reason for limiting what will be applied to visited links if it will simply lie when asked. All it seem to do is lessen design and accessibility abilities without a real need to do so. Let functions lie all they want but leave the design part out of it.

    Reply

    1. Matti Schneider-Ghibaudo wrote on January 24th, 2011 at 5:03 am:

      Please read Christopher Blizzard’s comments and mine (first page, search for “April 23rd, 2010 at 5:20 pm”) :)

      Reply

  14. MJ. wrote on February 3rd, 2011 at 8:39 pm:

    Are You KIdding Me? Good Grief ! If Firefox Crashes Once More This Today/Week;. I’ll Try Not To Scream. WTH ?

    Yet I Do Appreciate The So Called “Security” Update Of Firefox. About Time Someone Picked Up Their Brains And Skills And Produced With Them.. Has Been A Long Time Coming.
    Am So Very Untrusting Of Google/Chrome Google Always Have Been. Will Never Use It Ever.
    Absolutely Did Not Appreciate Chrome Google Downloading It’s Self On My Puter. Right Pass McAfee Too !

    Reply

  15. trlkly wrote on February 9th, 2011 at 4:38 am:

    The thing is, you don’t break functionality to fix a bug. If the problem is that certain styling on visited links can give people information. Bold is screwed up because it makes text take up more space, which can be queried. The way to fix that is either to do what Chrome does and keep bold the same size as nonbold.

    Loading a background picture is a problem because it queries the server. So make it where the background is already preloaded upon page load. Heck, that would fix pretty much everything–analyze everything as if all links had been fixed.

    Finally, fingerprinting is a concern, but a lot of people don’t give a crap. Those of us that do aren’t going to run Firefox vanilla in the first place. We’ll use adblock, noscript, and, in risky situations, the built in private browsing mode.

    This is just a step backwards. JavaScript + CSS + HTML5 is supposed to be a fully functional system that will replace many overbearing plugins. Removing features so that people have to go back to relying on Firefox is just stupid.

    I really wish programmers would get off their soapboxes and design what the users want, rather than thinking they know better than the users they are supposed to be serving.

    BTW, I find it funny that they suddenly are okay with breaking standards, when before they didn’t give a crap. Designers are going to design to de facto standards, not what Firefox elitists tell them to do. Stop acting like IE.

    Reply

  16. Cycron wrote on February 26th, 2011 at 3:43 pm:

    I think these changes should be enabled by default, but there should be a way to disable them.

    Reply

  17. Frank Willwright wrote on March 1st, 2011 at 2:34 pm:

    I dont know. Dogs are the way to express feelings about CSS I would prefer yellow or brown. Default or not. Fingerprinting is a concern not nearby the wastelands of tomorrow and beyond. We are just little sparks in the immense web of information….Who cares! As time itself will catch up eventually. Regards!, Frank

    Reply

  18. Steve wrote on March 2nd, 2011 at 2:09 am:

    Visited links are useless IMO. I doubt anyone will really notice if the whole visited concept went away. I for one have my history wiped when I shut down my browser, so I rarely see visited links. If your site is so complicated that someone needs to see where they have been then use cookies to track the user on your site or rethink your site, there might be a design problem.

    That said, there will always be people who like them. So allow them to be enabled please (visited off by default). Let us choose to risk having our history looked at. Then when most websites decide to stop using visited altogether you can finally totally remove visited features..

    Reply

  19. Kafpauzo wrote on March 3rd, 2011 at 10:54 pm:

    The chosen solution is far more drastic and has far more wide-ranging impact than what’s necessary. A better solution would be this:

    – To thwart the non-JavaScript attack, where a server detects CSS background-image fetches: Regardless of the unvisited/visited state, always fetch both images, the visited and the unvisited, always in the same order. If other CSS properties exist that can have a similar impact, always act as if rendering both the visited and the unvisited versions.

    – To thwart detection by JavaScript: Determine the link’s dimensions and the resulting text flow for both cases, the case with the visited version and the case with the unvisited version of the link. Flow the page in such a way that there’s room for either version. Let the user see the correct version of the link in this space. Let JavaScript see the style settings of the unvisited version.

    – Do the same in cases of siblings and nesting. As above, prepare room enough for either version, display the right version, let JavaScript see the unvisited version.

    – Forbid only those CSS properties whose impact on rendering is so drastic that the above cannot work neatly, i.e. forbid properties like float, clear and display.

    With this solution, the huge number of websites that use various decorations in fully legitimate ways would still work fine. All they’d notice would be minor ugliness in the unusual cases where :visited is indicated with size-changing properties like boldface or border-width. And the only problem on these sites would be that the link size and text flow would become a bit ugly. The style’s signalling functionality would still remain.

    Reply

  20. Kafpauzo wrote on March 4th, 2011 at 2:12 am:

    Just in case my explanation wasn’t clear:

    In the non-JavaScript case, although you fetch both the visited and the unvisited background images from the server, you let the user see only the one that is right according to the link’s visited/unvisited state.

    Reply

  21. Joe wrote on March 5th, 2011 at 3:39 pm:

    There was a comment above stating “don’t remove functionality to fix a bug”. This assumption about good security is not realistic. There is no way to be secure without some restrictions on both the end user and the developer. Removing small pieces of functionality that prevent developers and users from using some parts of a functional piece is a non-sacrifice here. Data mining and identity theft are a much bigger issue than the ability to use a background image on a visited link. Good for the Mozilla Foundation! They have been brave enough to care for users security more than web developers pain points.

    Also there is a VERY good reason they removed this from a development standpoint. It has to do with separation of concerns. If you want to save state or be aware of previous activity there are mechanisms in place to do that. Using a presentation element to do what cookies or server side persistence should is just bad problem solving. Persistence and application awareness should not be mixed with presentation.

    Reply

  22. th wrote on March 5th, 2011 at 7:06 pm:

    the new Firefox just rocks.

    Reply

  23. Hawk wrote on March 8th, 2011 at 2:46 pm:

    I’m not liking these styling limitations.

    Why not limit getComputedStyle to URLs that have the same domain as the site that the JavaScript is running on? If the domains don’t match, then ‘lie’ and return a value as if the link is unvisited. If it’s the same domain, should be no problem.

    Why does CSS have to be crippled like this?

    Reply

  24. T. wrote on March 9th, 2011 at 4:06 pm:

    Thank you Mozilla. As a user who just learned about this issue from a link in the Firefox 4 RC documentation, it is nice to know my privacy is in good hands even if lazy developers are angry that they can’t use some obscure CSS feature.

    Reply

  25. Tar wrote on March 11th, 2011 at 7:35 am:

    This change breaks “hide visited” type bookmarklet functionality, for example the one from:
    https://www.squarefree.com/bookmarklets/pagelinks.html

    If someone has a solution how to make “hide visited” work on FF4/SM2.1 then I’d really appreciate it.

    Bug 147777 – :visited support allows queries into global history – https://bugzilla.mozilla.org/show_bug.cgi?id=147777

    Reply

  26. Carl wrote on March 11th, 2011 at 5:38 pm:

    Could someone “in the know” – preferably from Mozilla – please comment on all the suggestions that have been made about crippling some JavaScript functions instead of crippling the CSS?

    Most recently, “Hawk” wrote:
    “Why not limit getComputedStyle to URLs that have the same domain as the site that the JavaScript is running on? If the domains don’t match, then ‘lie’ and return a value as if the link is unvisited. If it’s the same domain, should be no problem.

    Why does CSS have to be crippled like this?

    Reply

  27. Glenn wrote on March 12th, 2011 at 10:05 am:

    This is about as good an idea as school uniforms are… and continuing to have to wear them once you graduate; but, yeah, sure… lets break accessibility for everyone, too. At the very least you should allow both user and user agent CSS to modify WTH it wants to (pssst: that’s why it’s called “cascading”).

    Reply

  28. The Neighbourhood Nerd wrote on March 13th, 2011 at 2:04 pm:

    Why not have an alert that warns the user that the site is running this code?

    Warning: This site is attempting to access your history. Allow?

    And an option to block this behaviour permanently.

    Reply

  29. YuriKolovsky wrote on March 15th, 2011 at 2:44 am:

    @The Neighbourhood Nerd because that is near impossible, it gets this info from different places where you least expect it.

    Reply

  30. Peter wrote on March 16th, 2011 at 5:47 pm:

    “Don’t rely on color alone.”
    http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#gl-color

    “Ensure that all information conveyed with color is also available without color, for example from context or markup.”
    http://www.w3.org/TR/WCAG10/#gl-color

    Surely standards are what Firefox is all about? Fooling the javascript is sufficient, you don’t have to compromise standards and accessibility on top of that. If a script can’t detect visited links then that is what counts, so there are no reasons to limit CSS just for the sake of it. Such a simple thing as to “unbold” or having a faded background on a visited link in menu would be impossible even if it would greatly increase scannability.

    I can only echo that once again, surely standards must count for something and certainly people with accessibility issues must be taken into account? And surely, feeding false values into the script is far sufficient? The values are already there, there is no real need to cripple CSS. No real need whatsoever.

    Reply

  31. Peter wrote on March 16th, 2011 at 6:01 pm:

    @Carl: I concur, external links are what is causing the whole problem, right? Then those links can suffer the consequences if any. There might be a problem with web hosts that share the same domain but that should be easy to work around with regards to URL hierarchy.

    But I still thinks that just fooling the script with false values (color, border, images, layout – everything will “look” like it would if all links would be unvisited) are the best way to go.

    Reply

  32. MattG wrote on March 17th, 2011 at 11:09 am:

    The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
    – 4th amendment of the U.S. Constitution

    My browser history is no doubt one of my effects. Any websites gleaning my browser history without a warrant are violating my 4th amendment rights. Shame on them. :P

    Imperfect security is not an issue, it’s the people who want to use it against you – that’s the real problem. Sometimes you block them, sometimes you allow them through, but either way, you teach them a lesson if you can.

    Reply

  33. Pingback from Mozilla Firefox 4 Final oficial a partir del 22 de Marzo :Luctus on March 19th, 2011 at 11:35 am:

    [...] pone su privacidad en primer lugar, se corrigen algunos fallos que permitían a los chicos malos husmear y exponer el historial del [...]

    Reply

  34. Pingback from Things You’ll Love About Firefox 4.0 | Robert Accettura's Fun With Wordage on March 21st, 2011 at 8:00 am:

    [...] Just a FYI, this no longer works. [...]

    Reply

  35. Pingback from Mañana lanzamiento de Firefox 4 | yQueJue on March 21st, 2011 at 8:09 am:

    [...] pone a su privacidad en primer lugar, se fijan las fallas en algunos estándares web que permiten a los chicos malos que husmear y exponer el historial del [...]

    Reply

  36. Duncan wrote on March 24th, 2011 at 1:00 am:

    This really messes up usability for marking visited links!!

    Both my parents have short term memory loss (my Mother has Alzheimer and father has had a few strokes). They do not remember if they used a link or not.

    So they use a “hide visited” links bookmarklet I installed for them. Works like a charm but it breaks on FF4.0.

    This is doubly annoying as it is very hard to train them to use a new browser, which is my only option unless somebody has an alternative solution?

    Reply

    1. Hemilton wrote on April 22nd, 2011 at 4:01 pm:

      If they can’t remember having already visited a site why should they care?

      Reply

  37. One wrote on March 25th, 2011 at 7:12 am:

    The user should be allowed to disable this feature. I used a custom global stylesheet via addon to change visited links opacity, and now I cannot. I’m not a developer, my :visited was usefull for ME.

    Reply

    1. Tom wrote on March 31st, 2011 at 3:55 pm:

      I agree. I used userContent.rss to force the style of visited links and now this no longer works. I can understand why the change was made but the potential information leak is something I am willing to live with.

      This should be configurable via about:config (and disabled by default, of course).

      Reply

  38. marc wrote on April 9th, 2011 at 5:05 pm:

    this is a stupid idea to disable the :visited styles.

    it really shows a lack of creativity of the programmers in charge, i’m sure there would be other ways to solve this small security issue.

    sad this came through, even IE9 and Chrome10 followed.

    Reply

  39. ranimi wrote on April 12th, 2011 at 1:42 am:

    I want the :visited functionality back too!
    I agree with Tom:
    “This should be configurable via about:config (and disabled by default, of course).”
    Ranimi

    Reply

  40. GlitchMr wrote on April 14th, 2011 at 10:34 am:

    And the webmasters will make our cookie to store visited links, you click link, it gets stores into cookie. Making this thing complex.

    Reply

    1. ehsan wrote on April 29th, 2011 at 10:59 pm:

      salam

      Reply

  41. Alan Gresley wrote on April 19th, 2011 at 9:36 am:

    Is this security issue so hard to understand.

    [href*="http://www.google.com/"]:visited {background: url(images/gallery/im1.jpg);}
    [href*="http://www.google.co.uk/"]:visited {background: url(images/gallery/im2.jpg);}
    [href*="http://www.google.com.au/"]:visited {background: url(images/gallery/im3.jpg);}

    If a background shows, then you have visited http://www.google.com/.
    If a background shows, then you have visited http://www.google.co.uk/.
    If a background shows, then you have visited http://www.google.com.au/.

    Reply

    1. Alan Gresley wrote on April 19th, 2011 at 9:38 am:

      The HTML was striped from the anchor links.

      Reply

  42. Tomcat76 wrote on April 23rd, 2011 at 8:18 am:

    What I don’t get: if you’re still allowing color settings, then what’s the point in disallowing other basic CSS settings such as font-weight? It makes no sense to me.

    From a personal stand, I’d like to say that my security is my own business. I don’t mind if an application comes with a set of basic security measures, but anything as drastically impacting CSS standards support as this should be configurable.

    I agree that full :visited control via CSS is not an absolute necessity, but the current options are too limited.

    Reply

  43. Henrik wrote on April 30th, 2011 at 7:08 am:

    I run a website that doesn’t do much more than tell people about their browsing history, and – ofcourse – people are fully aware of how this works when they enter the site and run the diagnosis tool, I have no choice but to let this site “go to history” now. :-(

    Reply

  44. Henrik wrote on April 30th, 2011 at 7:12 am:

    Tomcat76: The reason as to why font-weight, border-size, height, width etc is disabled is probably because otherwise we would be able to use .offsetHeight, .offsetWidth, .offsetTop and such things to determine whether an url has been visited or not.

    Reply

  45. Eric wrote on May 8th, 2011 at 3:23 pm:

    I don’t really care about this “feature” nor am I worried that some site knows where I’ve visited. Please give us the option to disable it.

    Reply

  46. ben wrote on May 14th, 2011 at 4:47 am:

    Having been a Firefox evangelist since FF1, I’m not going to use FF4 with this “feature” (not that you would care…). However, I feel that many other people think like I do.

    I think you’ve come to a point in development where you start (like many other companies) to take the wrong way; instead of trying to impose “your way” on us (thought, we overcame the totalitarian regimes – or M$ for that matter) you should give us a note and leave it up to us whether we want this option or not (=> implement a switch!).

    Just to make clear why I consider this option useful: Often – when browsing big link lists – the FF 3.x functionality allows me to tell the links I already visited from the ones I haven’t *although they might have different labels*.

    Reply

  47. marc wrote on June 1st, 2011 at 10:01 am:

    Hi there. I never used the :visited tag until today because of lazyness. Still the question arises if it wouldn’t have been enough to restrict the usage of :visited to links pointing to the same domain / site, instead of disabling the functionality alltogether. To determine if a user clicked on some link in ones own domain is possible by other means, so there’s no real security problem there.

    Reply

  48. Glenn wrote on June 2nd, 2011 at 1:26 pm:

    You know, given that you’re going lie to any application/site trying to “peek” into your “visited history” by saying “Nope, never been there.”, then why is it you feel the need to also screw the users ability to use CSS to style the links the way he/she wants to? For authors/site styles, go ahead–I don’t care. But for user/user agent styles, leave MY browser/pages alone to let ME style then as I want. The gall of some people…

    Reply

  49. Pingback from Mozilla Firefox 4.0 RC2 — Hiphopboy's Blog on June 9th, 2011 at 9:53 pm:

    [...] CSS :visited selectors have been changed to block websites from being able to check a user’s browsing history [...]

    Reply

  50. Pingback from Privacy-Related Changes Coming To CSS :visited « EvoTuts on June 25th, 2011 at 4:53 am:

    [...] this article by Mozilla, who explain what they are doing to help crak down on this, check it out here. Feel free to post up some comments, letting us know what your view on all this is. June 25, 2011 [...]

    Reply

1 2 3

Add your comment

  5.