Long-pressing on an iframe which doesn't have focus puts selection in unexpected place

NEW
Unassigned

Status

()

Core
Selection
a year ago
11 months ago

People

(Reporter: kats, Unassigned)

Tracking

(Blocks: 1 bug)

51 Branch
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox49 wontfix, firefox50 fix-optional, firefox51 affected, firefox52 wontfix)

Details

Attachments

(1 attachment)

On Fennec, or Windows e10s with touch:

1. Load a page like http://people.mozilla.org/~kgupta/gridframe.html which has an iframe
2. Tap outside the iframe to make sure the parent window has focus
3. Long-press inside the iframe (on some blank space) to bring up the text-selection carets

ER: text selection carets show up inside the iframe

AR: text selection carets show up outside the iframe

Note that in step 2 if you tap inside the iframe (on blank space) then the iframe gets focus and things work as expected. I believe what we need to do is give the iframe focus once we detect the long-press. Chrome seems to do this as well.
See Also: → bug 1304263
I thought this would be fixable by simply copying the code at [1] down into the eLongTap case, but that doesn't work.

After looking at the code some more I then thought that the problem was the AccessibleCaretEventHub schedules its internal long-tap injector when it receives the touchstart, but at that point the focus is still in the parent window. So the long-tap injector triggers a long-tap on the parent window, regardless of whether the focus changes later. But disabling the long-tap injector and using the eMouseLongTap event didn't fix the problem either. Still digging...

[1] http://searchfox.org/mozilla-central/rev/d1276b5b84e6cf7991c8e640b5e0ffffd54575a6/dom/ipc/TabChild.cpp#1781-1783
I think it might be related to how the EventHub is delivered events from nsPresShell. It looks like it always sends it from the focused presShell, or the top-level presShell. In this case we want it to go to the presShell that's under the finger which is only computed later in the code. I haven't yet confirmed.
Created attachment 8796680 [details] [diff] [review]
Hack

Indeed, that is the problem. A patch like the one attached, which passes positioned events to the AccessibleCaretEventHub of the presshell *after* hit-testing fixes this bug. It probably breaks other things, though. I'm not sure what the correct mechanism here is to fix this.
Unassigning since I'm not familiar enough with the intricacies of the AccessibleCaret event delivery timing to really tackle this.
Assignee: bugmail → nobody
On Windows this will affect 52 and up, but on Fennec it is already in release (48 and up).
status-firefox49: --- → wontfix
status-firefox50: --- → fix-optional
status-firefox51: --- → affected
status-firefox52: --- → affected
OS: Unspecified → Android
Hardware: Unspecified → All
I feel the patch in comment 3 makes some sense. However, after applying the patch, sometimes I cannot drag caret. 

Each PresShell owns an EventHub, and we should want to let the event hub under the finger to handle the event.  The event retargeting code [1] was from the very first implementation in bug 924692.  Morris, do you recall why we did [1]?

[1] http://searchfox.org/mozilla-central/rev/d1276b5b84e6cf7991c8e640b5e0ffffd54575a6/layout/base/nsPresShell.cpp#7341-7347
Flags: needinfo?(mtseng)
That because we want to active only one caret at the same time. Otherwise it might have multiple caret appeared on the screen.
Flags: needinfo?(mtseng)
Mass wontfix for bugs affecting firefox 52.
status-firefox52: affected → wontfix
You need to log in before you can comment on or make changes to this bug.