Closed Bug 477882 Opened 15 years ago Closed 14 years ago

frame-targeted visited links disappear when closing and reopening Firefox (should not be considered EMBED visits)

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 4.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: earittap, Assigned: mak)

References

Details

(Keywords: dataloss, Whiteboard: [requires patch in bug 549340])

Attachments

(1 file, 1 obsolete file)

patch v1.1
6.87 KB, patch
dietrich
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

When I restart Firefox visited links do not show past 1 day. The firs thing I checked was the setting for number of days in History. I have the Keep History set at 90 days. It repeatedly happens. Makes it difficult to find new posts in online discussion forums. Clear private data is unchecked.

Reproducible: Always
Do you have some security software installed that modifies our database files ?
(Spybot, CCcleaner, ...)
Component: General → Bookmarks & History
QA Contact: general → bookmarks
No Spybot or CCcleaner.

I use Trend Micro Internet Security (PC-cillin) which includes spyware protection. However, I have it set to only scan for spyware once a month. It has only built-in security features for the web and I could check/change settings if I know what I am looking for. :)

pranderson
Good news (think)! I installed FF 3.06 last night and so far today all my visited links are showing as they should. I will continue to test this for the next week and if the problem returns I'll let you know.

Thanks
PAnderson
Great !
Would you please add you comment and change the Status to resolved/worksfome if it works for you ? That would save a little bit of my time, thanks !
I spoke too soon, which is why I wanted to wait a few days to see if FF 3.06 really solved the problem. This morning all the visited links except for yesterday's are new & blue again. Sigh. Back to square one. 

Is there some setting in History that could be causing this? Am I wrong to expect visited links to last as long as the days I have set in History? Some cache file setting perhaps? 

PAnderson
>Am I wrong to expect visited links to last as long as the days I have set in >History?

No, that is the correct expectation.
Here are the things that could happen:
a) external Security Software writes to our files, known for example from Norton360 and many other security Software
b) Firefox restores a backup for some reason but that would mean that added bookmarks should be also lost.
c) a bug in Firefox that it deletes the history (unlikely because all users should be hit by this)
d) an Firefox addon doing this
(In reply to comment #6)
> Here are the things that could happen:
> a) external Security Software writes to our files, known for example from
> Norton360 and many other security Software

If you can recall what it was in Norton that was causing the conflict, I'll check and see if there's something similar in my PC-cillin. PC-cillin has a software history cleaner, but it is set (by default) to only clean these files manually. I double-checked. Besides that, under its browsers section, it only targets Internet Explorer. I'll check on line in their knowledge base and see if I can find something about Firefox conflicts. 
---------

> b) Firefox restores a backup for some reason but that would mean that added
> bookmarks should be also lost.

I agree, so I doubt that this is the problem unless it's related to some sort of cache limit???

> c) a bug in Firefox that it deletes the history (unlikely because all users
> should be hit by this)
-------------

Is there some sort of cache limit for stored files? Seems like I read about it somewhere in my search for a solution. If there is, can I increase the capacity in about:config?

--------

> d) an Firefox addon doing this

I have Adblock Plus and Stylish. I tried using Stylish to change the visited link colors, but of course, that only works if there are seen as visited, which was kind of useless. :)  I have since deleted that code. So, it's installed, but it doesn't have anything in use.

PAnderson
Read bug 471986 or bug 452469 for software that writes to places.sqlite 

>I agree, so I doubt that this is the problem unless it's related to some sort
>of cache limit???
This happens if the original file is detected as corrupted. But restoring the places.sqlite from the automatic backup will also restore an old version of the bookmarks because Bookmarks and History are in one file.

>Is there some sort of cache limit for stored files?
4GB for fat32 file system, i don't know about other limits

>I have Adblock Plus and Stylish. I tried using Stylish
I don't think that Adblock will do anything with the history but I don't know about stylish.
Can you please close Firefox and move the file places.sqlite in your profile to another location but don't delete it because it contains your bookmarks.

http://support.mozilla.com/en-US/kb/Profiles
Okay it's moved, so now what? I had to open Firefox to reply to this and I see it created a new places.sqlite.

PAnderson
Does it work now with the visited links ?
First of all after moving the places.sqlite file ALL my visited links disappeared. :)  Let me play with a day or two and I'll see if the new visited links stay put.

Since I this problem only occurred in version 3, are you thinking maybe the carry over of this particular file from version 2 might be the problem? (Just thinking out loud)

