Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007122118 Minefield/3.0b3pre ID:2007122118 repro: open FF open url click on a link result: dm pops up the link on the page is not styled :visited expected: the link on the page should be styled :visited. it's only shown when you refresh the page
regressionwindow: works in 20071221_1532_firefox-3.0b3pre.en-US.win32 fails in 20071221_1836_firefox-3.0b3pre.en-US.win32 http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=1198285740&maxdate=1198290959&cvsroot=%2Fcvsroot
Seriously? We have a test that actually tests this exact behavior... http://mxr.mozilla.org/seamonkey/source/toolkit/components/places/tests/unit/test_download_history.js
Just to independantly verify Peter's bug. 1. New profile, start firefox 2. Visit http://hourly-archive.localgho.st/ 3. Right click on a download file, and Save As 4. Save file Expected: - After download starts, the link I right-clicked on should have changed colour Actual: - Link does not change colour. Works: 20071221_1709_firefox-3.0b3pre.en-US.win32 Broken: 20071221_1836_firefox-3.0b3pre.en-US.win32 FWIW, if I use 20071221_1836_firefox-3.0b3pre.en-US.win32 and right click on a load of these download links, none of them get coloured as if they have been visited. But if I close the browser down and start it back up, the links then get coloured as expected.
(In reply to comment #3) Right clicking is a different code path than just normally clicking on a download (I'm assuming you are using a right handed mouse). If it doesn't get highlighted with steps in comment 0, it's the same bug. If it does get highlighted upon restart, your bug is a different bug.
The STR in comment 0 also show that the link remains uncoloured for me. I've noticed too that you don't have to restart the whole browser to get the clicked download links the highlighted colour; a simple refresh of the page will colour the links accordingly.
Created attachment 294578 [details] [diff] [review] v1.0 Stupid mistake. Consolidated the code some too.
Comment on attachment 294578 [details] [diff] [review] v1.0 It would be nice to pass in the correct session id, but i don't think we've that handy, so just pass 0.
Created attachment 294583 [details] [diff] [review] v1.1 addresses review comments
Comment on attachment 294583 [details] [diff] [review] v1.1 r=mano
Comment on attachment 294583 [details] [diff] [review] v1.1 a=beltzner for 1.9
Checking in toolkit/components/places/src/nsNavHistory.cpp; new revision: 1.220; previous revision: 1.219 Checking in toolkit/components/places/tests/unit/test_download_history.js; new revision: 1.2; previous revision: 1.1
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007122617 Minefield/3.0b3pre ID:2007122617 VERIFIED
Can someone tell me why this is part of the Places component?
Because it requires changes to our history code to save download links in browsing history.
stephend saw that an automated test case was already created for this bug. I'm going to flag it as in-testsuite+ and in-litmus-. Thanks everyone!
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