1194106 - [Homescreen]Launch any one app, app will appear around dotted box.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[zouyi(Leave from Mozilla)]

[1.Description]:
[Flame KK v2.5]&[Aries KK v2.5][Homescreen]When user wants to invoke an app, the contacts will appear around dotted box. Tap home button, contacts also will appear around dotted box.
Found time:01:45.
See attachment:logcat_0145.txt, Flame KK v2.5.3gp.

[2.Testing Steps]: 
1.Tap any icon on homescreen.ex:contacts.
**Contacts will appear around dotted box, and then contacts will be launched.
2.Tap home button .

[3.Expected Result]: 
2.Contacts won't appear around dotted box.

[4.Actual Result]: 
2. Contacts will appear around dotted box.

[5.Reproduction build]: 
Device: Flame KK 2.5(Affected)
Build ID               20150812150204
Gaia Revision          52f3ea58df38e5427f6afeb636bc6ad01d24022f
Gaia Date              2015-08-12 16:40:43
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/cf932fc931dcd19f425934db79bec641ebe2a8a9
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150812.182303
Firmware Date          Wed Aug 12 18:23:12 EDT 2015
Bootloader             L1TC000118D0

Device: Aries KK 2.5(Affected)
Build ID               20150812230643
Gaia Revision          52f3ea58df38e5427f6afeb636bc6ad01d24022f
Gaia Date              2015-08-12 16:40:43
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/7649ffe28b67aa2dad0f67ea01500c0ff91b2bac
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150812.222959
Firmware Date          Wed Aug 12 22:30:07 UTC 2015
Bootloader             s1

Device: Flame KK 2.2(Unaffected)
Build ID               20150812032504
Gaia Revision          102f1299e9eafe3760e1deb44d556b5c4f36b5af
Gaia Date              2015-08-06 20:46:56
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/9295034c0ee3
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150812.065135
Firmware Date          Wed Aug 12 06:51:47 EDT 2015
Bootloader             L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free test

[8.Note]
Around dotted box will be hid after tap home button if we launch smart collections.

Comment 1

[zouyi(Leave from Mozilla)]

FlameKK 2.2&2.5 Base Image：v18d v4

Comment 2

[zouyi(Leave from Mozilla)]

Attachment: bug log: logcat_0145.txt

Comment 3

[zouyi(Leave from Mozilla)]

Attachment: Flame KK v2.5.3gp

Comment 4

[William Hsu [:whsu]]

UI regression bug. Request for improvement.

Comment 5

[Martin Shuman [:Marty]]

This issue appears to be caused by either:
Bug 1193018 - [Accessibility] Improve accessibility for non-natively-focusable controls.
or
Bug 1174727 - Add new homescreen prototype to main Gaia repository

B2G-inbound Regression Window

Last Working:
Environmental Variables:
Device: Flame 2.5
BuildID: 20150812040410
Gaia: 6fef72357971934c8774578044ea7a442be3a75d
Gecko: 54b0d7960113e35d4b202cb264a51becae30dcdb
Version: 43.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

First Broken:
Environmental Variables:
Device: Flame 2.5
BuildID: 20150812075909
Gaia: c0aef6d09c9954204ce8824172c9ed8b9b35be19
Gecko: 9b246bfabcec47316373a5700ebe29a7005a2305
Version: 43.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Last Working gaia / First Broken gecko - Issue does NOT reproduce
Gaia: 6fef72357971934c8774578044ea7a442be3a75d
Gecko: 9b246bfabcec47316373a5700ebe29a7005a2305

First Broken gaia / Last Working gecko - Issue DOES reproduce
Gaia: c0aef6d09c9954204ce8824172c9ed8b9b35be19
Gecko: 54b0d7960113e35d4b202cb264a51becae30dcdb

Gaia Pushlog:
https://github.com/mozilla-b2g/gaia/compare/6fef72357971934c8774578044ea7a442be3a75d...c0aef6d09c9954204ce8824172c9ed8b9b35be19

Comment 6

[KTucker [:KTucker][Inactive 3/4/2016]]

Yura and Chris, can you take a look at this please? Either the landing for bug Bug 1193018 or Bug 1174727 caused this to occur. We are 100 % unsure which one in the pushlog caused this.

Comment 7

[Chris Lord [:cwiiis]]

Definitely not caused by bug 1174727.

Comment 8

[GitHub Autolander Bot]

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

Comment 9

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

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

With tabindex present, we not need to ensure that the outline is not visible when tapping.

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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

I don't think I should review this. I am not familiar with gaia grid. Feel free to find the owner of the major consuming app (Home screen?).

Comment 11

[Chris Lord [:cwiiis]]

I would be the right reviewer for this, but I have a couple of questions;

Where does this outline style originally come from? Why has it been changed, and does this affect other applications?

I'm reluctant to fix it here if this will break the appearance of things elsewhere as well, rather than fixing it at the source.

Comment 12

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

