Community
Participate
Working Groups
Clicking duplicate topic headings jumps to the first instance. When a topic is reused, clicking the second instance of the topic jumps focus to the first instance. Steps to reproduce: 1) Download TPTP 4.5 M5 all-in-one package (http://www.eclipse.org/tptp/home/downloads/?buildId=TPTP-4.5.0M5-200802170400). 2) Open the Help and select Testing applications >> Testing with JUnit >> Generating test reports. 3) Note focus jumps to Testing applications >> Testing performance >> Generating test reports.
I have noted something like this as well. I have multiple help plugins where each has its own overview and release notes pages which have links in the various pages of the Welcome screen. When the user clicks on a link the correct page appears in the help pane but the wrong TOC entry is highlighted. Out help plugins are grouped in the TOC using a common top-level entry that looks like this: Product Help - Manual A -- Overview - Manual B -- Overview - Manual C -- Overview If I throw out the top-level entry (Product Help) so that the help plugins appear in the TOC list ungrouped, then the links and the TOC highlighted are correct.
I have been able to reproduce this, it happens when a topic occurs more than once with the same href and the same title and when the "Link with contents" button is on. Will fix for 3.4.
Created attachment 91463 [details] Patch
Fixed in HEAD. Frank, can you see if this fixes your problem also? If not can you file a separate bug?
Tried just copying the nightly build files into the product and had no luck, but the product is still based on the 3.3 release. Will be converting it to use 3.4 sometime soon. Will check again at that time and let you know.
Chris, this is still a problem in Eclipse 3.4 M6 (I20080305-1100).
The fix may have been too late for that particular I-build. Can you try using N20080310-0100 or wait for this weeks I-build.
Sorry Chris, the Eclipse 3.4 M6 N20080310-0100 build contains the fix.
Verified in the Eclipse 3.4 M6 N20080310-0100 build.
Chris, we are seeing a similar behavior with the I20080330-1350 driver. Although the original problem is resolved, clicking on a link in a HTML file that references a shared file, the topic jumps focus to the first instance.
Can you elaborate on the previous comment? Do both topics have the same href? If the same href appears in more than one table of contents or more than once in a single table of contents then the show in table of contents will pick the first one that it finds. Does this describe the problem you are seeing?
(In reply to comment #11) > Can you elaborate on the previous comment? Do both topics have the same href? > If the same href appears in more than one table of contents or more than once > in a single table of contents then the show in table of contents will pick the > first one that it finds. Does this describe the problem you are seeing? > Sorry Chris for the late reply. We are using relative URLs in the hrefs. I believe what you described is the problem we are seeing. Can you confirm using the following example: http://help.eclipse.org/help33/topic/org.eclipse.hyades.test.doc.user/tasks/t_openinglogs.html >> Analyzing test results
When following a hyperlink from one page to another the algorithm for highlighting in the toc does indeed look through all the books for the first match for that href. It is not always going to be possible to determine the right topic to select but there are some cases that could be handled. I see three distinct cases 1. Following a hyperlink from topic A to topic B which exists in the same book and in another book, only one instance of B exists in that book. This is the case that we would be easiest to handle. 2. Following a hyperlink from topic A to topic B which exists in the same book, more than one instance of B exists in that book. This is much harder, we can pick the right book but how do we decide which of the topics in that book is the correct one? I'm guessing that this is the most common case. 3. Following a hyperlink from topic A to topic B which only exists in other books. In this case there is no way to know which book was intended. I think this case might be pretty rare. Paul, am I correct in thinking that case 2 is the one you are interested in?
(In reply to comment #13) > When following a hyperlink from one page to another the algorithm for > highlighting in the toc does indeed look through all the books for the first > match for that href. It is not always going to be possible to determine the > right topic to select but there are some cases that could be handled. > > I see three distinct cases > > 1. Following a hyperlink from topic A to topic B which exists in the same book > and in another book, only one instance of B exists in that book. This is the > case that we would be easiest to handle. > 2. Following a hyperlink from topic A to topic B which exists in the same book, > more than one instance of B exists in that book. This is much harder, we can > pick the right book but how do we decide which of the topics in that book is > the correct one? I'm guessing that this is the most common case. > 3. Following a hyperlink from topic A to topic B which only exists in other > books. In this case there is no way to know which book was intended. I think > this case might be pretty rare. > > Paul, am I correct in thinking that case 2 is the one you are interested in? > Hi Chris. Yes, you are correct that use case #2 applies to us. Since we are always linking to a topic that is within the current branch of the TOC, could you walk up the branch to find the first instance?
It may be possible to handle just that one case where the link target is an ancestor of the page containing the link. I need to think this through to see what the implications are, I don't want to add overhead to the show in toc mechanism if I can avoid it.
There is a way which you can disambiguate multiple identical pages in a TOC by using anchors which allows you full control of which page will get selected when you follow a link. I think that this is preferable to using a heuristic to try to guess which page is the correct one to highlight. This does not require the page in question to contain any anchors Consider this TOC <?xml version="1.0" encoding="UTF-8"?> <?NLS TYPE="org.eclipse.help.toc"?> <toc label="Anchored TOC" topic="html/toc.html"> <topic href="html/a.html#A1" label="Topic A1"> <topic href="html/b.html" label="Topic B11"> </topic> <topic href="html/a.html#A12" label="Topic A12"> <topic href="html/c.html" label="Topic C121"> </topic> </topic> <topic href="html/b.html" label="Topic B13"> <topic href="html/d.html" label="Topic D131"> </topic> </topic> <topic href="html/c.html" label="Topic C14"> </topic> <topic label="Nav Topic"> <topic href="html/e.html" label="Topic E151"> </topic> <topic href="html/a.html#A152" label="Topic A152"> </topic> </topic> </topic> <topic href="html/maintopic.html" label="Links"> </topic> </toc> And this html snippet: <a href="a.html#A1">link to A1</a> <a href="a.html#A12">link to A12</a> <a href="a.html#A152">link to A152</a> Page a.html appears 3 times in the same tree but each link clicked will cause a different node is highlighted. Can you try this to see if it works for you?
Removing the 3.4 milestone because the last problem as described in Comment #10 is not easy to fix and we are late in the cycle. The problem initially described has been fixed.
(In reply to comment #16) > There is a way which you can disambiguate multiple identical pages in a TOC by > using anchors which allows you full control of which page will get selected > when you follow a link. I think that this is preferable to using a heuristic to > try to guess which page is the correct one to highlight. This does not require > the page in question to contain any anchors > > Consider this TOC > > <?xml version="1.0" encoding="UTF-8"?> > <?NLS TYPE="org.eclipse.help.toc"?> > > <toc label="Anchored TOC" topic="html/toc.html"> > <topic href="html/a.html#A1" label="Topic A1"> > <topic href="html/b.html" label="Topic B11"> > </topic> > <topic href="html/a.html#A12" label="Topic A12"> > <topic href="html/c.html" label="Topic C121"> > </topic> > </topic> > <topic href="html/b.html" label="Topic B13"> > <topic href="html/d.html" label="Topic D131"> > </topic> > </topic> > <topic href="html/c.html" label="Topic C14"> > </topic> > <topic label="Nav Topic"> > <topic href="html/e.html" label="Topic E151"> > </topic> > <topic href="html/a.html#A152" label="Topic A152"> > </topic> > </topic> > </topic> > <topic href="html/maintopic.html" label="Links"> > </topic> > </toc> > > And this html snippet: > > <a href="a.html#A1">link to A1</a> > <a href="a.html#A12">link to A12</a> > <a href="a.html#A152">link to A152</a> > > Page a.html appears 3 times in the same tree but each link clicked will cause a > different node is highlighted. > > Can you try this to see if it works for you? > This solution does not pertain to our situation. We have several subtopics that link to a shared TOC. For example, the following link to http://dev.eclipse.org/viewcvs/index.cgi/test/org.eclipse.hyades.test.doc.user/toc/logviewer_toc.xml?root=TPTP_Project&view=log: http://dev.eclipse.org/viewcvs/index.cgi/test/org.eclipse.hyades.test.doc.user/toc/url_toc.xml?root=TPTP_Project&view=log http://dev.eclipse.org/viewcvs/index.cgi/test/org.eclipse.hyades.test.doc.user/toc/junit_toc.xml?root=TPTP_Project&view=log When the user selects the link in http://dev.eclipse.org/viewcvs/index.cgi/test/org.eclipse.hyades.test.doc.user/tasks/t_openinglogs.html?root=TPTP_Project&view=log to http://dev.eclipse.org/viewcvs/index.cgi/test/org.eclipse.hyades.test.doc.user/concepts/c_viewingtestresults.html?root=TPTP_Project&view=log for Help >> Help Contents >> Testing applications >> Testing with JUnit >> Analyzing test results >> Opening a test log, it opens Help >> Help Contents >> Testing applications >> Testing performance >> Analyzing test results >> Opening a test log.
Hi Paul and Chris, Do you think there should be a separate (new) bug entry for symptoms that occur when a shared toc file is used in multiple locations? I ask because I have been testing with another information set that uses <link toc=.. to a shared toc file in multiple locations, and I've discovered some additional symptoms involving search. The symptoms seem to only occur when a toc file is reused in multiple locations, and not specifically what this Bugzilla was originally about. Chris, the solution in comment #16 won't work when a toc.xml file is linked in multiple places, because the hrefs at those <link toc spots are identical in each spot. There's no facility for us in the hrefs to include unique anchors because it's the same toc.xml file that gets resolved at run-time in those locations. (I don't know--maybe there could be a new attribute on a <link toc element that specifies the context for that particular reuse instance, and on resolving the entries at runtime, that attribute is converted into an anchor in the hrefs.) If you want to keep the discussion in this bug, that's fine also. Best, Lee Anne
Using a shared toc file is used in multiple locations sounds dangerous, but as far as I know it is legal and yes there should be a separate bug for each problem.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
