Created attachment 589493 [details] testcase See testcase, steps to reproduce: - Make a swipe movement over one of the iframes Expected result: - Content becomes (perhaps) for a short while blue, then is white again Actual result: - Content stays light blue (which happens when content like links, text inputs) are css :active when tapped upon. Tested on the LG Optimus Black on Android 2.2.2 in portrait mode. I guess this might be related to bug 719019.
Created attachment 589495 [details] testcase2, using inputs This bug can also be seen in XUL Fennec, btw. Also, long tap -> Context Menu -> Paste, then the input in the iframe still stays blue.
Yeah, it does look related to bug 719019/bug 716863 in that some of the events go to the iframe and some do not.
Assignee: nobody → bugmail.mozilla
tracking-fennec: --- → ?
See Also: → bug 716863
over to margaret assuming this is related to the iframe event issues she's been working on
Assignee: bugmail.mozilla → margaret.leibovic
tracking-fennec: ? → 11+
Priority: -- → P3
Created attachment 632718 [details] [diff] [review] patch A lot has changed since this bug was filed, but I think this patch fixes the problem. In _cancelTapHighlight, we're trying to remove the active state on an element by setting the active state on the top-level document. However, this does not affect the active state set on elements in iframes. To fix that, we need to set the active state on that element's owner document. I found that with this change, it seems like we remove the highlight too quickly, maybe exposing a problem with how soon we call _cancelTapHighlight, but I'm not sure what the expected behavior is here.
Attachment #632718 - Flags: review?(wjohnston)
Attachment #632718 - Flags: review?(wjohnston) → review+
Target Milestone: --- → Firefox 16
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.