The same does not happen in Timeless: https://no.wikipedia.org/wiki/Wikipedia:Torget/Arkiv/2024/august?useskin=timeless#c-Znuddel-20240731074400-Årstall

I believe scroll-padding-top is what makes this work, but in Vector-2022 the sticky header seemingly isn't ready when the DT code runs. If you focus the address bar and press enter you'll notice it works the second time.

I also can't reproduce it locally, so feels like a race condition.

Seems the issue could be the Special:GoToComment link? If you use the link on the timestamp of the comment [https://no.wikipedia.org/wiki/Wikipedia:Torget/Arkiv/2024/august#c-Znuddel-20240731074400-%C3%85rstall], that takes you to the exact spot you're wanting. I wonder why Special:GoToComment doesn't target that same spot, seems it targets something different because I'm finding it impossible to generate or go to my example below's Special:GoToComment link on nowiki??? It's so unintuitive... There's no instructions, it's not the right click Copy link address one, it's not the click the timestamp and it copies to clickboard one....

For example to link to Wikipedia-diskusjon:Portal#Kommentarer til oversikten i forrige seksjon:

• from comment href works as expected: https://no.wikipedia.org/wiki/Wikipedia-diskusjon:Portal#c-Wkee4ager-2022-01-17T10:00:00.000Z-Kommentarer_til_oversikten_i_forrige_seksjon
  • https://no.wikipedia.org/wiki/Special:GoToComment/c-Wkee4ager-20220117100000-Kommentarer_til_oversikten_i_forrige_seksjon
  • https://no.wikipedia.org/wiki/Wikipedia-diskusjon:Portal#c-Wkee4ager-2022-01-17T10:00:00.000Z-Kommentarer_til_oversikten_i_forrige_seksjon

In T406114#11232965, @Waddie96 wrote:

Seems the issue could be the Special:GoToComment link? If you use the link on the timestamp of the comment [https://no.wikipedia.org/wiki/Wikipedia:Torget/Arkiv/2024/august#c-Znuddel-20240731074400-%C3%85rstall], that takes you to the exact spot you're wanting.

No, for me it happens with the fragment (#) URL too, but only when I load the page fresh with that link, like @Esanders says (i.e.: copy the URL with the fragment link and open it in a new tab). When the page (and thus the sticky header) has already loaded, it works as expected.

It's somewhat viewer-dependent. For me (Chrome on macOS) it looks just right:

It happens in Chrome on Ubuntu too for me (I normally use Firefox), FWIW.

I found a hook in Vector that might be useful here, but haven't found a logical place in the DiscussionTools code to place it. The hook is marked as internal though, which might be an issue.

mw.hook( 'vector.page_title_scroll' ).add( ( a ) => {
	if ( a.context === 'scrolled-below-page-title' ) {
		// Do scrolling here somehow
	}
} );

DT doesn't actually do scrolling for the hash-linked comments, it's done natively. We could do a delayed non-native scroll after the vector hook runs to fixup the problem.

I just noticed that the same happens in Wikidata too when I visit something like https://www.wikidata.org/wiki/Q42#P26 . So this should be fixed in Vector-2022 and not DiscussionTools.

In T406114#11234813, @jhsoby wrote:

I just noticed that the same happens in Wikidata too when I visit something like https://www.wikidata.org/wiki/Q42#P26 . So this should be fixed in Vector-2022 and not DiscussionTools.

Oh yes does that to me too Chrome on macOS +- 2-3em below, and Safari is erratic but mostly faaar off.

Change #1192980 had a related patch set uploaded (by Jon Harald Søby; author: Jon Harald Søby):

[mediawiki/skins/Vector@master] Make link targets obscured by sticky header scroll into view

https://gerrit.wikimedia.org/r/1192980

I've done some experimenting, and I think I know what's happening (@Esanders already mentioned it: race condition). There is LESS code in https://gerrit.wikimedia.org/g/mediawiki/skins/Vector/+/f2e2939816d6d150240b46d4307294c4ee109abb/resources/skins.vector.js/stickyHeader.less#123 that is intended to avoid this problem. However, it seems to me that that LESS code takes a few milliseconds to actually be loaded into the browser, which is enough time for the browser to already have scrolled to the element indicated in the URL fragment. I tested this by adding --background-color-base: red; in that LESS file just below the scroll-padding-top declaration, and there was a teeny tiny delay before that background color took effect, meaning the same happens to the scroll-padding-top.

So the solution I came up with (the patch just above) was to add a check in stickyHeader.js's initStickyHeader() function, that checks whether the top of the target element is (or would be) obscured by the sticky header. If yes, run .scrollIntoView() on the element, and the now-loaded stickyHeader.less file makes it scroll with the correct scroll padding.

I'm running into the same thing in Firefox, with any logged-in account using the default Vector 22 skin. (It notable does not affect legacy Vector, or logged-out Vector 22; as neither of those have a sticky header by default.)

The Mobile domain sunsetting talk page on mediawiki.org has a good mix of heading lengths and comment lengths, in case its content-dependent around line-wrapping or something.

Example: Opening singe-line comment, under a single-line heading, short page title, in short and wide viewport. In this the entire comment is obscured.

Actual
Expected

Example: Longer reply, under a longer opening comment, under a mulit-line heading, in a taller viewport.

Actual	Expected

@Krinkle Could we allow the skin to specify a default scroll-padding-top and then render that really early (e.g. an inline <style> tag in the <head>)?

In T406114#11246826, @Esanders wrote:

@Krinkle Could we allow the skin to specify a default scroll-padding-top and then render that really early (e.g. an inline <style> tag in the <head>)?

According to https://www.mediawiki.org/wiki/Manual:How_to_make_a_MediaWiki_skin#Preparation , skins are "restricted from editing anything inside the HEAD", so I'm not sure how feasible that is? Would adding a non-zero scroll-padding-top that early affect scrolling in contexts where the sticky header is not shown too? I'm not opposed to that (I like there to be a bit of room above the element I'm scrolling to), just asking. :-)

btw, anchors were not mentioned yet, subject of T407884: Vector 2022's sticky header toolbar overlaps beginning of a content linked with an achor (~duplicate issue)

In T406114#11284782, @jhsoby wrote:

In T406114#11246826, @Esanders wrote:

@Krinkle Could we allow the skin to specify a default scroll-padding-top and then render that really early (e.g. an inline <style> tag in the <head>)?

According to https://www.mediawiki.org/wiki/Manual:How_to_make_a_MediaWiki_skin#Preparation , skins are "restricted from editing anything inside the HEAD", so I'm not sure how feasible that is?

It would probably need to be a core feature that the skin could override for just setting scroll-padding-top, not just allowing the skin to add arbitrary head tags.

Would adding a non-zero scroll-padding-top that early affect scrolling in contexts where the sticky header is not shown too? I'm not opposed to that (I like there to be a bit of room above the element I'm scrolling to), just asking. :-)

Probably in some edge cases, but as you say, scrolling a little too far is much better than not scrolling far enough.

Change #1217591 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/skins/Vector@master] Move scroll-padding-top to render-blocking CSS

https://gerrit.wikimedia.org/r/1217591

Change #1192980 abandoned by Esanders:

[mediawiki/skins/Vector@master] Make link targets obscured by sticky header scroll into view

Reason:

See I2f4a476bb474906c05ace1a389ecabea8ab8594f

https://gerrit.wikimedia.org/r/1192980

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://b8ea894641.catalyst.wmcloud.org/wiki/Talk:DiscussionTools#c-TheresNoTime-2021-10-19T20:09:00.000Z-Curb_Safe_Charmer-2021-10-19T20:06:00.000Z

Turns out the scroll-padding-top CSS was only getting added by a JS-loaded module, so moving to the core styles will make it load early enough.

The bug is easily reproduceable by loading a page with network caching disabled in the developer tools (and some bandwidth throttling if necessary).

In the above PatchDemo that is fixed (login is required to enable the sticky header).

There is a relatively low risk patch ready for review: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1217591

It just moves the scroll-padding-top rule to load earlier.

Change #1217591 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Move scroll-padding-top to render-blocking CSS

https://gerrit.wikimedia.org/r/1217591