download link is not styled :visited when clicked

VERIFIED FIXED in Firefox 3 beta3

Status

()

Firefox
Bookmarks & History
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: Peter6, Assigned: sdwilsh)

Tracking

({regression})

Trunk
Firefox 3 beta3
regression
Points:
---
Bug Flags:
blocking-firefox3 +
in-testsuite +
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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?
(Reporter)

Comment 1

10 years ago
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
(Assignee)

Comment 2

10 years ago
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.
(Assignee)

Comment 4

10 years ago
(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.
(Assignee)

Comment 6

10 years ago
Created attachment 294578 [details] [diff] [review]
v1.0

Stupid mistake.  Consolidated the code some too.
Assignee: nobody → comrade693+bmo
Status: NEW → ASSIGNED
Attachment #294578 - Flags: review?(mano)
(Assignee)

Updated

10 years ago
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-
(Assignee)

Comment 8

10 years ago
Created attachment 294583 [details] [diff] [review]
v1.1

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+
(Assignee)

Updated

10 years ago
Attachment #294583 - Flags: approval1.9?
(Assignee)

Updated

10 years ago
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+
(Assignee)

Comment 11

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review][needs approval]
Target Milestone: --- → Firefox 3 M11
Flags: in-litmus?
(Reporter)

Comment 12

10 years ago
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

Updated

10 years ago
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.