Closed Bug 409836 Opened 17 years ago Closed 17 years ago

download link is not styled :visited when clicked

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3 beta3

People

(Reporter: Peter6, Assigned: sdwilsh)

References

()

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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
Flags: blocking-firefox3?
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
Summary: download link is not styled :visited when klicked → download link is not styled :visited when clicked
Component: General → Places
QA Contact: general → places
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.
Attached patch v1.0 (obsolete) — Splinter Review
Stupid mistake.  Consolidated the code some too.
Assignee: nobody → comrade693+bmo
Status: NEW → ASSIGNED
Attachment #294578 - Flags: review?(mano)
Whiteboard: [has patch][needs review Mano]
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.
Attachment #294578 - Flags: review?(mano) → review-
Attached patch v1.1Splinter Review
addresses review comments
Attachment #294578 - Attachment is obsolete: true
Attachment #294583 - Flags: review?(mano)
Comment on attachment 294583 [details] [diff] [review]
v1.1

r=mano
Attachment #294583 - Flags: review?(mano) → review+
Attachment #294583 - Flags: approval1.9?
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: [has patch][needs review Mano] → [has patch][has review][needs approval]
Version: unspecified → Trunk
Comment on attachment 294583 [details] [diff] [review]
v1.1

a=beltzner for 1.9
Attachment #294583 - Flags: approval1.9? → approval1.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
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review][needs approval]
Target Milestone: --- → Firefox 3 M11
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007122617 Minefield/3.0b3pre ID:2007122617

VERIFIED
Status: RESOLVED → VERIFIED
Flags: blocking-firefox3? → blocking-firefox3+
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!
Flags: in-testsuite+
Flags: in-litmus?
Flags: in-litmus-
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: