Closed Bug 409662 Opened 12 years ago Closed 7 years ago
_TYPE _FULL _VISIT
support RESULT_TYPE_FULL_VISIT http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsNavHistory.cpp#4799 I was hoping to use this to test bug #409301, but it is not implemented. Beyond wanting it for tests, I am sure there are interesting an extension author could do if they could get at the full visit (as it would include the referring visit id, the visit id and the transition type). It appears this we have some test code partially written as well, see http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/tests/unit/test_history.js#98
of course, I could have write SQL directly to test 409301 instead of doing what I did (which was to use a history observer.) perhaps at the very least, if we don't think we are going to have this for fx 3, we should remove it from the the interface and make sure the docs are correct?
I got bitten by this a few days ago, it would help if FULL_VISITs were not in the idl at all or returned an error of some sort! (I spent a while trying to figure out why my queries were coming back empty). I actually do want to record the transition type, so that I can sync it and get good frecency calculations on all machines. Since I can't get it right now I'm creating synced items as "typed", but since they're all the same that skews the scores.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
No, if we need more information on the visit we should just add it to the visit node, provided we don't even kill visit nodes, in such a case would just be provided in uri nodes.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.