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.

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?

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.

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.

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