I report back later...
PAnderson
FF2 doesn't use sqlitw, it used bookmarks.html and that caused several lost bookmarks files and sqlite should be more robust.
So far I still have my visited links. I am crossing my fingers! If it continues for the next 3 days, I'll mark this as resolved.

PAnderson
Dang it.  The visited links disappeared again!  I'm beginning to wish I never upgraded to version 3. Sigh. 

I'm willing to be a guinea pig if you have any more ideas to try, Matthias. After pondering this a bit, I'm wondering if it's this particular site, or rather the particular page.  It only seems to be the forum of this one site where I teach. The forum is set up in frames. I can't give you my classroom page link since it's password protected, but I can show something similar on the same site. Maybe you can figure out something from looking at the code. I don't know what software the site owners use, but if there is some little tweak they can do, I can ask them.
 
http://www.quiltuniversity.com/StudentLounge/student_lounge.html

My classroom forum is set up the same way as the above. I can have up to 100 students, so I REALLY REALLY need to be able to keep those visited links so I don't get lost in the questions I've already answered, LOL. I don't have a lot of time for surfing, so I can't be 100% sure it's just this site, or if it's all my visited links. I can say I did not have the problem with IE or FF 2. 

Thanks in advance...
PAnderson
I faced with the same issue in Firefox 3.5. It is reproduced on Linux and Windows machines. I have created backup copy of places.sqlite and deleted original file. Firefox created new one, but after restarting it still don't remember visited links. I have watched places.sqlite with SQLite Database Browser: "select count(id) from moz_historyvisits;" always returns 0.
I have the same issue in 3.5, but it might be different from what's being commented here so I'll take you through what happened with me.

I kept the history as normal since last reinstalling my PC, which was only a couple of days ago, and last night (Sunday NZ Time) I had history recorded from Friday upwards. But when logging on today the history from Friday and Saturday was missing and I only Sunday's and today's left in there.

I have CCleaner but it's not set up to clean at startup or anything like that and I don't have Spybot either which has also been suggested prior in this report.
I have found that version 3.5.1 does remember visited links correctly, but only if they are opened in the top of frame, e.g. in new tab or in new window. If link is opened in another frame of the same tab, it is not marked as visited after restart. Is it connected to Bug 477882 or should I create new request?
confirmed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1.4pre) Gecko/20090912 Shiretoko/3.5.4pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: visited links disappear when closing and reopening Firefox → frame-targeted visited links disappear when closing and reopening Firefox
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Test Case for Bug 477882: Visited links showed OK in 3.1.14 but show as unvisited after upgrade to 3.5.3 when Firefox is restarted.
* Visit http://sfbay.craigslist.org/forums/?forumID=21 , no need for an account.
* Select any posting in the bottom left frame. Note colour changes blue to purple.
* File, Exit Firefox.
* Restart Firefox 3.5.3 and return to http://sfbay.craigslist.org/forums/?forumID=21
* Note colour of previously visited link is blue again.
Also note previously visited links under version 3.1.14 correctly appear as purple.

I have uploaded this with screenshots here: 
http://sites.google.com/site/keysersozeorg/bug-477882
if the visits are considered EMBED they are not retained across restarts. The problem is just if they should be considered EMBED or better LINK transitions.
I propose to consider links from sites specified in a special list as LINK, but for other sites as EMBED. Such list as a list for "Block popup windows" or "Exceptions for addons" sites etc. In this case user can specify several sites to remember it's embedded links, but embedded links from all another sites don't litter the database.
backlists or whitelist are the last choice and for sure we would not like that solution. If i click on a link it should probably have a link transition even if it's opening in a frame.
the embed code:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/src/nsNavHistory.cpp#5172

5172     // If there is a referrer, we know you came from somewhere, either manually
5173     // or automatically. For toplevel windows, assume its manual and you want
5174     // to see this in history. For other things, it's some kind of embedded
5175     // navigation. This is true of images and other content the user doesn't
5176     // want to see in their history, but also of embedded frames that the user
5177     // navigated manually and probably DOES want to see in history.
5178     // Unfortunately, there isn't any easy way to distinguish these.
5179     //
5180     // Generally, it boils down to the problem of detecting whether a frame
5181     // content change is the result of a user action, which isn't well defined
5182     // since script could change a frame's source as a result of user request,
5183     // or just because it feels like loading a new ad. The "back" button will
5184     // undo either of these actions.
A 'whitelist' solution would be OK for me but many users of Craigslist are Lawyers or Politicians so may not be smart enough to understand where to go and select for a whitelist.

