Please add a screenshot yourself

Issues:

• Menus are not sticky. (Fixed on Chromium)
• In the dark mode, the headers of your own comments have a semi-transparent background color. Since I couldn’t add a backdrop, I used a blur effect instead. However, this makes the header text difficult to read on brighter backgrounds.
• Issue descriptions headers start to move a little bit earlier than they should:
  

From #8463 (comment):

• that bar
• mobile view
• notification bar
• automatically adjust when the notification bar is closed
• should still only be CSS only and avoid broad :has() usage (e.g. body:has())

Issue descriptions headers start to move a little bit earlier that they should:

It's unfortunately one of those things that will cause bug reports and I don't really want any more of those.

The solution is likely to use :has() but that's why one of the restrictions was specifically "no broad has" 🥲

Menus are not sticky.

They open in the right place at least, right?

Menus are not sticky.

They open in the right place at least, right?

Yes

Menus are not sticky.

More or less fixed

(Reposted from #8463 (comment) )

Browser: Firefox Nightly v142.0a1 32-bit

I've tested the artifact from:

https://github.com/refined-github/refined-github/actions/runs/16232281217?pr=8544

on below GH issue:

e3kskoy7wqk/Firefox-for-windows-7#69

and there's a bug when I scroll down to my comment; e.g.

e3kskoy7wqk/Firefox-for-windows-7#69 (comment)

is fine:

... however

e3kskoy7wqk/Firefox-for-windows-7#69 (comment)

appears bugged (the second fixed header has a transparent background) :

Hopefully an easy fix 😄 ...

appears bugged (the second fixed header has a transparent background) :

do you have hw acceleration enabled? backdrop-filter: blur doesn't work without it

As mentioned, this PR cannot be merged with filter so if there's no alternative solution it can be closed.

I don't see any css-only alternative

(Apologies for the tardy response, I had been away from my laptop for several hours 😉 )

do you have hw acceleration enabled?

Actually no 😞 ; this is a quite old laptop with a blacklisted, vendor customised, gfx driver that can't be further updated; so Firefox's WebRender is running in "Software" mode; but the overall browsing experience here is quite satisfactory for 99% of my needs (they exclude watching online 1080p video 😉 ) ...

backdrop-filter: blur doesn't work without it

... Sad to hear; it's unfortunate when website code discriminates against older H/W; and I'm not talking only about CSS here; websites have appeared (in WASM) which only load with a SSE4.2+ CPU 😠 ...

FWIW, the bug I reported seems to be more acute (on my system) when inside an issue tracker; things look much better when inside a PR's Conversation tab:

#8544 (comment)

I still think there's merit 👍 in this actual PR, thus sad it can't be implemented in a CSS-only manner; is everybody sure no compromise can be reached without filter ?

I see two alternatives to blurring:

1. What I did in my implementation for the mockup in Sticky header for issue / PR / discussion comments #8463 was to hardcode a non-transparent background color, sampling the resulting dark blue from applying the transparent color on top of the background color (alternatively, using a different existing non-transparent color from GitHub's CSS variables). If hardcoding values is unwanted, this could also possibly be calculated dynamically, using alpha compositing / blending.
2. Or, if calculating a non-transparent color value seems too brittle, then adding a new element behind the header (exactly sized to the header) with the GitHub background color would be another option

Mamma mia, i like it spaghetti

Do you dislike the suggested implementation, or the idea of explicitly connecting the two features?

Let me explain my reasoning:

• I think all features make sense for everyone (or most people) and I think they should be disabled when broken or causing issues (performance, etc)
• While I want features to be independent, I can consider scenarios where they can help/augment each other
• Since this is very rare, I don't want to set up the whole thing to declare features as dependent on each other: you'd have to parse this from the .tsx files and show it in the options UI, and all the maintenance burden that comes with this

The drawback is just some marinara and own comments that are not as bright as they should be IF you disable show-names. The alternative is using listeners on pages that get long and busy, worsening performance. I'll take the spaghetti.

Maintaining the extension is difficult enough given the frequency GitHub changes UIs and the quantity of features, I try to limit "meta" complexity by keeping things as simple as possible. There are already a long list of broken features; I shouldn't really be spending any time adding more of them right now.

I'm totally ok on piggybacking on show-names to add a class like rgh-own-comment so you can target it. That feature already detects and ignores them, so it can add the class and ignore them.

done

I've just installed the latest artifact from
https://github.com/refined-github/refined-github/actions/runs/16363550749?pr=8544
to test how this new feature is being developed and improved 👍 ; same system with old H/W as in my previous comment here, that doesn't allow for HW compositing/acceleration; some quick results:

1. Own comment inside a PR looks OK now, with a non-transparent sticky header; e.g. :
   sticky-comment-header - New feature #8544 (comment)

2. When on a repo's issue tracker, I see mixed results; if I am the OP/issue author, the sticky header is now non-transparent, which is OK in my system 👍 , e.g.:
   https://github.com/Eclipse-Community/r3dfox/issues/318#issue-3184196332

... however, when I have commented on someone else's original issue, the sticky header is still transparent; e.g.:
https://github.com/Eclipse-Community/r3dfox/issues/325#issuecomment-3046113949

Hopefully the geniuses here 😉 could also find a way to tackle this small visual bug...
Many thanks ❤️ for all the hard efforts and time spent by the coders to perfect this invaluable extension 🥇 !

when I have commented on someone else's original issue, the sticky header is still fully transparent

Yeah, happens sometimes because of #6554

generally ready to be re-reviewed

Sorry for wasting your time, but this feature is not practical to write and to support given the small advantage it gives. Closing

Ahh too bad! I understand the point about the React views being brittle. Hope this changes in future.

@SunsetTechuila @Vangelis66 thanks for your effort!

@Vangelis66: the sticky header is still fully transparent

Here's my version of the CSS that doesn't attempt to piggyback on show-names but rather sets everything to a default dark gray background:

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

@Vangelis66 thanks for your QA! It has proven very valuable

thanks for your QA! It has proven very valuable

... You're most welcome 😄 ; now back from a brief summer vacation 😜 and with access again to my old (but treasured) laptop... Below is the link to the last/most recent GH artifact implementing the proposed sticky-comment-header feature:

https://github.com/refined-github/refined-github/actions/runs/16389640058?pr=8544

(GH artifacts do expire over time, not sure about the "artifact retention" duration in this repo...)

If I'm allowed to share some last test findings (using above artifact), I'll have to note that @SunsetTechuila's implementation must have used CSS code properly supported only in fairly recent Firefox versions; this extension, in theory at least, currently supports the (now previous) FirefoxESR 128 branch (128.12.0esr was the last release; latest ESR is now v140-based, 140.1.0esr has just been released); below comments refer to artifact installation on FirefoxESR-v128.12.0 (32-bit):

1. The header of an own comment inside a PR Conversations tab is black (when non-stickied):

The same is true for "older" Fx versions such as 131.0.x and 135.0.x; in Fx 139.0.x, the header is non-transparent blue-ish (as posted above)

2. If I am the author of an issue in a tracker, the top (first) header is, again, black:

In Fx 139.0.x, the header is non-transparent blue-ish (as posted above)

3. The header of an own comment inside an issue tracker, in non-sticky mode, is blue-ish, consistent with recent Fx versions:

4. Own-comment headers inside an issue tracker are fully transparent (like glass) when in "sticky mode":

I realise my test findings have little value now, because:

1. The extension will soon drop support for out-going FxESR-128 versions (it's up to the devs, ofc)
2. This PR has been now closed 😞 ...

However, I decided to post them for "completeness" purposes 😉 ; apologies if I created unwanted noise 😊 ...