If a page contains an internal anchor link, i.e. <a href="#foo">, and the user clicks on it, tableheader.js scrolls a bit backwards in order to make room for the header above the link target.

The code assumes that the anchor is a &;td> - I don't know why that is. If the anchor isn't a <td>, scrollLocation becomes negative, and the page is scrolled to the top, right after in has scrolled to the anchor further down the page. In other words, using anchors on a page using tableheader.js does not work.

Also, the adjustment code is inside the tracker() function that is invoked once per table on the page, but the adjustment is only done once using the height of the header of the first table on the page (after that prevAnchor == location.hash), even though the anchor is inside another table or not in a table at all.

This patch makes tracker() only adjust the scroll if the anchor is inside the current table, and when the header is displayed (it's not when the anchor is e.g. in the very last row).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch failed testing.

c960657’s picture

Status: Needs work » Needs review
FileSize
3.22 KB

Now it also adjusts for the admin toolbar height (anchor links outside tables are still hidden by the admin toolbar, but that is a separate issue).

Status: Needs review » Needs work

The last submitted patch failed testing.

c960657’s picture

Status: Needs work » Needs review
FileSize
1.21 KB
2.87 KB

Updated patch as well as a test case that may be useful when reviewing the patch. The test case adds a long list of anchor links to the bottom of admin/config/modules.

seutje’s picture

it seems to do the trick for me

cosmicdreams’s picture

#4: tableheader-3.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, tableheader-3.patch, failed testing.

casey’s picture

Something like this is also included in #787670: Clean up tableheader.js.

casey’s picture

liquidcms’s picture

i have this issue with Drupal 6 and the patch listed in #4 fixes the issue. I see it failed due to the patch not applying (i applied manually) so not sure if it did apply it would fail other tests - but works.

why is this bug not fixed in D6?

13rac1’s picture

Priority: Minor » Normal
FileSize
1.31 KB

Raising priority because this is more than a "minor cosmetic issue", especially when you've got a client who asks for named anchors then can't understand why they aren't working. ;)

I know this should be fixed in D7, then backported to D6. At this point I just need it working in D6, plus there seems to be competing solutions. Attached is a patch for the current (2010-Sep-06) 6.x-dev based on #4, perhaps it can help someone else while this gets sorted out.

aidanlis’s picture

Wow - talk about being bitten in the arse by this. However, the patch provided has already been rolled into core?
http://drupalcode.org/project/drupal.git/blob/refs/heads/6.x:/misc/table...

nod_’s picture

Version: 7.x-dev » 8.x-dev
casey’s picture

Status: Needs work » Closed (duplicate)