This bug is important for Craigslist users as the link colour change for visited posts in the forums is the only quick way of seeing new posts.  Others continue to experience the challenge:
http://sfbay.craigslist.org/forums/?act=Q&ID=135941805
http://sfbay.craigslist.org/forums/?act=Q&ID=136402878
I'm glad to see this being taken seriously.  Is there an explanation as to why some FF3.0 users have the experience I mentioned here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=511905#c4 and first reported in Aug. 2008?

My craigslist title frame links opened from the frame and into the other frame (normal click) don't revert on closing the browser, but they do revert after 24+hrs AND the next browser cycle.  They don't appear in the History but the color change is retained except if the forum main page which IS in the History is removed from History OR 24+hrs etc.   If I open a title in a New Window, that sticks and does show in my History.  They are in some kind of hidden History and apparently subordinated to the craigslist forum link in the History.  So this seems related but not identical to the FF3.5 bug which is the primary focus here.  In Aug 2008 when I upgraded to FF3.0 I also reported a History display date anomaly which I thought might have been related.
If somebody doesn't want to enable persistent storing of embed links in the official build, please point a place in the sources where i can enable it in my custom build from the sources. Of cource, if anybody know that place :)
I've changed
#define EXCLUDED_VISIT_TYPES "0, 4, 7"
to
#define EXCLUDED_VISIT_TYPES "0, 7"
in toolkit/components/places/src/nsPlacesTriggers.h, but it doesn't help.

This "feature" really foils to use some frame-based sites, it's unable to keep in my head names of every topic which i've read and which i haven't read.
The same bug shows up at http://www.wer-weiss-was.de , which is a German knowledge exchange forum. Pretty annoying, especially when you act as board moderator and cannot distinguish between read and unread articles. The bug seems to appear with FF3.5 on Windows, Linux and Mac systems. Definitely on my system with:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5

as well as with all previous versions of FF3.5
I am also participating in a frame based internet forum.
In my opinion it is really uncalled for to force current firefox users into utilising MS Internet Explorer if they want to keep taking part in their present forum.

