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.
over to margaret assuming this is related to the iframe event issues she's been working on
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.