1853570 - Touch event rotationAngle property is always 0 for me.

Status: RESOLVED INVALID

(Core :: Panning and Zooming, defect, P3)

Description

[Samuel Jackson]

Steps to reproduce:

I went to page https://www.w3schools.com/jsreF/event_touch_touches.asp , pressed the "Try It Yourself" button under the "Return the x- and y-coordinates of the touch" example, replaced .clientX with .rotationAngle , then pressed "Run", then touched the document with my finger on an android phone, making sure the area of contact is long enough.

Actual results:

It showed 0, no matter how I press the screen.

Expected results:

I expected it to show rotation angle of my finger. Properties radiusX and radiusY work, but they are useless without rotation angle.

Here is documentation for this property https://developer.mozilla.org/en-US/docs/Web/API/Touch/rotationAngle

Same result on Android Chrome.

Comment 1

[jackyzy823]

Not reproducible. I tested under Firefox 117 and Firefox Nightly 119.0a1, the number changes.

Comment 2

[Mike]

I was able to reproduce this bug by following your steps and replacing one of the client values with "rotationAngle", Please see attached screenshot showing a zero value for a large, entire-thumb press that should have generated a rotation angle for its contact oval https://imgur.com/a/0Li6wBI

Comment 3

[Samuel Jackson]

Here is a stackoverflow question with extra info and an easier way to reproduce https://stackoverflow.com/questions/77117574/why-mobile-javascript-touch-events-always-have-rotationangle-0-for-me

Comment 4

[jackyzy823]

Hello, I tested on OnePlus 7T (Android 11) , it was reproducible. I previously tested on Pixel 6 (Android 13), it wasn't reproducible.

So , it may depends on device (i guess mainly) or android version?

Comment 5

[Mike]

My test was conducted on a Samsung S10+ with Android 12 and Firefox 117.1.0; additionally it did not work on chrome

Comment 6

[Samuel Jackson]

Android 13, Samsung Galaxy M12, rotationAngle is always 0.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jonalmeida, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Jonathan Almeida [:jonalmeida]]

Thanks for reporting! I can reproduce this with our Samsung Galaxy A51 which means we have a reproducible device/state.

I'm forwarding this to the Panning and Zooming component.

Comment 9

[Botond Ballo [:botond] [away until July 9]]

Here is the code that computes the rotationAngle value on Android.

It's computed based on the orientation, toolMajor, and toolMinor fields of the PointerCoords object exposed by the Android API MotionEvent.getPointerCoords().

So the thing to check here would be:

• Are the original values on the MotionEvent in line with expectations? If not, it's an issue with the Android OS or hardware.
• If so, where does our computation for rotationAngle go wrong.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Samuel Jackson]

Attachment: Android program to test orientation value

Made an android program that tests if orientation is always 0 in general for me, and yes, it is. Added it as an attachment.

Can somebody here forward this bug to google?

Also question about documentation here https://developer.mozilla.org/en-US/docs/Web/API/Touch/rotationAngle . It says that it goes from 0 to 90, which means 1/4 of a circle. But it needs to go from -90 to 90 to be useful, to represent all possible rotations of a finger. The original api went from -pi/2 to pi/2 https://developer.android.com/reference/android/view/MotionEvent.PointerCoords#orientation

Comment 12

[Botond Ballo [:botond] [away until July 9]]

(In reply to Samuel Jackson from comment #11)

Can somebody here forward this bug to google?

You can report it using the instructions at https://source.android.com/docs/setup/contribute/report-bugs.

Also question about documentation here https://developer.mozilla.org/en-US/docs/Web/API/Touch/rotationAngle . It says that it goes from 0 to 90, which means 1/4 of a circle. But it needs to go from -90 to 90 to be useful, to represent all possible rotations of a finger. The original api went from -pi/2 to pi/2 https://developer.android.com/reference/android/view/MotionEvent.PointerCoords#orientation

The representations are slightly different, but they're equally expressive.

The Android API's representation is an angle that can go from -90 to 90 (orientation), and the major and minor radii of the ellipse representing the touch area (toolMajor and toolMinor). The major radius will always be the larger one.

The web API's representation is an angle that can go from 0 to 90 (rotationAngle), and two radii (radiusX and radiusY), but there is no constraint that one radius is always the larger one. So, the set of values that the Andoid API represents with a negative angle, the web API represents with a positive angle but the two radii swapped.

Let me know if that makes sense.

Comment 13

[Samuel Jackson]

That made sense, thanks for explanation.

I was wrong, "orientation" that my program showed was rotation of the screen itself rather than the finger, I didn't notice it in time. It shows -1.57 when I rotate phone to the left or 1.57 when I rotate phone to the right. This seems to contradict documentation a bit though, https://developer.android.com/reference/android/view/MotionEvent.PointerCoords#orientation says "finger pointing fully left" and "finger pointing fully right", not screen.

Here is the code I use, maybe I do something wrong again? I edited it a bit and left old code in comments, but they both show same result. Not sure how to do kotlin syntax highlighting.

    override fun onTouchEvent(event: MotionEvent?): Boolean {

        if (event != null) {
            if (event.pointerCount >= 1) {
                var pointerCount = event.pointerCount

                var pointerId = event.getPointerId(0)
                var pointerIndex = event.findPointerIndex(pointerId)


                /*val x = event.x
                val y = event.y
                var or = event.orientation*/

                var x = event.getX(pointerIndex)
                var y = event.getY(pointerIndex)
                var or = event.getOrientation(pointerIndex)

                dbgstr.value = "touch happened: count: $pointerCount, x: $x, y: $y, or: $or."
            } else {
                dbgstr.value = "pointerCount 0"
            }
        } else {
            dbgstr.value = "null"
        }

        return super.onTouchEvent(event)
    }

Comment 14

[Botond Ballo [:botond] [away until July 9]]

(In reply to Samuel Jackson from comment #13)

I was wrong, "orientation" that my program showed was rotation of the screen itself rather than the finger, I didn't notice it in time. It shows -1.57 when I rotate phone to the left or 1.57 when I rotate phone to the right. This seems to contradict documentation a bit though, https://developer.android.com/reference/android/view/MotionEvent.PointerCoords#orientation says "finger pointing fully left" and "finger pointing fully right", not screen.

I can see the phone rotation being factored into the orientation, e.g. the angle is always given relative to the line pointing towards the top of the phone, so that if the phone is in portrait mode an ellipse pointing physically upwards has angle 0, but if the phone is in landscape mode an ellipse pointing phyically upwards has angle pi/2 (1.57).

The fact that you're not getting any values in between would suggest that maybe the touchscreen on your phone is not capable of discriminating the orientation of the finger itself, or it's not communicating this information to the OS properly?

Comment 15

[Botond Ballo [:botond] [away until July 9]]

I'm going to close this issue because based on the discussion so far, it does not look like there is a Firefox issue here; to the extent that the observed behaviour is unexpected, the issue seems to be at the level of the Android OS or the hardware.

If there's new information that suggests there's a Firefox issue here, please feel free to re-open.