Touch coordinates are wrong when screen is rotated

RESOLVED FIXED in Firefox 26

Status

defect
RESOLVED FIXED
6 years ago
9 months ago

People

(Reporter: gbennett, Assigned: mwu)

Tracking

({regression})

Trunk
mozilla27
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:koi+, firefox25 wontfix, firefox26 fixed, firefox27 fixed, b2g18 unaffected, b2g18-v1.0.0 unaffected, b2g18-v1.0.1 unaffected, b2g-v1.1hd unaffected, b2g-v1.2 fixed)

Details

(Whiteboard: burirun1)

Attachments

(3 attachments, 1 obsolete attachment)

Description:
After launching an app and changing orientation to landscape mode pressing the home button does not work. This does not repro when holding the device sideways within an app that cannot change orientation (contacts).

Repro Steps:
1) Updated Buri 1.2 to Build ID: 20130910040201
2) Open Browser.
3) Change orientation to landscape.
4) Press home button.

Actual:
Home button does not vibrate or bring user to the home screen when pressed.

Expected:
Home button vibrates and brings the user to the home screen when pressed.

Environmental Variables
Build ID: 20130910040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/be1053dc223b
Gaia: 6deda9d7c51f278443f704217eaed722044a03e7
Platform Version: 26.0a1

Notes: I repro'd this using gallery, browser, and video.
Repro frequency: 100%, 6/6
See attached: LandscapeHomeButtonLog.txt
blocking-b2g: --- → koi?
Component: Gaia → Gaia::System
When the user changes the orientation on the gallery/video app. The tool bar icons found on these apps on landscape mode becomes non functional. 

Please see the video of the issue http://youtu.be/z26PcVpn8fM

Environmental Variables
Buri Build ID: 20130910040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/be1053dc223b
Gaia: 6deda9d7c51f278443f704217eaed722044a03e7
Platform Version: 26.0a1
QA Contact: nkot
Regression range:

Build ID: 20130906040204 - Does NOT Reproduce
Gecko: http://hg.mozilla.org/mozilla-central/rev/ab5f29823236
Gaia: 94e5f269874b02ac0ea796b64ab995fce9efa4b3
Platform Version: 26.0a1

Build ID: 20130909114657 - Reproduces
Gecko: http://hg.mozilla.org/mozilla-central/rev/218d4334d29e
Gaia: aa4180e9286d385fa6b62d236f30fb24cd8b93e9
Platform Version: 26.0a1
The Gaia commit log shows evidence that Alive was doing changes here recently in the System app.

Alive - Any ideas on what's failing here?
Flags: needinfo?(alive)
This sounds terrible.

Jason, I couldn't repro on latest gaia: efd21eddc030c2232b2e4707650995ed7714c38e
My device is inari.

