Fixed Reaction issue on Android

[The Colonel]

Affected version

2.3.4

So the forum I volunteer as a mod on has had some reports of funky behavior. I am not the owner so if this is the wrong section; apologies in advance.

Reaction selection is exhibiting odd behavior for end users. When you hit the like button to select the desired reaction for longer than a micro-second; it brings up the right-click context menu instead of allowing you to pick the reaction you want. This is on mobile only. See screenshot below. Not a problem on IOS.

 

[M@rc]

Maybe dup:

Fixed Thread 'Reactions on mobile device'

Aug 16, 2023

Have you ever tried to select a reaction other than the default, “Like” on a device that doesn’t have “hover” ability (like a phone)? Try it. It’s always been so irritating I assume it’s going to be fixed at some point, but maybe I’m the only one that notices somehow?

• digitalpoint
• reactions
• Replies: 42
• Forum: Resolved bug reports

• 
• 

On Android, this happens with any link, not just with the reaction link.

 

[The Colonel]

Honestly, it popped up recently. It got reported here within the last few days. It never used to do that, for what it's worth. Maybe something that can get addressed on the phone OS itself. Thanks for the reply.

 

[mjda]

This was reported almost a year ago.

Fixed Thread 'Long pressing reaction'

Mar 6, 2024

When long pressing the reaction button I'm now getting a popup like long pressing a standard link, as seen in the attached screenshot.

I just verified that it doesn't happen in any of my sites running the latest version of XF. It only does it on this site and I only noticed it today.

Oh yeah...I'm using Chrome on Android 14.

• mjda
• Replies: 39
• Forum: Bug reports

• 

 

[beerForo]

This was reported almost a year ago.

However now it is happened with just a quick tap.

 

[mjda]

However now it is happened with just a quick tap.

Still the same as it was before for me. It takes about a half second, or so, for the dialog to pop up.

 

[beerForo]

It's instant for me. Something changed like others are saying. I have to click outside the box to get it to disappear.

 

[PixelOrange]

This issue occurred to me when I upgraded to 2.3.x yesterday.

The fix is to edit your default style's react template to include

oncontextmenu="return false"

Without fix:

<xf:reaction id="{$reaction}"
    content="{$content}" link="{$link}" params="{$params}" list="{$list}" class="{$class}"
    init="true" hasreaction="{$hasReaction}" small="true" showtitle="true"  />

With fix:

<xf:reaction id="{$reaction}"
    content="{$content}" link="{$link}" params="{$params}" list="{$list}" class="{$class}"
    init="true" hasreaction="{$hasReaction}" small="true" showtitle="true" oncontextmenu="return false" />

If you have themes that aren't inheriting from the default style, you'll have to apply this on every top-level style.

 

[badmonkey]

This worked for me. Thanks for this!

 

[Jeremy P]

A candidate fix for this has been rolled out here, if anyone experiencing issues wants to test it out.

 

[beerForo]

A candidate fix for this has been rolled out here, if anyone experiencing issues wants to test it out.

Does seem fixed here!

 

[digitalpoint]

Better, but still some weirdness with how text gets selected when you hold. Sometimes on the “Like” text as well. Maybe some CSS is in order?

user-select: none;

 

[Chris D]

Many years ago, that was omitted deliberately because while it caused the nearest element to the tap hold to no longer become selected, iOS would then find the next nearest element and start selecting that instead, and ultimately that became weirder than the current behaviour.

I'm sure WebKit has fixed that after all of this time... right?

 

[digitalpoint]

Hah who knows… what if some JS was added that adds user-select: none; to the entire HTML element on click and removes it on release of that click?

 

[digitalpoint]

Many years ago, that was omitted deliberately because while it caused the nearest element to the tap hold to no longer become selected, iOS would then find the next nearest element and start selecting that instead, and ultimately that became weirder than the current behaviour.

I'm sure WebKit has fixed that after all of this time... right?

So I actually tested it, and this does appear to make it work as expected:

.message-footer {
  -webkit-user-select: none;
  user-select: none;
}

SO much better.

Safari does need the -webkit prefix, but seems to be working as expected... so maybe WebKit did fix whatever the issue was.

 

[Jeremy P]

Not rolled out here just yet, but we've made further adjustments to include that so should be sorted for the next release.

 

[Jeremy P]

Actually, looks like there might still be some issues there unfortunately It still seems to select the parent container and so forth in our testing. There might be some other tricks we can apply here though (like applying it more broadly for the touchhold duration as you say). We'll have to play around with it.

 

[digitalpoint]

Actually, looks like there might still be some issues there unfortunately It still seems to select the parent container and so forth in our testing. There might be some other tricks we can apply here though (like applying it more broadly for the touchhold duration as you say). We'll have to play around with it.

Maybe you just have fat fingers? hah j/k... I obviously didn't test it exhaustively, it was more a 10 second thing to inject the CSS to the message footer and click it a couple times. Was working for me, but also was one browser, one device and a couple clicks is all.

 

[Jeremy P]

Okay turned out to just be a sticky CSS cache issue. It's now rolled out here and seems to work just fine