539091 - Selecting Link with a URI Fragment Does Not Reposition Page

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091206 SeaMonkey/2.0.1
Build Identifier: 

At the beginning of the cited URI, there is a table of contents of articles.  Each entry in the table of contents is a link to an article further down in the page.  This is accomplished via a URI fragment as defined in RFC 3986, Sections 3 and 3.5.  The target location is identified by an <a> anchor with a "name" attribute whose value is the same as the fragment.  

Sometimes, selecting a link with a URI fragment targeting a location within the same page does not work.  I have observed this problem not only with the cited Web page but also with other pages.  Reloading the affected Web page (with or without clearing my cache) does not correct the problem once it occurs.  Using tabbed browsing to view other Web pages does seem to correct the problem.  


Reproducible: Sometimes




The cited Web page changes every Monday, Wednesday, and Friday if those days are normal business days in New York.  However, the structure of the page remains the same with a table of contents using URI fragments and articles that are targets of those fragments.  

Today, I viewed portions of the affected page.  The table of contents contained the following:  
   <li><a href="#445020">Making TV Social, Virtually</a></li>
   <li><a href="#444999">Queue ICPC Challenge</a></li>
   <li><a href="#444963">Stimulus Funding to Help Search Engines Learn on the Job</a></li>

The article "Queue ICPC Challenge" began with the following (including part of the previous article):  
   <div style="margin-top: 5px;">

   <a href="http://www.technologyreview.com/web/24340/?a=f" target="_blank">View Full Article</a> | 

   <a href="#top">Return to Headlines</a>
   </div>

   <br> <br> 

   <a name="444999"></a>
   <b>Queue ICPC Challenge</b><br> 
   <i> ACM (01/11/10)</i>

   <br><br> ACM Queue reader

Note that the value of the "name" attribute in the anchor just above the article title is "444999", which is the same as the fragment name in the table of contents.  

Among other Web pages where I have observed this problem is my own <http://www.rossde.com/>.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I could really use reliable steps to reproduce here.....

Comment 2

[David E. Ross]

If I knew how to consistently create the problem, I would definitely provide that information here.  Unfortunately, I don't know I have a problem until after the page has rendered and I try a link to another location on the same page.  By the time I then see the problem, I don't clearly remember everything I did before.  

Nevertheless, I will keep on trying to capture what I did.

Comment 3

[David E. Ross]

I am still unable to determine what steps lead to this problem.  From a report at the mozilla.support.seamonkey newsgroup, I now see that others are encountering this same problem.  

In the meantime, I have noticed the following:  

When I saw the problem recently, I cleared the error log in the Error Console.  I then continued to see the problem, but no new entries were made in the error log.  Thus, any logged error causing this problem must occur before the problem is seen.  

When I select a link to another location within the same page, the link changes color although the page does not move to the selected location.  Thus, the link is recognized and an entry is made in the browsing history.  

If I open a new tab but do nothing in that tab, the problem disappears in the old tab.  The next time I see this problem, I will open a new tab and close that tab before trying the link.

Comment 4

[David E. Ross]

Attachment: Error Console

I captured an image of my Error Console on the last occurrence of this problem.  The image is attached.  Although some time and much activity had elapsed since the last time I cleared the Error Console, the entire contents fit in the window without any need to scroll.  I don't know how to interpret the contents, so I don't know if anything is there that might help diagnose this problem.  

I confirmed that merely opening and then closing a new tab -- without any browsing activity in that new tab -- eliminates the problem.

Comment 5

[David E. Ross]

I have not seen this problem in a long time.  I do not know whether it was resolved by changes to the Gecko Core or by my acquisition of a broadband Internet connection.

Comment 6

[Joshua Mitchell (Inactive)]

Issue is resolved - clearing old keywords - qa-wanted clean-up