1069348 - devtools connect dialog could be "seen" through lockscreen with screen reader

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Eitan Isaacson [:eeejay]]

I wouldn't be surprised if it doesn't have exclusive visibility either.

Comment 1

[GitHub Autolander Bot]

Attachment: [gaia] yzen:bug-1069348 > mozilla-b2g:master

Comment 2

[Yura Zenevich [:yzen] (please use "needinfo")]

Comment on attachment 8582213 [details] [review]
[gaia] yzen:bug-1069348 > mozilla-b2g:master

Hi Alive, I have this WIP that helps with screen reader visibility issues around modal dialog component but I wanted to get your suggestions. 

It mostly working, and the hierarchy is handled well for modal dialogs, however the issue is around the visibility_manager. It currently does not take into account current top ui (calculated with the hierarchy manager) and I see a number of comments in visibility_manager about the need of using it.

I am trying to figure out what's the best way to do that and I'm guessing the best way forward, instead of checking for things like attentionWindowManager.hasActiveWindow, Service.locked etc we should see if what we want to show has higher priority than the current top ui/window from the hierarchy manager. This is however is a little bit complicated since the hierarchy manager handles window managers in some cases and the visibility_manager handles windows. Am I on the right track? Perhaps you have a better suggestion forward? thanks!

Comment 3

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Yura Zenevich [:yzen] from comment #2)
> Comment on attachment 8582213 [details] [review]
> [gaia] yzen:bug-1069348 > mozilla-b2g:master
> 
> Hi Alive, I have this WIP that helps with screen reader visibility issues
> around modal dialog component but I wanted to get your suggestions. 
> 
> It mostly working, and the hierarchy is handled well for modal dialogs,
> however the issue is around the visibility_manager. It currently does not
> take into account current top ui (calculated with the hierarchy manager) and
> I see a number of comments in visibility_manager about the need of using it.
> 
> I am trying to figure out what's the best way to do that and I'm guessing
> the best way forward, instead of checking for things like
> attentionWindowManager.hasActiveWindow, Service.locked etc we should see if
> what we want to show has higher priority than the current top ui/window from
> the hierarchy manager. This is however is a little bit complicated since the
> hierarchy manager handles window managers in some cases and the
> visibility_manager handles windows. Am I on the right track? Perhaps you
> have a better suggestion forward? thanks!

The design purpose of hierarchy manager is to replace visibility manager.
Maybe you could see Bug 1079748 for further detail.

In my plan, the functionality of visibility manager will be replaced by:
1. HierarchyManager will call setHierarchy(false) when any UI loses the top most focus.
2. If an UI which registers to HierarchyManager see setHierarchy is called with false, and if it's a window manager, it should call setVisible(false) to its current active window instance.
2.1. The same, if it's the dialog manager, it should call setVisible(false) or setVisibleForScreenReader(false) to its current active dialog instance.
3. If an UI gets top most focus, HierarchyManager will call setHierarchy(true) for it; then it should ask the active instance to setVisible(true) or setVisibleForScreenReader(true)

For long term, ModalDialog should be merged into SystemDialog, and then SystemDialogManager will do the favor for you.

I am not sure if this answers your question. If this bug is not an emergent issue to you, could you help to do it in the right way?

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8582213 [details] [review]
[gaia] yzen:bug-1069348 > mozilla-b2g:master

Cancelling at first before final implementation decision.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Shall we deprioritize this now?

Comment 6

[BMO Automation]

Firefox OS is not being worked on