github-wc-polyfill icon indicating copy to clipboard operation
github-wc-polyfill copied to clipboard

Reaction tooltips missing on "Releases" page / Missing tooltips for Editor's toolbar buttons

Open Vangelis66 opened this issue 3 years ago • 13 comments

Browser: Latest (UXP-based) Serpent 52.9.0 (2022-02-25) (32-bit) Browser profile: Fresh/clean one (with default settings), only this extension installed Extension version: Latest release, i.e. v1.12.15

STR

  1. Make sure you're already signed-in, as this GitHub feature is reserved for GitHub members...
  2. Load e.g. https://github.com/SeaHOH/github-wc-polyfill/releases In the "reactions" area, just below "Assets", you'll see that (at the time of this writing) 6 members have reacted with :+1: and another with a :heart: emoji.
  3. Place the cursor on top of either reaction; expected behaviour: A tooltip containing the usernames of the members that reacted similarly:

tooltip

(the above was taken with a Chromium-derived browser)

actual behaviour: No tooltip is being displayed:

tooltip2

(St52+gh-wc-pf-1.12.15)

NB: "Reaction" tooltips are being displayed correctly on Comment reactions...

Addendum:

It later emerged that the GitHub editor's toolbar buttons are similarly affected, i.e.

  1. Scroll down this page to find the "New Comment" input field (you also need to be signed-in).
  2. Hover with the cursor over one of the editor's toolbar buttons,

c3

expected behaviour: A tooltip pops-up, explaining the function of selected button:

c4

(Chromium-derived browser)

actual behaviour: Tooltip missing:

c2

(St52+gh-wc-pf-1.12.15)

Vangelis66 avatar Mar 07 '22 03:03 Vangelis66

I can't find the reason. A style as dirty fix is:

.hx_tooltip {
  position: static !important;
  opacity: 1 !important;
}

SeaHOH avatar Mar 07 '22 06:03 SeaHOH

for uBo github.com##.hx_tooltip:style(opacity: 1 !important;) 👍 it's just my opinion or (a little different effect) github.com##.hx_tooltip:style(position: static !important; opacity: 1 !important;)

pic1:

bughh0021

AroKol78 avatar Mar 07 '22 11:03 AroKol78

Thanks for investigating this 👍 ; I still hope a proper solution will present itself in due course... 😉

for uBO:

github.com##.hx_tooltip:style(position: static !important; opacity: 1 !important;)

Unfortunately, that one, as well as the CSS style proposed by SeaHOH do also affect other GH regions, e.g. the position of tooltips that pop-up when hovering over the comment editor's toolbar buttons:

C1

which, I have come to realise now, are also plagued by that very same bug 😠 ...

Vangelis66 avatar Mar 07 '22 21:03 Vangelis66

First post as well as issue's title have been updated...

Vangelis66 avatar Mar 07 '22 22:03 Vangelis66

Is this more better?

markdown-toolbar > div, .js-pick-reaction > div {
  position: relative !important;
}
.hx_tooltip {
  opacity: 1 !important;
  bottom: 110% !important;
  left: 0 !important;
}

SeaHOH avatar Mar 08 '22 15:03 SeaHOH

it's OK

pic1:

isokgh001

AroKol78 avatar Mar 08 '22 16:03 AroKol78

Is this more better?

It certainly is a compromise one could live with... :+1: :smile:

FTR, in Chromium every button in the editor's toolbar spawns its own tooltip when hovered, displayed slightly below said button (see opening post, 4th attached screenshot); with that latest userstyle, every 3 successive buttons, starting from left to right (1-3, 4-6, 7-9, 10-12), share the same tooltip position, displayed slightly above the button(s) ...

As for Releases reaction tooltips, these are now displayed above the emojis, which is closer to what Chromium does... :+1:

At the end of the day, without me nitpicking :stuck_out_tongue_winking_eye: , all required information (provided by the tooltips) is indeed displayed in an acceptable fashion, so, unless somebody has an "epiphany" on the actual root cause of this bug in UXP, "we" could settle for such a CSS workaround... Many thanks!

Vangelis66 avatar Mar 08 '22 23:03 Vangelis66

github-wc-polyfill-1.2.16b2 I caught it, an attribute issue by named hidden.

SeaHOH avatar Mar 09 '22 06:03 SeaHOH

I caught it, an attribute issue by named hidden

👍 🥇 🎉 🚀 :

F2

F1

(St52+gh-wc-pf-1.2.16b2)

... Someone did have an epiphany, for sure! 😄 Closing this, thanks...

Vangelis66 avatar Mar 09 '22 14:03 Vangelis66

nothing serious when deleting an earlier comment (ST52 + 1.2.16)

pic1:

gh002bug

AroKol78 avatar Mar 10 '22 13:03 AroKol78

when deleting an earlier comment (ST52 + 1.2.16)

I can replicate 👍 :

b1

; but why do you think it's related to this closed issue? I get the same result with 1.2.16b1, too, which doesn't contain the "fix" for #54 ...

Additionally, when I actually delete a comment revision, the whole webpage reloads 😠 ; not sure whether it's a bug or intended behaviour... How do latest Chrome/Firefox act in that regard (I can't test in this laptop now...) ? If they do it differently, perhaps I (or someone else 😜 ) should file a new, separate, issue ...

Vangelis66 avatar Mar 11 '22 02:03 Vangelis66

it just gives a signal that something like that is (i don't even know if it's specific to UXP only)

AroKol78 avatar Mar 11 '22 15:03 AroKol78

I know the extension has been abandoned now, however, for clarity reasons, this original issue has, as of the first week of Aug 2022, come back now :rage:, involving ALL GH tooltips, i.e. both the Editor's toolbar buttons as well as reaction tooltips on comments/releases...

Anyone willing to take a look, please chime in... 😉

Vangelis66 avatar Aug 07 '22 16:08 Vangelis66

The issue has been successfully resolved a second time, by @roytam1, by backporting fixes from the currently maintained fork, palefill 🎉 ... For the updated source code, look at: https://github.com/roytam1/github-wc-polyfill/commit/1a0d796a8a63497edea54e4baea56cb4dfda6e71 For compiled source, i.e. an .XPI file, look here 👍 .

Many thanks to all the devs (roytam1, SeaHOH, martok) involved! ❤️

Vangelis66 avatar Aug 17 '22 15:08 Vangelis66