Also from the video, the phone seems totally hang...
Flags: needinfo?(alive)
For those watching the bug - I confirmed a reproduction of this on 9/10/2013 unagi build. Alive has borrowed my device to debug this.
I do think this is a gecko issue. I don't get mozChromeEvent once device is landscape-oriented.
Lemme debug from shell.js...
(In reply to Alive Kuo [:alive] from comment #7)
> Lemme debug from shell.js...

There's no keydown/keyup/keypress event in landscape mode. Only for home button. Very strange...
Anyway I was able to repro after flashing latest pvt build to my inari.

Jason, I need regression window on this one -- for mozilla-central. Also you could bring your device back.
http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#447
No event is fired here.
Also the touch screen seems totally failing - UI is unresponsive.
Component: Gaia::System → General
Summary: [B2G][Buri 1.2][Landscape]Home button does not function when an app is in landscape → When orientation is unlocked and put the phone to landscape, UI seems unresponsive and key event of home button is losing.
Fabrice - Do you know who on the gecko side could look into something like this issue?
Flags: needinfo?(fabrice)
This shall be caused by changes very recently. I flashed my inari from pvtbuild yesterday (afternoon?) and everything is fine so I wrote comment 4.

My working sources.xml
https://gist.github.com/alivedise/6522946
(In reply to nkot from comment #2)
> Regression range:
> 
> Build ID: 20130906040204 - Does NOT Reproduce
> Gecko: http://hg.mozilla.org/mozilla-central/rev/ab5f29823236
> Gaia: 94e5f269874b02ac0ea796b64ab995fce9efa4b3
> Platform Version: 26.0a1
> 
> Build ID: 20130909114657 - Reproduces
> Gecko: http://hg.mozilla.org/mozilla-central/rev/218d4334d29e
> Gaia: aa4180e9286d385fa6b62d236f30fb24cd8b93e9
> Platform Version: 26.0a1

Which gives this list of changesets:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab5f29823236&tochange=218d4334d29e
What this bug really seems to need is further bisection down to one changeset.
(In reply to Benoit Jacob [:bjacob] from comment #13)
> What this bug really seems to need is further bisection down to one
> changeset.

We could get down to a build within a 12 hour range, but after that, we don't have any release builds to get a deeper regression range.
Right, so someone needs to make builds from sources, by hand. I'm not signing up for this labor-intensive tasks given that I have other bugs to work on :-)
(In reply to Jason Smith [:jsmith] from comment #14)
> (In reply to Benoit Jacob [:bjacob] from comment #13)
> > What this bug really seems to need is further bisection down to one
> > changeset.
> 
> We could get down to a build within a 12 hour range, but after that, we
> don't have any release builds to get a deeper regression range.

Actually I'm not right here - https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-central-unagi/2013/09/ shows that 9/6 to 9/9 is the deepest we can go by rel eng builds.
Is there a way to reproduce this on an emulator?
Apparently yes, Ctrl+F11 and Ctrl+F12 should both tell the emulator to switch orientation.

Here for me, Ctrl+F11 works (while Ctrl+F12 is intercepted by my window manager).

http://stackoverflow.com/questions/1991318/how-to-change-emulator-screen-orientation
No longer blocks: GFXB2G1.2
Here on emulator, I can reproduce the issue that in the Gallery app, in landscape mode, the 'camera' button does not do anything.

I cannot reproduce issues with the home button. The home button works for me.
Self-assigning, bisecting.
Assignee: nobody → bjacob
Flags: needinfo?(fabrice)
I'm half-way through bisection, made harder by being near a revision range that fails to bool, here is what I have:

145771:ab5f29823236 good
145953:028b937786cb good
145955:36cc6b1669b4 fails to boot
145996:8a73c481e49e fails to boot
146004:ba0ecbba9add bad
146068:4ca898d7db5f bad
146137:218d4334d29e bad
Component: General → Graphics
Product: Boot2Gecko → Core
Version: unspecified → Trunk
Regarding this component change --- there is still no definite reason to consider this bug graphics related. But let me finish bisecting...
Finished bisecting, the first bad changeset is:

http://hg.mozilla.org/mozilla-central/rev/0b914f0e61ab

Bug 908797 - Update libui to the latest input code from JB MR2

-> blocking bug 908797, un-blocking the gfx tracking bug. Not a graphics bug.
Blocks: 908797
No longer blocks: GFXB2G1.2
Component: Graphics → Widget: Gonk
Assignee: bjacob → nobody
Note: there have been multiple symptoms discussed above. The specific one I'm talking about is that in the Gallery app, in landscape mode, the 'camera' button (which should allow switching back to the camera mode to take new pictures) does nothing.
(In reply to Deepa Subramanian from comment #1)
> When the user changes the orientation on the gallery/video app. The tool bar
> icons found on these apps on landscape mode becomes non functional. 

^ that is what I am talking about (the only thing that I was able to reproduce).
Assignee: nobody → vwang
It looks like the mXScale and mYScale is not correct in landscape mode, it will cause the touch event mapping incorrect.
I think problem comes from the mSurfaceWidth and mSurfaceHeight.

    // The surface orientation, width and height set by configureSurface().
    // The width and height are derived from the viewport but are specified
    // in the natural orientation.
    int32_t mSurfaceWidth;
    int32_t mSurfaceHeight;

Take N4 for example, it should be 768(width)*1280(height) no matter it's landscape or portrait.
But we have 768*1280 in portrait and 1280*768 in landscape mode now.

Since we always setDisplayInfo with gScreenBounds.width and gScreenBounds.height in nsAppShell, I'm thinking we should used it directly as the mSurfacewidth and mSurfaceHeight in TouchInputMapper::configureSurface without considering the orientation. 

I would like to fix the mXScale and mYScale in configureSurface, and we can have correct coordination in cookPointerData
This patch will keep the correct mXScale/mYScale, and we can have the correct touch panel points for applications
Attachment #808483 - Flags: review?(mwu)
(In reply to viral [:viralwang] from comment #29)
> Created attachment 808483 [details] [diff] [review]
> fix the mXScale and mYScale in configureSurface and leave the coordination
> in cookPointerData. (v1)
> 
> This patch will keep the correct mXScale/mYScale, and we can have the
> correct touch panel points for applications

As mentioned in bug 908797, I would like to minimize changes to any code in widget/gonk/libui. We should be able to fix this in nsAppShell.cpp, right?
Sorry - gonna steal this bug. This is a pretty bad regression and I'd like to get it fixed sooner.
Assignee: vwang → mwu
Attachment #808483 - Attachment is obsolete: true
Attachment #808483 - Flags: review?(mwu)
Attachment #809457 - Flags: review?(mvines)
http://androidxref.com/4.3_r2.1/xref/frameworks/base/services/java/com/android/server/display/DisplayViewport.java has some explanation for the different fields in the C++ version of DisplayViewport.
Comment on attachment 809457 [details] [diff] [review]
Fix touch events when rotated

Review of attachment 809457 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm.
Attachment #809457 - Flags: review?(mvines) → review+
ftfy
blocking-b2g: koi? → koi+
blocking-b2g: koi+ → koi?
Summary: When orientation is unlocked and put the phone to landscape, UI seems unresponsive and key event of home button is losing. → Touch coordinates are wrong when screen is rotated
blocking-b2g: koi? → koi+
https://hg.mozilla.org/mozilla-central/rev/ddf051d653ec
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.