(In reply to Chris Lord [:cwiiis] from comment #11)
> I would be the right reviewer for this, but I have a couple of questions;
> 
> Where does this outline style originally come from? Why has it been changed,
> and does this affect other applications?
> 
> I'm reluctant to fix it here if this will break the appearance of things
> elsewhere as well, rather than fixing it at the source.

So the original style is actually a browser default. Tabbable elements get the dotted outline by default (see most websites via firefox).

Comment 13

[Chris Lord [:cwiiis]]

(In reply to Yura Zenevich [:yzen] from comment #12)
> (In reply to Chris Lord [:cwiiis] from comment #11)
> > I would be the right reviewer for this, but I have a couple of questions;
> > 
> > Where does this outline style originally come from? Why has it been changed,
> > and does this affect other applications?
> > 
> > I'm reluctant to fix it here if this will break the appearance of things
> > elsewhere as well, rather than fixing it at the source.
> 
> So the original style is actually a browser default. Tabbable elements get
> the dotted outline by default (see most websites via firefox).

Right, this isn't something we want when a user taps a tabbable element though, so we need to fix this at the source, not just in homescreen - this will likely affect many other areas too?

Comment 14

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

(In reply to Chris Lord [:cwiiis] from comment #13)
> (In reply to Yura Zenevich [:yzen] from comment #12)
> > (In reply to Chris Lord [:cwiiis] from comment #11)
> > > I would be the right reviewer for this, but I have a couple of questions;
> > > 
> > > Where does this outline style originally come from? Why has it been changed,
> > > and does this affect other applications?
> > > 
> > > I'm reluctant to fix it here if this will break the appearance of things
> > > elsewhere as well, rather than fixing it at the source.
> > 
> > So the original style is actually a browser default. Tabbable elements get
> > the dotted outline by default (see most websites via firefox).
> 
> Right, this isn't something we want when a user taps a tabbable element
> though, so we need to fix this at the source, not just in homescreen - this
> will likely affect many other areas too?

Hi Chris, sorry did not catch you earlier in IRC. 

I was thinking more about the issue and I think disabling outline on tap would be creating a general accessibility barrier when alternatives are not provided. We simply can not guarantee that developers will provide an alternative :focus, :active styling.

I realize that it might seem counter intuitive that the outline is present when you tap on an element, but it simply follows the focus on the page (e.g. we get both focus and click) and the current active element. A user with visual or/and cognitive disability will loose the ability to identify what was the last focused item (again, if no alternative provided). In most cases, unfortunately, web authors choose to no have the outline, but then do not provide any alternative.

This is why I think it might be best not to disable the default outline behavior. After all we already implement alternatives (active and focused styling) in places where we also disable the outline (tabs, most links, etc).

Let me know.

Comment 15

[Chris Lord [:cwiiis]]

(In reply to Yura Zenevich [:yzen] from comment #14)
> (In reply to Chris Lord [:cwiiis] from comment #13)
> > (In reply to Yura Zenevich [:yzen] from comment #12)
> > > (In reply to Chris Lord [:cwiiis] from comment #11)
> > > > I would be the right reviewer for this, but I have a couple of questions;
> > > > 
> > > > Where does this outline style originally come from? Why has it been changed,
> > > > and does this affect other applications?
> > > > 
> > > > I'm reluctant to fix it here if this will break the appearance of things
> > > > elsewhere as well, rather than fixing it at the source.
> > > 
> > > So the original style is actually a browser default. Tabbable elements get
> > > the dotted outline by default (see most websites via firefox).
> > 
> > Right, this isn't something we want when a user taps a tabbable element
> > though, so we need to fix this at the source, not just in homescreen - this
> > will likely affect many other areas too?
> 
> Hi Chris, sorry did not catch you earlier in IRC. 
> 
> I was thinking more about the issue and I think disabling outline on tap
> would be creating a general accessibility barrier when alternatives are not
> provided. We simply can not guarantee that developers will provide an
> alternative :focus, :active styling.
> 
> I realize that it might seem counter intuitive that the outline is present
> when you tap on an element, but it simply follows the focus on the page
> (e.g. we get both focus and click) and the current active element. A user
> with visual or/and cognitive disability will loose the ability to identify
> what was the last focused item (again, if no alternative provided). In most
> cases, unfortunately, web authors choose to no have the outline, but then do
> not provide any alternative.
> 
> This is why I think it might be best not to disable the default outline
> behavior. After all we already implement alternatives (active and focused
> styling) in places where we also disable the outline (tabs, most links, etc).
> 
> Let me know.

Do we have the idea of accessibility features being enabled? I'd have thought there must be some way we can track that a user has only interacted with the device via touch and not draw these outlines.

I worry that an author might see one of these outlines, think 'How do I get rid of that?', debug it and track it down to them adding tabIndex, or role, or whatever and just remove that instead of adding outline: 0.

Also, is that even the right solution? If we're adding outline: 0, surely we're back to square one and we may as well not be drawing them by default?

I'll r+ the change, but I think there are a lot of unanswered questions here and I question the point of default behaviour if we just override it everywhere.

Comment 17

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

So there are several things here:

(In reply to Chris Lord [:cwiiis] from comment #15)
> (In reply to Yura Zenevich [:yzen] from comment #14)
> > (In reply to Chris Lord [:cwiiis] from comment #13)
> > > (In reply to Yura Zenevich [:yzen] from comment #12)
> > > > (In reply to Chris Lord [:cwiiis] from comment #11)
> > > > > I would be the right reviewer for this, but I have a couple of questions;
> > > > > 
> > > > > Where does this outline style originally come from? Why has it been changed,
> > > > > and does this affect other applications?
> > > > > 
> > > > > I'm reluctant to fix it here if this will break the appearance of things
> > > > > elsewhere as well, rather than fixing it at the source.
> > > > 
> > > > So the original style is actually a browser default. Tabbable elements get
> > > > the dotted outline by default (see most websites via firefox).
> > > 
> > > Right, this isn't something we want when a user taps a tabbable element
> > > though, so we need to fix this at the source, not just in homescreen - this
> > > will likely affect many other areas too?
> > 
> > Hi Chris, sorry did not catch you earlier in IRC. 
> > 
> > I was thinking more about the issue and I think disabling outline on tap
> > would be creating a general accessibility barrier when alternatives are not
> > provided. We simply can not guarantee that developers will provide an
> > alternative :focus, :active styling.
> > 
> > I realize that it might seem counter intuitive that the outline is present
> > when you tap on an element, but it simply follows the focus on the page
> > (e.g. we get both focus and click) and the current active element. A user
> > with visual or/and cognitive disability will loose the ability to identify
> > what was the last focused item (again, if no alternative provided). In most
> > cases, unfortunately, web authors choose to no have the outline, but then do
> > not provide any alternative.
> > 
> > This is why I think it might be best not to disable the default outline
> > behavior. After all we already implement alternatives (active and focused
> > styling) in places where we also disable the outline (tabs, most links, etc).
> > 
> > Let me know.
> 
> Do we have the idea of accessibility features being enabled? I'd have
> thought there must be some way we can track that a user has only interacted
> with the device via touch and not draw these outlines.

This is a bit hard to answer. For example when we have screen reader enabled we do not care about the styling at all because we draw our own outline.

Keyboard accessibility requires different solutions which this bug is more relevant to but we don't yet have a good plan for that (UX/UI needs to be involved, I believe).

Making things accessibly for other types of disabilities or assistive technologies might actually need the outline even if interaction happens via touch (sort of what I mentioned in comment 15).

> 
> I worry that an author might see one of these outlines, think 'How do I get
> rid of that?', debug it and track it down to them adding tabIndex, or role,
> or whatever and just remove that instead of adding outline: 0.
True that's one way to do it but I noticed that most of the help pages about dealing with this actually mention the outline, and better ones say what to do in leu of that styling missing (for example https://css-tricks.com/removing-the-dotted-outline/)
> 
> Also, is that even the right solution? If we're adding outline: 0, surely
> we're back to square one and we may as well not be drawing them by default?

Yes that is a different issue however, and definitely requires some UI/UX. At least for the screen reader users we draw an outline that is separate from CSS but we need indeed need to think about the keyboard, especially in gaia-component context.

> 
> I'll r+ the change, 

Thanks this is mainly to bootstrap our a11y integration testing tools and I realize this is not a complete solution, I'll open and will track specific bugs about it. 

> but I think there are a lot of unanswered questions here
> and I question the point of default behaviour if we just override it
> everywhere.
Indeed we do, but I would not generalize to all FirefoxOS app developers. Essentially by initially opting for removing the outline and not providing alternatives we discarded keyboards which might not be the case in the near future.

Comment 18

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

https://github.com/mozilla-b2g/gaia/commit/e35cd39563ad2043ba9fca1d5edb38845e5098e0

Comment 19

[Chris Lord [:cwiiis]]

Thanks for addressing my comment Yura, I think I have a better understanding of the situation now :)

Comment 20

[Shally Li（leave from Mozilla）]

This bug has been verified as "pass" on the latest build of Flame KK 2.5 and Aires KK 2.5 by the STR in comment 0.

Actual results: App/collection icon is not surrounded with dotted box in homescreen.
See attachment: verified_FlameKK_v2.5.3gp
Reproduce rate: 0/15


Device: Flame KK 2.5 (Pass)
Build ID               20150818150207
Gaia Revision          507ba38fb64b27f87d11f4104dfcc58448e12b1a
Gaia Date              2015-08-18 10:50:12
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/2c272af993c23e803f6ea7798a812b0c8abfad4d
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150818.184156
Firmware Date          Tue Aug 18 18:42:07 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK 2.5(Pass)
Build ID               20150818233027
Gaia Revision          1e1197e0e8e64307aa382ffba4711d1c661de7ca
Gaia Date              2015-08-18 16:54:35
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/88e1d293ffa9faf065b2a944c94a2705aabf1fb9
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150818.225517
Firmware Date          Tue Aug 18 22:55:24 UTC 2015
Bootloader             s1

Comment 21

[Shally Li（leave from Mozilla）]

Attachment: verified_FlameKK_v2.5.3gp