Fails to scroll to top of page when loading URL w/ empty reference fragment Observed in the latest Safari3 as well as WebKit r24803. IE and FF do not have this bug. If you have a page w/ an anchor like <a href="#">, other browsers scroll to the top of the page, but WebKit does not. This causes problems on pages like this: http://wiki.gamer.com.tw/wiki.php?n=PSU%3A%E5%A4%A2%E5%B9%BB%E4%B9%8B%E6%98%9F If you scroll down to the bottom of the page, there is an arrow button that is intended to take you back to the top of the page. It is implemented using <a href="#">. Simple test case coming up...
Created attachment 15813 [details] reduced test case
Expected behavior works in Firefox 2.0.0.6. Does not work in Opera 9.21.
With <a href="#">, WebKit interprets the fragment identifier as a null string. And then WebKit searches the anchor node in two steps: (in bool FrameLoader::gotoAnchor(const String& name)) 1) searches any node whose id attribute is the same as the fragment identifier. If the fragment identifier is a null string, it returns directly. 2) searches in a set of <a> elements that have name attributes, using HTMLCollection::namedItem(). It should be noted that namedItem() first searches for an object with a matching id attribute. If a match is not found, the method then searches for an object with a matching name attribute. Consider the following node: <a name="anyname">...</a> Its id attribute is not specified (returned as a null string when querying it). If we are searching with a null fragment identifier, it will match this node, no matter what its name attribute is. As a result, clicking the "Goto Top" link in the page below will bring you to the "youwillgethere" anchor but not the top of the page. ======================================= ... <a href="#">Goto Top</a> ... ... <a name="youwillgethere">Oops!</a> ... ======================================= I will upload a patch soon.
As I tested today Webkit r30939 scrolls to the top. So the reported issue is absent in this build. But there is similar issue reported in bug 17714.
Yes, I tested with the newest version of the code and the problem disappears. BTW, in case like this, shall I still submit a patch with only the test case and expeced result?
(In reply to comment #5) > Yes, I tested with the newest version of the code and the problem disappears. > > BTW, in case like this, shall I still submit a patch with only the test case > and expeced result? > I think new layout tests are always welcome :)
I have uploaded a patch for bug 17714 and it has been reviewed. This two bugs are related, please refer to my comments in bug 17714 for details. And the test case for bug 17714 covers the situation described in this bug.
(In reply to comment #7) > I have uploaded a patch for bug 17714 and it has been reviewed. This two bugs > are related, please refer to my comments in bug 17714 for details. And the test > case for bug 17714 covers the situation described in this bug. > So I mark the bug as FIXED since original reported bug is not visible any more and the test case for it is available in related bug 17714.