No need to force push here, it makes it difficult to see what changed between reviews of the code

I've accidentally committed lockfile changes, sorry

When one of my own comments has been hidden, either by me or the tracker's owner, the bluish stickied-header becomes transparent when I click the show comment header button:

yt-dlp/yt-dlp#14847 (comment)

The above is with latest artifact installed in Firefox (Nightly 144.0a1) ...

I don't believe myself this should fall under

Less attention to detail

😉 ; kind regards.

I click the show comment header button

this triggers a re-render, undoing any changes to the class list

When one of my own comments has been hidden, either by me or the tracker's owner, the bluish stickied-header becomes transparent when I click the show comment header button:

This doesn't appear to be a problem with the current Custom CSS version from my comment:

This doesn't appear to be a problem with #8463 (comment):

Because it doesn't rely on classes added by RGH

And you have to check your own comment. Also, I've already fixed that in 94a092d

When one of my own comments has been hidden, either by me or the tracker's owner, the bluish stickied-header becomes transparent when I click the show comment header button

... I can confirm this is now fixed 👍 🎉 when installing artifact:

https://github.com/refined-github/refined-github/actions/runs/19009740536/artifacts/4441037790

Thanks for your swift action ❤️ ...

Well, I had brought this up when PR #8544 was still open, but I think now is the time for a decision to be made...

At this very moment, judging by its manifest.json file,

	"browser_specific_settings": {
		"gecko": {
			"id": "{a4c4eda4-fb84-4a84-b4a1-f7c1cbf2a1ad}",
			"strict_min_version": "128.0"
		},

RGH still supports Mozilla Firefox 128.x.x, which includes the FxESR-128 branch...
Indeed, I can install artifact sticky-comment-header - New feature #14806 on FxESR-128.14.0 without an issue...
Be that as it may, this PR #8726 is quite broken on that version of Fx, because it uses CSS code implemented in later Fx versions; to get an idea, you can have a look at the comment I had posted in #8544, shortly after it was closed; also, below I have attached two new screenshots with the referenced artifact installed on 128.14.0:

PR own comment, e.g. #8726 (comment)

Issue own comment, e.g. #8463 (comment)

In both images, the "own" comment header has a solid black background, which becomes transparent when the header is being stickied 😞 ...

Mozilla have EoL'ed the 128esr branch with v128.14.0, the current ESR branch being 140-based 😉 ; so, it isn't imperative that RGH extends that 128esr support...

@SunsetTechuila can find and document the absolutely minimum version of Firefox that fully supports his #8726 code, and set that as the new minimum supported version inside the extension's manifest.json file.

If, for whatever other reason, the extension devs want to sustain 128esr support, then, perhaps, the extension could dynamically check the platform (browser engine) for specific CSS feature(s) support and if not found a) disable the sticky-comment-header feature altogether b) fallback to some 128esr-compatible "workaround" code, if at all possible...

Personally, for 128esr I still use the CSS code in @karlhorky 's comment ; "own" comment header background is dark grey (not bluish) and stays opaque when stickied:

#8544 (comment)

PS: This comment was written in FxESR-128.14.0 (32-bit) 😜 ; GitHub is still functioning here 😄 ...

Thanks for testing! Yeah we can definitely bump the minimum version in this PR to v140 for Firefox only

Support for single-color stop in linear-gradient() is limited, so it is best to avoid using it

@Vangelis66 try now

@Vangelis66 , try now

Well, back to fx-128.14.0esr, where I have just installed artifact

sticky-comment-header - New feature #14809

Test results 😉 :

PR own comment, e.g. #8726 (comment)

Issue own comment, e.g. #8463 (comment)

Issue unhidden own comment, e.g. yt-dlp/yt-dlp#14847 (comment)

So, all cases above appear as expected 🥇 🎉 ; many thanks indeed for your attention and prompt fixes to this specific "older" Fx support issue 😉 ...

@fregante, no need then to up the minimum supported Fx version in RGH itself, at least with regards to this specific "New feature" 😄 PR ...

Thanks for SunsetTechuila's coding efforts ❤️ , thanks overall for this indispensable extension for anyone using GH!

Best regards.

(Again, this comment was written using fx-128.14.0esr; there's a quite small "lag" in the editor, probably because GitHub are polyfilling (some of the) missing features - but it all works as it should!)

This feels awfully familiar. @yakov116 did we have this feature before?

#3577 we had this for the issue, I don't think we ever had it for the comment

don't merge this rn please

safe to merge

Is there anything I can do to help get this merged?

When the PR is ready for review, it should be marked as ready for review.

I'll check it this week and release a new version

Let's give this a go 🚀

@SunsetTechuila it looks like there's a visual bug with issue comments by the viewing user (your own issue comments) which are not the issue description comment at the top - the background is transparent and allows the content to make the header text unreadable:

This does not affect an issue description from the viewing user - the background is not transparent there:

All PR comments by the viewing user are also unaffected by this bug:

Should be visible for you in the issue, eg:

• Sticky header for issue / PR / discussion comments #8463 (comment)

Do you have show-names enabled?

No, I disable show-names because it makes the username ambiguous:

• show-names replacement of usernames w. real names breaks UX expectations, leads to ambiguity #8561

I remember reading somewhere that show-names was somehow tied to sticky-comment-header.

Would it be possible to use the CSS cascade to gracefully degrade in the case that show-names is disabled? For example:

1. by default using a hardcoded opaque dark blue - or even dark gray - instead of transparent
2. overriding this with another selector if show-names is enabled

@fregante @SunsetTechuila I see that #8809 was merged, but the fallback fixing the transparent header problem was reverted?

• 917f531

Does that mean that the problem still exists? Or am I misunderstanding the code in #8809?