Closed Bug 710704 Opened 8 years ago Closed 8 years ago

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

Categories

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

ARM
Android
defect

Tracking

()

VERIFIED FIXED
Firefox 12
Tracking Status
firefox11 --- verified
firefox12 --- verified
fennec 11+ ---

People

(Reporter: andreea.pod, Assigned: Margaret)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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
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.
Blocks: 697265
Keywords: regression
Got a simpler test case. I am too lazy to go to this one specific website.
Also note: We do not "auto zoom in" when tapping on textboxes, or any other widgets.
I can reproduce this on the air canada site, but other editboxes work just fine.
I see this error in logcat:

E/GeckoConsole(11309): [JavaScript Error: "tab is null" {file: "chrome://browser/content/browser.js" line: 1921}]
(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
The underlying cause for this is the same as bug 710869 - the input field is inside an iframe.
Summary: Form fields not accessible on www.aircanada.com → [frames] Form fields not accessible on www.aircanada.com
I have a patch in progress
Assignee: nobody → mark.finkle
Attached patch WIP (obsolete) — Splinter Review
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.
A simpler test case would make this a little easier to debug.
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).
Priority: -- → P2
tracking-fennec: --- → 11+
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.
Assignee: mark.finkle → margaret.leibovic
Attached patch patchSplinter Review
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?
Attachment #581981 - Attachment is obsolete: true
Attachment #588243 - Flags: review?(wjohnston)
Duplicate of this bug: 715630
(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 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!
Attachment #588243 - Flags: review?(wjohnston) → review+
Is bug 709663 a duplicate of this bug?
(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.
https://hg.mozilla.org/mozilla-central/rev/1e60b2e0c8a3
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 12
Comment on attachment 588243 [details] [diff] [review]
patch

[Approval Request Comment]
Working well on m-c. Without this, clicks in iframes are busted.
Attachment #588243 - Flags: approval-mozilla-aurora?
Comment on attachment 588243 [details] [diff] [review]
patch

[Triage Comment]
Mobile only - approved for Aurora.
Attachment #588243 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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)
Status: RESOLVED → VERIFIED
Duplicate of this bug: 709663
You need to log in before you can comment on or make changes to this bug.