Blue background color remains for inputs, links etc, when panning inside iframes

RESOLVED FIXED in Firefox 16

Status

()

Firefox for Android
General
P3
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: Margaret)

Tracking

({testcase})

Trunk
Firefox 16
ARM
Android
testcase
Points:
---

Firefox Tracking Flags

(fennec11+)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
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
(Assignee)

Comment 4

6 years ago
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+
(Assignee)

Comment 5

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/a2d50843d2a5
Target Milestone: --- → Firefox 16

Comment 6

6 years ago
https://hg.mozilla.org/mozilla-central/rev/a2d50843d2a5
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.