My System:
Windows XP Prof
Version 2002
Service Pack 3
Firefox 3.5.5
Marco: what platform callback changes the color of the visited links? Perhaps that is where we can fix this issue? The basic point is that we have the data (in transient form) so we should be able to update the history on window close or tab blur or on idle.
(In reply to comment #32)
> Marco: what platform callback changes the color of the visited links? Perhaps
> that is where we can fix this issue? The basic point is that we have the data
> (in transient form) so we should be able to update the history on window close
> or tab blur or on idle.

We have the data, but since we consider it an embed visit it is session-persistent. the problem is that we should not consider a click on a link an embed visit even if this is a visit between frames. So the issue is not really in Places rather in docshell (or at least in the data we pass to history).
We're runnning the forum at http://www.wer-weiss-was.de and we can confirm this bug. FF 3.5 does not remember visited links in frames. It's very annoying for a large number of our users because we have a huge number of new articles every day. We would be glad if this would be fixed.
Summary: frame-targeted visited links disappear when closing and reopening Firefox → frame-targeted visited links disappear when closing and reopening Firefox (should not be considered EMBED visits)
So, the docshell calls globalHistory::addURI passing !isFrame() as aTopLevel, and we use aTopLevel to evaluate embed status. But actually we need to know if the visit has been caused by a click on a link or is just due to being in a frame. The docshell should know if this is a valid click or not, and addURI should probably be able to receive more optional params (more informations) about the uri that is being added, to take better decisions.
You know, I've been waiting patiently for awhile for Mozilla to fix this bug. I'm done. IE8 doesn't have this problem. Screw FF! Stupid open-source BS is what the problem is. There is NO devoted resource for supporting the application. It will only get attention when some schmuck is done playing their mmorpg or something. None of the developers are dedicated to fixing anything! I'm leaving FF...maybe someday the developers will find a way to fix this VERY annoying bug. I'm not waiting around for it to happen.

C-YA!
(In reply to comment #35)

Ok, we created a small demo: http://www.wer-weiss-was.de/content/ffFramesDemo/frameset.html

Steps to reproduce this: 
open the demo frameset, 
click one or both links in the navigation frame (visited links should turn from blue to red)
close firefox (all instances)
restart firefox
open the demo frameset (the already visited links are blue)
Here's a live example to test in addition to the previous one posted by Thomas. well:
http://www.quiltuniversity.com/StudentLounge/student_lounge.html

Same steps. Links change back to un-visited when exiting and restarting FF. I would love to see this bug fixed!! When I teach a class it uses these frames and it's impossible to tell which posts I have visited.

Patti
I hope I'm not being obnoxious or whatever - but I'm honestly willing to pay $300 to the person who fixes this. It is important to my on-line community. -- Jay
I am very very angra, that the history doesn't run.

I think abot to remove Firefox from my System. Also with Frames I have Problems.

A lot of Websites make Problems an it is no fun anymore to surf with FF

Cirwalda
Trying to see what file/s contain the history and bookmarks

Is it places.sqlite for history and places.sqlite-journal for bookmarks? or?
This is not a solution to the web forum/frames problem, but I have found a temporary workaround...at least for me. I discovered this by accident. I noticed when returning to my online forum that there was one post that kept its visited link status. After thinking about it a little, I remembered that I had opened that particular post on a new tab in FF. So now when I post a reply to a student, I open the original post on a new tab. There are also options for frames on the right-click context menu that work in the same manner, i.e. it will keep your visited links. If you use the "This frame" option to open the right-hand frame in a new window you can work frameless and your links will stick around.

At this point, I am stubborn enough to refuse going back to IE. Besides, I've not updated past IE 6 on this machine and I could not live without the tabs!

Patti
Thanks Patti. I'm glad you found a workaround that works for you but that particular method would be too time consuming in my situation. As the administrator of our site I have to read a good many of the posts and with 1,700 members we average over 350 posts each day.

What I ended up doing is going back to an earlier version of FF (Firefox 3.0.17) where this bug is not present. I realize there is some risk in doing that but so far everything is fine and my visited links remain as they should. But I can no longer recommend FF to our members.

The current version of IE has tabs and visited links retain their visited status in the frames format, so you may want to take another look at IE.

Unless something is happening behind the scenes it appears no one who is in a position to work on this bug is interested in doing so.

 -- Jay
please, be patient, we have a long way to make everybody happy.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Well - that's encouraging that you made that post. It implies the problem is being looked at.

I for one would be very interested in hearing how the general work flow operates in the development of FF. -- J
(In reply to comment #47)
> Well - that's encouraging that you made that post. It implies the problem is
> being looked at.

I already posted before, all problems are being looked at, don't worry, just that days have 24 hours, we would prefer 48 :)

> I for one would be very interested in hearing how the general work flow
> operates in the development of FF. -- J

We do our best to make the Web better, that's it. Well no, there is also a lot more stuff about work flow, but this is not the place to discuss about it, newgroups are a better place.

I have a locally working patch for this, could be tricky to sneak it into 3.6.x since i have to change 2 interfaces, but i could probably add a temporary interface, so looks like doable for a next stability release. I tried the testcases above and they are working.

I'm handling the work in bug 542941, since this one is just too long. please don't comment in that bug, i need it clean, keep conversation here, i'll probably post a test build for you to try once possible.
Thanks.
Depends on: 542941
I can see in 542941 that you have to carefully document everything you do. Good way to prevent spaghetti code.

Thanks much Marco.  -- J
Depends on: 549340
Whiteboard: [frontend hook for bug 542941]
I received an email today indicating this bug is now fixed.
That's great!! I'm wondering when it will be available to download?
Thanks,  -- J
(In reply to comment #50)
> I received an email today indicating this bug is now fixed.
> That's great!! I'm wondering when it will be available to download?
> Thanks,  -- J

I added support in the backend, i still have to add UI part for it (that i'll do in this bug).
Unfortunatly the change ended up being larger than expected, so i'm not anymore confident we can bring it to Firefox 3.6.x since it won't satisfy stability and security rules we have for backporting.
But once this bug (frontend) will be fixed you'll be able to use a Minefield nightly or alpha.
Thank you Marco - although I'm afraid I don't know what is meant by 
"...you'll be able to use a Minefield nightly or alpha."
I have been using Firefox since v. 2, and I never saw this bug until v. 3.5; it continues to the present v. 3.6.3 on Windows XP and 7, I suspect also on Linux. The bug breaks the Contents frame in my site: open http://www.biblekjv.com/kjv-fm/startkjv.htm and click on links in the Contents frame at the left. Opera has precisely the same problem. Chrome does not, but has a worse problem: it does not support cookies for local offline files, and the Bible on my site requires cookies for the Contents and is available as a ZIP file for download. I read somewhere that Firefox treats frames (and iframes) as hidden files, giving me the impression that supressing the retention of the visited color for links in frames is a deliberate decision, not an unintentional bug. But this bug 47882 gives me hope that it is indeed a bug and will be fixed.
I have been using Firefox since v. 2, and I never saw this bug until v. 3.5; it continues to the present v. 3.6.3 on Windows XP and 7, I suspect also on Linux. The bug breaks the Contents frame in my site: open http://www.biblekjv.com/kjv-fm/startkjv.htm and click on links in the Contents frame at the left. Opera has precisely the same problem. Chrome does not, but has a worse problem: it does not support cookies for local offline files, and the Bible on my site requires cookies for the Contents and is available as a ZIP file for download. I read somewhere that Firefox treats frames (and iframes) as hidden files, giving me the impression that supressing the retention of the visited color for links in frames is a deliberate decision, not an unintentional bug. But this bug 47882 gives me hope that it is indeed a bug and will be fixed. I voted for it.
it will be fixed, we are waiting for a depending bug to proceed.
(In reply to comment #55)
> it will be fixed, we are waiting for a depending bug to proceed.


Marco,
Can you PLEASE explain what this "depending bug" thing means? Maybe you're being intentionally vague??...but it's been over a year now since I reported this bug, and I am getting anxious to see this resolved. Dare we hope for a fix with the next Firefox 3.6+ update?

Patti
(In reply to comment #56)
> Can you PLEASE explain what this "depending bug" thing means? Maybe you're
> being intentionally vague??...but it's been over a year now since I reported
> this bug, and I am getting anxious to see this resolved. Dare we hope for a fix
> with the next Firefox 3.6+ update?

No, we are never 'intentionally vague', we believe in openness. Bug 549340 should be fixed before i can fix this, it is waiting for review, i have no guess how much time that could take, i hope it will be soon.
About whether this could be in 3.6.x, i can't tell off-hand, it was a more complex fix than expected, thus it probably does not respect expected security and stability rules we have for current releases. Hard to tell till it's fixed.
It will definately be fixed in next version (could be 3.7 or 4.0, we have not finalized plans for version numbering there).
Asking final blocking, we have this regression from Firefox 3.5 and framed websites navigations is affected (history is lost).
blocking2.0: --- → ?
Keywords: dataloss
Whiteboard: [frontend hook for bug 542941] → [frontend hook for bug 542941][waiting for review in bug 549340]
blocking2.0: ? → final+
What is happening on this?  I just upgraded to 3.6.10 on a Mac and suddenly my previously viewed craigslist forum threads revert to unread when I close the browser.  The OLD threads from before I upgraded remain marked as 'read' so far .... except I suspect that as they have for TWO YEARS NOW SINCE I FIRST REPORTED THIS PROBLEM (and others before me) with 3.0 on a PC, after 24hrs plus one browser close even the old links will continue to vanish.

PLEASE FIX THIS OR LOSE MORE INTEREST IN FIREFOX.  I will no longer recommend FF until this is fixed (both parts).
Welcome to the club.

It was suggested 10 months ago that I be patient.

I'm still waiting - and still using version 3.0.17 where this bug is not present.
Whiteboard: [frontend hook for bug 542941][waiting for review in bug 549340] → [frontend hook for bug 542941][waiting for review in bug 549340 or will need a new patch]
Attached patch patch v1.0 (obsolete) — — Splinter Review 
built on top of the patch in bug 549340, includes test.
Attachment #486325 - Flags: review?(dietrich)
Flags: in-testsuite?
Whiteboard: [frontend hook for bug 542941][waiting for review in bug 549340 or will need a new patch] → [frontend hook for bug 542941][requires patch in bug 549340]
Whiteboard: [frontend hook for bug 542941][requires patch in bug 549340] → [requires patch in bug 549340][needs review]
actually, I have to add a try catch around the call, since createFixedURI (that is internally called by markPageAs... can throw for some bad uri).
Attached patch patch v1.1 — — Splinter Review 
added the try/catch.
Attachment #486325 - Attachment is obsolete: true
Attachment #486621 - Flags: review?(dietrich)
Attachment #486325 - Flags: review?(dietrich)
Attachment #486621 - Flags: review?(dietrich) → review+
Whiteboard: [requires patch in bug 549340][needs review] → [requires patch in bug 549340]
Whiteboard: [requires patch in bug 549340] → [requires patch in bug 549340][can land]
http://hg.mozilla.org/mozilla-central/rev/aef0b80d0535
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Whiteboard: [requires patch in bug 549340][can land] → [requires patch in bug 549340]
Target Milestone: --- → Firefox 4.0b8
Blocks: FF2SM
Blocks: 610736
No longer blocks: FF2SM
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: