Closed Bug 30607 Opened 25 years ago Closed 23 years ago

named anchors don't become "visited"

Categories

(Core Graveyard :: History: Global, defect, P2)

x86
Windows 95
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.1alpha

People

(Reporter: alan-lists, Assigned: alecf)

References

()

Details

(Keywords: regression)

Any page that has target/anchors does not change colors Example go to http://users.ipa.net/~asj/moz3.html click on a number link then scroll back up and see the link did not change colors to a visited link. This used to work. This was seein on 3-4-00-8 build of win32 and on linux.
Changing component to Style System
Assignee: troy → pierre
Component: Layout → Style System
QA Contact: petersen → chrisd
Assigning to ekrock: 1/3 of Pierre's NEW bugs to help reduce his doomage factor
Assignee: pierre → ekrock
Reassigned back to me these bugs that shouldn't have left my list.
Assignee: ekrock → pierre
Related bugs: #12493 ([Webshell] Vlink attribute not supported) and #23210 (a:visited CSS property does not always work). Don't know if this is a dup of one or both of those.
Reassigned to waterson, like the other 2 bugs (12493 and 23210). I'm not sure this one is a duplicate. The testcase shows links to anchors that are on the same page.
Assignee: pierre → waterson
travis/radha: can one of you please verify that pages are added to global histor *before* page layout, but *after* a successful load has been initiated?
Status: NEW → ASSIGNED
Target Milestone: --- → M15
Yes pages are added after the load has successfully connected to the site, but before rendering occurs. This bug is due to simply global histories lack of forgiveness to the formatting of an URI as in if the trailing "/" is missing. Take a look at 12493.
Target Milestone: M15 → M16
travis: I set a breakpoint in nsGlobalHistory::AddPage(), and it's not tripped when clicking on an anchor reference. You and radha should look at the codepath that's take through the webshell and URI loader stuff and make sure it adds anchor refs to global history.
Assignee: waterson → travis
Status: ASSIGNED → NEW
Should be fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Using 9/14 builds on Windows, Mac and Linux with testcase provided, links are not changing colors to relect 'visited'. Reopening bug and nominating for nsbeta3. Is this a duplicate of another bug?
Status: RESOLVED → REOPENED
Keywords: nsbeta3
Resolution: FIXED → ---
reassigning to clayton
Assignee: travis → clayton
Status: REOPENED → NEW
Reassigning to pierre.
Assignee: clayton → pierre
Adding rtm+. Reassigning to History component.
Assignee: pierre → radha
Component: Style System → History
Keywords: rtm
QA Contact: chrisd → claudius
Whiteboard: [rtm+]
nav triage team: marking [RTM NEED INFO] to request a patch, then we can rtm+ it. P2
Keywords: regression
Priority: P3 → P2
Whiteboard: [rtm+] → [nsbeta3-][RTM NEED INFO]
Nav triage team: Regression; leaving at P2
cc'ing rjc and docshell folks. This is a global history problem. Maybe something changed in docshell that regressed this bug.
Reassigning to rjc,since this is a global history problem.
Assignee: radha → rjc
Haven't seen any activity on this bug since 10/5, doesn't sound like a "pull it off the wire" problem. Robert: if you've got a fix and a good case for why the PDT might approve this go ahead and attach the patch and remove the [rtm-]
Whiteboard: [nsbeta3-][RTM NEED INFO] → [nsbeta3-][rtm-]
Summary: Visited links in targets/anchors don't change colors → named anchors don't become "visited"
ok, this doesn't sound like a global history prob to me, but I'm taking it.. I have a feeling it's a docshell thing
Assignee: rjc → alecf
Target Milestone: M16 → mozilla1.0
nav triage team: not a beta stopper.
Keywords: nsbeta1-
Status: NEW → ASSIGNED
Keywords: nsbeta3, rtm
Whiteboard: [nsbeta3-][rtm-]
Component: History: Session → History: Global
nav triage team: Nice to have but not critical, pushing out to mozilla1.2
Target Milestone: mozilla1.0 → mozilla1.2
argh.. take two at reassigning history bugs to new owner
Assignee: alecf → blakeross
Status: ASSIGNED → NEW
Target Milestone: mozilla1.2 → ---
Target Milestone: --- → mozilla1.0
-->alec (Isn't this just the same problem about us not updating link color until leaving and returning to a page? It just doesn't work in the case that you scroll back up to see the link)
Assignee: blakeross → alecf
Target Milestone: mozilla1.0 → ---
the problem is that we need to store named anchors in history. (note - these are "anchors" not "links") I'm not sure where we process anchors, but that code has to add the full anchor URL to history.
actually, session history stores this kind of thing, so right around the time we're poking session history, we sould poke global history as well. cc'ing radha who might be able to give us some pointers. I don't plan to fix this anytime soon though, so if anyone wants to take this off my hands, feel free.
Target Milestone: --- → mozilla0.9.9
The place to look is nsDocShell::InternalLoad(). There is a segment there, that checks if the uri to be loaded is a target on the same page and calls ScrollToAnchor(). THere is code there already to add these targets to SH. So, Global history code should probably go there too.
We already do add the full uri to history. And if you reload, the links do change color. I thought this was just the same problem as opening a link in a new window doesn't color the link unless you reload.
no, this is ANCHORS, not links, as in http://foo.com/bar#anchor we're only adding this part to history: http://foo.com/bar
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.9 → mozilla1.1
alec: i know what they are...I see both "http://users.ipa.net/~asj/moz3.html#3" and "http://users.ipa.net/~asj/moz3.html" in my global history. what am I missing here?
blake: you're right. .. I don't know how this started working (I don't think radha or I changed anything) but it is now...
Status: ASSIGNED → RESOLVED
Closed: 25 years ago23 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.