710704 - [frames] Form fields not accessible on www.aircanada.com

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Andreea Pod]

Mozilla /5.0 (Android;Linux armv7l;rv:11.0a1) Gecko/20111214 Firefox/11.0a1 Fennec/11.0a1 
Device: LG Optimus 2X (Android 2.2)

Steps to reproduce:
1. Go to www.aircanada.com
2. Click on "Canada - English"
3. Click on "Flight Status"
4. Tap on the flight number field next to "AC" and the date field.

Expected result: 
The page should be zoomed into towards the field and you should be able to input characters into that field.

Actual result:
page is not zoomed in and you are not able to input characters, the text field is only highlighted. 

Note: 
- testcase: https://litmus.mozilla.org/show_test.cgi?id=33637

Comment 1

[Aaron Train [:aaronmt]]

This looks like a regression from bug 697265. As soon as I select tap and hold on a field, select an operation in the context menu, input works.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Got a simpler test case. I am too lazy to go to this one specific website.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Also note: We do not "auto zoom in" when tapping on textboxes, or any other widgets.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

I can reproduce this on the air canada site, but other editboxes work just fine.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

I see this error in logcat:

E/GeckoConsole(11309): [JavaScript Error: "tab is null" {file: "chrome://browser/content/browser.js" line: 1921}]

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Aaron Train [:aaronmt] from comment #1)
> This looks like a regression from bug 697265. As soon as I select tap and
> hold on a field, select an operation in the context menu, input works.

I think this is because we are focusing the textbox in the clipboard operation. Not sure it is really a regression from bug 697265

Comment 7

[Kartikaya Gupta (email:[e-mail])]

The underlying cause for this is the same as bug 710869 - the input field is inside an iframe.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

I have a patch in progress

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: WIP

This WIP patch cleans up the toBrowserCoords and toScreenCoords methods. Among other things:
* Never fallback to the selected tab. Always expect a window to be provided
* Use the Topmost window to find the Browser, and Tab, in the case of iframes

The said news is that this patch does not fix the issue. It only stops the JS error from happening. The mouse events are still being sent to the wrong location. For example, at certain zoom/scroll situations, when I tap on the "AC" edit box a mouse click is fired on the editboxes below it.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

A simpler test case would make this a little easier to debug.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Simpler test case is at http://people.mozilla.org/~kgupta/bug/710869.html (it just embeds a different simple page with an input field into an iframe).

Comment 13

[:Margaret Leibovic]

This looks like it might end up being the same as bug 715630, but we can keep it open until we know it's fixed.

Comment 14

[:Margaret Leibovic]

Attachment: patch

This is mostly just mfinkle's patch, but I fixed the window we were using for cwu.sendMouseEventToWindow in _sendMouseEvent, and that fixed the coordinate positioning problems.

Also, toScreenCoords is also used in anyElementFromPoint and elementFromPoint, so should I be worrying about it throwing in there?

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Margaret Leibovic [:margaret] from comment #14)

> Also, toScreenCoords is also used in anyElementFromPoint and
> elementFromPoint, so should I be worrying about it throwing in there?

I am not sure what to do in those functions. Using a try/catch and returning a null element is one way to do it, but that might just bandaid a bigger problem. I am more inclined to let the exception happen, so we at least know about it.

Comment 17

[Wesley Johnston (:wesj)]

Comment on attachment 588243 [details] [diff] [review]
patch

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

::: mobile/android/chrome/content/browser.js
@@ +2084,5 @@
> +          if (ElementTouchHelper.isElementClickable(element))
> +            Haptic.performSimpleAction(Haptic.LongPress);
> +        } catch(e) {
> +          Cu.reportError(e);
> +        }

Cool. I think this try catch may help with times when we have "erratic" tap highlights not disappearing too!

Comment 18

[Martijn Wargers (dead)]

Is bug 709663 a duplicate of this bug?

Comment 19

[:Margaret Leibovic]

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #18)
> Is bug 709663 a duplicate of this bug?

It looks like it probably is. I'm going to land this today, so we can test in Nightly tomorrow before we mark it as a dupe.

Comment 20

[:Margaret Leibovic]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1e60b2e0c8a3

Comment 21

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/1e60b2e0c8a3

Comment 22

[:Margaret Leibovic]

Comment on attachment 588243 [details] [diff] [review]
patch

[Approval Request Comment]
Working well on m-c. Without this, clicks in iframes are busted.

Comment 23

[Alex Keybl [:akeybl]]

Comment on attachment 588243 [details] [diff] [review]
patch

[Triage Comment]
Mobile only - approved for Aurora.

Comment 24

[Mark Finkle (:mfinkle) (use needinfo?)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/b89dfc2f350e

Comment 25

[Catalin Suciu [:csuciu]]

Verified fixed on Nightly 12.0a1 (2012-01-18) and on Aurora 11.0a2 (2012-01-18).
Device: Samsung Galaxy S2 (Android 2.3.4)