Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Reporter
	Description • 9 years ago

[STR]
1. enable lock screen and screen reader
2. long press to focus on any element
3. press power key to turn off screen
4. press power key again to turn on screen

[EXPECTED RESULT]
lock screen is displayed with no highlight box on top of it

[ACTUAL RESULT]
highlight box is overlay on top of lock screen. (screenshot in attachment)

	Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Reporter
	Comment 1 • 9 years ago

The highlight box is a <div> on shell.html created by AccessFu.jsm [1], so the highlight box is always on top of any content in side system app iframe. For browser app on TV, the highlight box is also being displayed in front of browser chrome.

I'll suggest to the highlight box in content side directly, like what we did for displaying touch caret on B2G [2]. It can solve following issues:
1. display order: the highlight box is only on top of the element (or page) that focused.
2. visibility: the highlight box is only displayed while the focused element is visible.
3. position update performance: the position of highlight box is updated without the delay of IPC.

ni? eeejay about my proposal.

[1] https://dxr.mozilla.org/mozilla-central/source/accessible/jsat/AccessFu.jsm#528
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=924692

	Eitan Isaacson [:eeejay]
	Comment 2 • 9 years ago

I think it is important that the cursor not intermingle with content. Since we listen for mutation events, we don't want to be stuck in a loop of observations/highlight changes. That is why we have it in the chrome doc and not in the actual content right now.

I think what you are seeing is a bug that I would rather see fixed in having the cursor update when the lockscreen is engaged and get placed on something visible.

Generally, we do a lot to make sure that if elements go away, we update the cursor so we don't stay on a dead position.

This bug 1186459 may be relevant to this specific use case.

	Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Reporter
	Comment 3 • 9 years ago

(In reply to Eitan Isaacson [:eeejay] from comment #2)
> I think it is important that the cursor not intermingle with content. Since
> we listen for mutation events, we don't want to be stuck in a loop of
> observations/highlight changes. That is why we have it in the chrome doc and
> not in the actual content right now.
For touch caret they render the blue-drop-like caret handle with an anonymous DOM element. I think it will not create mutation events but I have to double check with the devs. It's more like injecting an extra layer directly in graphics system. You're concern might not exist if we take this approach.
> 
> I think what you are seeing is a bug that I would rather see fixed in having
> the cursor update when the lockscreen is engaged and get placed on something
> visible.
> 
> Generally, we do a lot to make sure that if elements go away, we update the
> cursor so we don't stay on a dead position.
> 
> This bug 1186459 may be relevant to this specific use case.
It might solve the lockscreen issue on b2g phone but not the issue on TV browser app. I know we can solve issues case by case but IMO this takes too much effort (both ENG and QA) for any app/UX introduced later. I'd like to see a systematic approach that solve this once and for all.