Closed Bug 779096 Opened 12 years ago Closed 12 years ago

Yellow Outline Appearing Within Web Pages After Clicking Content

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox16 affected, firefox17 affected, firefox18 verified, firefox19 verified)

VERIFIED FIXED
Firefox 18
Tracking Status
firefox16 --- affected
firefox17 --- affected
firefox18 --- verified
firefox19 --- verified

People

(Reporter: tech4pwd, Assigned: eeejay)

References

()

Details

(Keywords: access)

Attachments

(15 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20120730030540

Steps to reproduce:

I'll upload screenshots as I really don't know how they're caused.
CC'ing Wesj as mentioned on IRC
OS: Windows 7 → Android
Hardware: x86 → ARM
See Also: → 772502
Steps to reproduce?
(In reply to Aaron Train [:aaronmt] from comment #9)
> Steps to reproduce?

I'm unsure. It's something I see so regularly, I'm unable to pin it down to a specific set of actions. Given the regularity of these appearing, I assumed there was a bug filed for it already. In fact, I was sure I saw a bug for this issue filed previously, but no one on IRC knew where of one and WesJ pointed me to the bug linked above. I said I'd file a followup, hence why I took a slew of screenshots. Sorry, this is like the worst bug filing ever. I can tell you that certain text boxes generally leave the outline behind, as do certain DIVs.
heh. not worst bug filing ever. good to have tracking bugs even if we aren't sure what causes them.

just to be sure, do you have any extensions installed? also device type might also help since I don't see this on mine.
I'm running an unrooted HTC One X (Endervoru/International Version). Running HTC Sense 4.0 and Android 4.0.3. The only extension I have installed is Ad Block Plus.
After spending several minutes poking around GSMarena with Nightly + ABP and a Sprint HTC One X I have yet to hit this issue.
Could the problem be something to do with Swiftkey 3 and Fennec not playing nicely together? I know it's not device dependent due to the fact it happened on my Incredible S. I can also say that it's not ROM dependent due to the fact that Incredible S was running CyanogenMod 7.x (Android 2.3.x) and the One X is running Sense 4 (Android 4.0.3).
Do you have 'Enhance Web Accessibility' turned on under Android Accessibility settings? If so, can you try disabling and reporting back.
I don't even have that option.
I'm seeing this too actually!

* adb shell am start -a android.intent.action.VIEW -n org.mozilla.fennec/.App -d http://google.com
* adb shell am start -a android.intent.action.VIEW -n org.mozilla.fennec/.App -d http://facebook.com
* adb shell am start -a android.intent.action.VIEW -n org.mozilla.fennec/.App -d http://youtube.com
* adb shell am start -a android.intent.action.VIEW -n org.mozilla.fennec/.App -d http://twitter.com
--
Nightly/Aurora (08/01), Galaxy Nexus (Android 4.1.1)
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
(In reply to Aaron Train [:aaronmt] from comment #23)
> Reason I asked, I found this thread with what looks like this
> http://forum.xda-developers.com/showthread.
> php?s=59c107c4088df96fc4d32710377cc44b&t=1608868&page=2

Definitely don't have that option. It's possible that it's on and Sense 4 doesn't expose the preference.
Just added the comparison that Aaron done as that shows the problem on ~25 screenshots.
tracking-fennec: ? → 15+
tracking-fennec: 15+ → 16+
I have no idea how to reproduce this manually but with my recent automated run this tends to happen all the time.

See a whole slew of screenshots where this is happening http://people.mozilla.com/~atrain/webapps/app-screenshots/
I see this most of the time. Like 8/10 that I click something within the browser. It's horrid.
Is this the same as bug 788379?  If so, it's easy to reproduce on the site mentioned there (happens every time).
As you can see from all of the screenshots and linked screenies above, for some people it's part and parcel of their browsing experience, while for others, it is yet to appear. Sadly unless the devs can reproduce it, it's hard for them to isolate the problem and fix it. All test cases and screenshots are greatly appreciated.
Noted in bug 768182

> Possible regression window for this issue is:

> good build:
> 2012/06/06

> bad build 
> 2012/06/07

> possible push-log:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6338a8988917&tochange=7e4c2abb9fc9
Is this maybe related to 773240 ? Screenshots look similar.

It happens on my Galaxy S2, Android 4.0.4. In nightly 18.0a1 20012-09-26 and release 15.0.1. I just load page, select input/link and the orange border appears - highlighting the input/link.

It lags behind when scrolling/zooming and often it stays in one place and doesn't follow input field/link. Will post screenshot.
I don't have 'Enhance Web Accessibility' turned on under Android Accessibility. There is no such option on GS2. Tried with Swift Key 3, Swipe and default Samsung keyboard - no difference.
I would also add, that the orange box is very annoying even when it does follow the input. I wouldn't mind if it disappeared completely :-)
Petr, thanks for the input. Do you have consistent steps to reproduce to try and help the developers here? For example, which page are you loading and is it from a bookmark or directly by entering an address? Which links are you selecting too. It seems something is triggering this but we're not exactly sure what.
Hi Aaron, I have consistent steps to reproduce it in nightly it really happens every time:

1. open firefox 
2. go to www.google.cz (can't go to google.com, I get redirected to google.cz anyway)
3. touch inside the search input box
4. orange box appears around the input box and stays fixed in one place on the screen even when scrolling the page

This really happens on any page with input elements (at least pages I tried), so it's not limited to google search. The outline also appears around buttons and links and sometimes remains on screen after loading target page. It looks to me as if it's independent from the page on which it first appears. 

I have noticed, that in recent Firefox Android release it behaves differently. 
The steps to reproduce the behavior are exactly the same, but the yellow/orange box stays fixed on screen only during scrolling, then after lifting my finger it jumps to input location. Sometimes it doesn't fit exactly around the input, but it tries to follow it :-)

I can (and gladly try to) test anything you need. I'am software developer (C++/Java/JavaScript/...) myself. I can even try to debug it, but my experience with Android development is still limited ;-) I tried some C++ with Android NDK, but just one small test app. And tried Firefox debuggin only once and it was on Windows (wow, it's 9 years ago :-) https://bugzilla.mozilla.org/show_bug.cgi?id=213282)
Even with those steps on the same device, I was not able to reproduce :(
I tried older nightly builds and I can confirm, that the outline first appears in 2012-06-07 nightly.

16.0a1 2012-06-05 - nothing
16.0a1 2012-06-06 - nothing
16.0a1 2012-06-07 - yellow outline 
16.0a1 2012-06-27 - yellow outline
16.0a1 2012-07-15 - yellow outline
18.0a1 2012-10-01 - yellow outline
I did some research and there were some Accessibility changes around in early 16.0a1 that probably caused this. I think the yellow outline is drawn by Firefox accesibility component (explore by touch, or something similiar). I don't have accessibility enabled on my device, but today I've noticed, that the Missed It app (https://play.google.com/store/apps/details?id=net.igecelabs.android.MissedIt) needed to be enabled under accessibility system settings in order to read unread message counts:

"Missed It! must be enabled as an Accessibility Service to be able to receive application notifications ('Settings » Accessibility » Accessibility services')"

When enabled, firefox probably detects that something is enabled under accessibility settings and shows the virtual cursor (another issue is the placement of the cursor, which is wrong). If I disable Missed It, the yellow outline disappears (but I can't get notofications from Missed It :-(

Hope this helps.
That's exactly what I figured.

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoAccessibility.java

Bug 764119 , added a preference: 'accessibility.accessfu.explorebytouch'. In about:config, when tweaked from 2, to perhaps 0, does the issue go away?
Blocks: 766779
Keywords: access
Setting 'accessibility.accessfu.explorebytouch' to 0 (or 1) doesn't affect the outline, it's still there (I did restart the browser - terminated it from the task manager). Setting 'accesibility.accessfu.activate' from 2 to 0, disables it (without restart).
Paul can you confirm comment 43 results?(In reply to Petr Kures from comment #41)

> "Missed It! must be enabled as an Accessibility Service to be able to
> receive application notifications ('Settings » Accessibility » Accessibility
> services')"

I sure hope sure this doesn't become a common practice for android apps that don't require full blown accessibility.
Maybe there is some other generic way for them to monitor all notifications, but I guess there isn't so they used this. I don't exactly like it either, but it was the only way I could get this info on my lock screen :-) I think maybe Firefox could show the virtual cursor only when needed... when explore by touch is enabled ? Don't know if this is possible, but other browsers/apps don't show any virtual cursors when Missed It is enabled under Accessibility.  Maybe they are detecting accessibility service type or showing some kind of visual feedback only when explore by touch is enabled.

I can disable accesibility.accessfu.activate for now, but it's only a workaround.

Quick search in Play store  shows other apps that require this - for example 
Voice Notify. It has the same requirement and reads notifications aloud, but I doubt the user would like to see the outline around input boxes in Firefox ;-)

Maybe stupid question, but ... What is the reason Firefox shows the virtual cursor ?
This is not related to explore by touch, but it is an AccessFu issue. What is happening is when you click on a link, it receives keyboard focus and AccessFu highlights and announces it.

This could be resolved by blacklisting non a11y a11y services. With 2.2+ you call
AccessibilityManager.getAccessibilityServiceList()
In 4.0+ you call
AccessibilityManager.getInstalledAccessibilityServiceList
No longer blocks: 766779
I've set this to 0 and haven't seen a yellow outline yet.
bug 768182 has a regression range.  Not sure why it was closed in favor of this one.
(In reply to Paul [sabret00the] from comment #47)
> I've set this to 0 and haven't seen a yellow outline yet.

Set accesibility.accessfu.activate to 1 to see the outline.
I may have said 0 was a success prematurely as I saw the yellow outline this morning. I'll be testing on 1 for a couple hours to see what happens.
Had a bit of a test,its still there with 1. Will test zero again tomorrow.
Comment on attachment 668227 [details] [diff] [review]
Add whitelist for supported accessibility services.

Review of attachment 668227 [details] [diff] [review]:
-----------------------------------------------------------------

So, if any white listed a11y services are running we enable it? Is that what you really want? It almost seems like you want to disable it unless all running a11y services are whitelisted. Would that wind up being a problem?

::: mobile/android/base/GeckoAccessibility.java
@@ +32,5 @@
>  
>      private static JSONObject mEventMessage = null;
>      private static AccessibilityNodeInfo mVirtualCursorNode = null;
>  
> +    private static final HashSet<String> ServiceWhitelist =

sServiceWhitelist

While your here, mEventMessage and mVirtualCursorNode should be sEventMessage and sVirtualCursorNode. Please fix those.
Attachment #668227 - Flags: review?(blassey.bugs) → review+
(In reply to Brad Lassey [:blassey] from comment #53)
> Comment on attachment 668227 [details] [diff] [review]
> Add whitelist for supported accessibility services.
> 
> Review of attachment 668227 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> So, if any white listed a11y services are running we enable it? Is that what
> you really want? It almost seems like you want to disable it unless all
> running a11y services are whitelisted. Would that wind up being a problem?
> 

Not sure I follow. If accessibility is enabled AND any of the whitelisted services are running, start a11y mode.

This is to prevent the case above where non-a11y related apps bake up an a11y service so they could do things like announce notifications.
the question is, if these fake a11y apps do exist do we still want to start a11y mode?
(In reply to Brad Lassey [:blassey] from comment #55)
> the question is, if these fake a11y apps do exist do we still want to start
> a11y mode?

If they are running alongside a legit whitelisted service, yes.
Comment on attachment 668227 [details] [diff] [review]
Add whitelist for supported accessibility services.

Review of attachment 668227 [details] [diff] [review]:
-----------------------------------------------------------------

So, if any white listed a11y services are running we enable it? Is that what you really want? It almost seems like you want to disable it unless all running a11y services are whitelisted. Would that wind up being a problem?

::: mobile/android/base/GeckoAccessibility.java
@@ +32,5 @@
>  
>      private static JSONObject mEventMessage = null;
>      private static AccessibilityNodeInfo mVirtualCursorNode = null;
>  
> +    private static final HashSet<String> ServiceWhitelist =

sServiceWhitelist

While your here, mEventMessage and mVirtualCursorNode should be sEventMessage and sVirtualCursorNode. Please fix those.
(In reply to Paul [sabret00the] from comment #52)
> Had a bit of a test,its still there with 1. Will test zero again tomorrow.

1 made it worst I feel.
You should enable it if at least one whitelisted service is enabled IMHO. That's what the patch does.
https://hg.mozilla.org/mozilla-central/rev/b8b44407bfe6
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
I cannot reproduce this issue on the latest Nightly build on any of google.com, gsmarena or bugzilla sites. Closing bug as verified fixed on:

Firefox 19.0a1 (2012-10-10)
Device: Galaxy Note
OS: Android 4.0.4
Status: RESOLVED → VERIFIED
Apologies, I should've come in and said the problem appeared to be gone with the landing of this. That said, there was the crash-happy 24hrs that presented proper testing.
Can I nominate for beta and aurora?
This is on Aurora (mozilla-18), and can ride the trains.
tracking-fennec: 16+ → ---
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: