891688 - Defect - Caret selections not always appearing when tapping inside text areas embedded in iframes

Status: RESOLVED FIXED

(Firefox for Metro Graveyard :: Input, defect, P2)

Description

[Kamil Jozwiak [:kjozwiak]]

When tapping inside text area's, the caret selection monocles will not be consistent and only appear on every other tap.

Steps to reproduce the issue:

1) Open Firefox Metro
2) Go to https://developer.mozilla.org/en-US/docs/HTML/HTML_Elements/textarea#HTML_Content
3) Tap on the word "something" inside the text area where the "Write something here" message appears (caret monocle should appear)
4) Tap on the word "Write" inside the text area (caret monocle will not be displayed)
5) Tap on the word "here" inside the text area (caret monocle should appear)
6) Tap on the word "something" inside the text area (caret monocle will not be displayed)

Current Behavior:

- caret selection monocles only appear on every other tap and are not consistent

Expected Behavior:

- caret selection monocle should be displayed every single time a user taps anywhere inside the text area

Comment 1

[Jim Mathies [:jimm]]

confirmed, I can reproduce.

Comment 2

[Jim Mathies [:jimm]]

Attachment: simple text area

Comment 3

[Jim Mathies [:jimm]]

text area in iframe: http://www.mathies.com/mozilla/textareainiframe.html

Comment 4

[Jim Mathies [:jimm]]

This is caused by us getting sub-frame relative coords in our tap capture listener - 

http://mxr.mozilla.org/mozilla-central/source/browser/metro/base/content/helperui/SelectionHelperUI.js#809

which results in pointInTargetElement begin false here - 

http://mxr.mozilla.org/mozilla-central/source/browser/metro/base/content/helperui/SelectionHelperUI.js#820

so we shut down selection on every other tap.

Tricky bug to fix, _msgTarget is the parent browser, so the translation doesn't happen.

This is a pretty serious flaw when dealing with subframes, but I don't see a way to address it without breaking remote content compatibility.

Comment 5

[Jim Mathies [:jimm]]

What we could do here is detect that it's a subframe in SelectionHandler on set up and hand back coordinate offset info SelectionHelperUI can apply.

Comment 6

[Jim Mathies [:jimm]]

Attachment: wip

Comment 7

[Jim Mathies [:jimm]]

Attachment: wip

Comment 8

[Jim Mathies [:jimm]]

Attachment: patch

Comment 9

[Jim Mathies [:jimm]]

Attachment: patch + tests

Pushed to try. This test also pummels our FormHelper code pretty hard, which triggers a number of js errors in that module during the run. I'll file a follow up on that.

Comment 10

[Jim Mathies [:jimm]]

Comment on attachment 782521 [details] [diff] [review]
patch + tests

https://tbpl.mozilla.org/?tree=Try&showall=0&rev=4edf749c980f

Turned out that most of logic in the click handler could go away, the rest of the selection code has solidified up enough that it wasn't needed.

Comment 11

[Jim Mathies [:jimm]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/33b2ed1859e3

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/33b2ed1859e3

Comment 13

[Ed Morley [:emorley]]

Please land on fx-team now (see newsgroup post) - this unfortunately caused conflicts with metro landings on fx-team. Thank you :-)

Comment 14

[Ed Morley [:emorley]]

Sorry forgot the link:
https://mail.mozilla.org/pipermail/firefox-dev/2013-July/000618.html

Comment 15

[Samvedana (:Samvedana)]

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130815030203
Built from http://hg.mozilla.org/mozilla-central/rev/a8daa428ccbc

WFM
Tested on windows 8 using latest nightly for iteration-12. Followed steps provided in comment0 and got expected result.