Closed Bug 779920 Opened 9 years ago Closed 9 years ago

Tapping link in small iframe doesn't work

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox17 verified, firefox18 verified)

VERIFIED FIXED
Firefox 17
Tracking Status
firefox17 --- verified
firefox18 --- verified

People

(Reporter: martijn.martijn, Assigned: kats)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

See url, steps to reproduce:
- At bottom of article, there is a link next to the text: "Reageer op dit artikel", tap on this link.

Expected result:
- New tab opens with this link

Actual result:
- Nothing happens

I guess the whole tap-hitting code in frames is broken, because I'm unable to focus the textarea in the iframe at: http://people.mozilla.org/~mwargers/tests/iframetextarea.html

Also not able to focus the input in the small iframe at: http://people.mozilla.org/~mwargers/tests/forms/textinput/parentframe.html
Tapping the little red circle in the article fires this logcat:

08-06 14:27:47.359: I/GeckoScreenshot(10144): rect: 251.233337, 138.033340, 198.033340, 269.233337
08-06 14:27:47.586: E/GeckoConsole(10144): [JavaScript Error: "aElement is null" {file: "chrome://browser/content/browser.js" line: 3520}]
08-06 14:27:47.664: I/GeckoScreenshot(10144): rect: 251.233337, 138.033340, 198.033340, 269.233337
This is a regression from bug 770659. There is a mismatch in the window and coordinates that are passed to the call to anyElementFromPoint that I added there.
Assignee: nobody → bugmail.mozilla
Blocks: 770659
Duplicate of this bug: 780424
Attached patch PatchSplinter Review
I'm tempted to remove the window parameter to anyElementFromPoint and just use BrowserApp.selectedBrowser.contentWindow in the function, which is effectively what every caller of that function does. Same for ElementTouchHandler.elementFromPoint. What do you think?
Attachment #649760 - Flags: review?(wjohnston)
Comment on attachment 649760 [details] [diff] [review]
Patch

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

Removing the paramter seems fine to me.

I think I did something similar once (forcing window.top in the function), which was probably not as good an idea. I pinged mfinkle on irc to see if he has an opinion, but we should open a bug and people can comment there too.
Attachment #649760 - Flags: review?(wjohnston) → review+
I tend to dislike assuming all of our code is using the selected tab. I don't mind reordering the params and passing the window, optionally as the last param.
Filed bug 780975 for the follow-up. I'll land this patch as-is to fix the regression.
https://hg.mozilla.org/mozilla-central/rev/8ef97697b18d
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 17
STRs from comment #0 are working as expected on the latest Nightly build. On Aurora build also everything works fine either. Closing bug as verified fixed on:

Firefox 18.0a1 (2012-09-11)
Device: Galaxy Note
OS: Android 4.0.4
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.