1093755 - [Notifications] While notification tray is open, user can tap search bar and open the keyboard behind the tray

Status: VERIFIED FIXED

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

Description

[Robert Mead [:RobertM]]

Attachment: Flame2.1logcat.txt

Description:
While in an app, if you pull down the notification's tray and then tap right below the area where the search bar would be, the search bar and keyboard will open behind the notification's tray.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141104001202
2) Tap the 'Clock' app
3) Pull down the notification tray
4) Tap the upper left corner of device where the search bar is located
  
Actual:
The search bar and keyboard open behind the notification screen
  
Expected: 
Nothing should happen as long as the notification tray is open
  

Flame 2.1(319mb)(KitKat)(Shallow Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20141104001202
Gaia: 8b0cf889ae0d48a9eb7ecdcb9b67590de45cc5e5
Gecko: 388b03efe92d
Gonk: 
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

  
Repro frequency: 100%
See attached: logcat, video - http://youtu.be/DFh1RpdNKSQ

Comment 1

[Robert Mead [:RobertM]]

This issue DOES occur on Flame 2.2(319mb)

When in an app, if you pull down the notification tray and tap right below where the search bar is the keyboard will pop behind the notification tray.

Flame 2.2

Device: Flame 2.2(319mb)(KitKat)(Shallow Flash)
Build ID: 20141104040207
Gaia: 3c50520982560ccba301474d1ac43706138fc851
Gecko: 54d05732f29b
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


This issue does NOT occur on Flame 2.0(319mb) because this version has a different rocketbar UX compared to the later versions.

Flame 2.0

Device: Flame 2.0(319mb)(KitKat)(Shallow Flash)
BuildID: 20141104000201
Gaia: fe2167fa5314c7e71c143a590914cbf3771905a8
Gecko: 241e51806687
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Although it can be confusing to the user that rocketbar is being selected with the notification tray open, this issue does not seem severe enough to request a blocking nomination

Comment 3

[Corinne Innes [:CorinneI]]

Attachment: Notification.png

Issue DOES occur on Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)

Pre req: Have an update available for user device.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141113000201
2) From home screen tap the notification tray
3) Tap on available update
4) Tap the "Later" button
5) If bug does not occur on first try then repeat steps 2-4 
  
Actual:
Status bar goes black and home screen doesn't respond to touch input

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141113000201
Gaia: ab83632c92f9fc571b11d8468b6901cc4ed905c0
Gecko: e21bf45e6c44
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 4

[Corinne Innes [:CorinneI]]

Attachment: Notification issues.png

Issue still occurs on 2.2 but now requires different STR and results in other problems.

Steps:
1) Update a Flame device to BuildID:20141202040207
2) Open clock app (or any app with access to rocketbar)
3) Tap rocketbar
4) Quickly open the utility/notification tray
5) Tap "Built-in Keyboard" notification

Environmental variables:

Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141202040207
Gaia: 725685831f5336cf007e36d9a812aad689604695
Gecko: 2c9781c3e9b5
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Actual:
Multiple issues may be observed-
1. Status bar is removed for the notification tray
2. Status bar is also gone on the "Built-in Keyboard" selection page
3. Rocketbar will appear in the background collapsed with an expanded rocketbar in the foreground
4. Keyboard will replicate, and if dismissed, will leave behind a large black box

Youtube Link: https://www.youtube.com/watch?v=zuO82J5dCy4 (Sorry about the glare!)

Comment 5

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Nominating to block 2.2 on this due to the status bar not being visible when this issue occurs

Comment 6

[GitHub Autolander Bot]

Attachment: [PullReq] albertopq:1093755-utility-tray-rocketbar to mozilla-b2g:master

Comment 7

[Kevin Grandon :kgrandon]

Comment on attachment 8535561 [details] [review]
[PullReq] albertopq:1093755-utility-tray-rocketbar to mozilla-b2g:master

I feel that we should probably try to leverage the new hierarchy manager for this, but I need to spend some time digging in to figure out the best way to leverage it. Also adding Alive to this to see if that makes sense, and if he has suggestions.

Comment 8

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

Comment on attachment 8535561 [details] [review]
[PullReq] albertopq:1093755-utility-tray-rocketbar to mozilla-b2g:master

Sorry, but the problem seems to me is: we should not open the rocketbar when touching the search area while utility tray is opened. It is really instinctive.. how could the user know?

Is there a spec about this?

Comment 9

[Alberto Pastor [:albertopq]]

Alive, I think you are getting confused with https://bugzilla.mozilla.org/show_bug.cgi?id=1109539

The rocketbar shouldn't open when the utility tray is open (it is happening now because of a regression). what this bug is about is when opening the utility tray while the rocketbar is being displayed (quickly swipe down after clicking the rocketbar). How can we avoid that?

Comment 10

[Alberto Pastor [:albertopq]]

Re-reading the bug again I understand why you were confused. The STR was modified on comment #4 :)

Comment 11

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

(In reply to Alberto Pastor [:albertopq] from comment #9)
> Alive, I think you are getting confused with
> https://bugzilla.mozilla.org/show_bug.cgi?id=1109539
> 
> The rocketbar shouldn't open when the utility tray is open (it is happening
> now because of a regression). what this bug is about is when opening the
> utility tray while the rocketbar is being displayed (quickly swipe down
> after clicking the rocketbar). How can we avoid that?

Sorry, I read the video at comment 0 but it does not match with what you said.
The solution is not bad, but I wonder
* Is this expected by UX? What is blocking us to open the utility tray on rocketbar?
* Could you use Service.registerState('active') and Service.query('Rocketbar.active') in utility tray instead of using the event? It is much safer than the events.

Comment 12

[Kevin Grandon :kgrandon]

Comment on attachment 8535561 [details] [review]
[PullReq] albertopq:1093755-utility-tray-rocketbar to mozilla-b2g:master

I suppose we should try leveraging Service.registerState() like Alive said. Feel free to re-flag me or Alive after trying that. Thanks!

Comment 13

[Alberto Pastor [:albertopq]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #11)
> (In reply to Alberto Pastor [:albertopq] from comment #9)
> > Alive, I think you are getting confused with
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1109539
> > 
> > The rocketbar shouldn't open when the utility tray is open (it is happening
> > now because of a regression). what this bug is about is when opening the
> > utility tray while the rocketbar is being displayed (quickly swipe down
> > after clicking the rocketbar). How can we avoid that?
> 
> Sorry, I read the video at comment 0 but it does not match with what you
> said.
> The solution is not bad, but I wonder
> * Is this expected by UX? What is blocking us to open the utility tray on
> rocketbar?
> * Could you use Service.registerState('active') and
> Service.query('Rocketbar.active') in utility tray instead of using the
> event? It is much safer than the events.

Thanks :alive, the problem is that if we use Rocketbar.active, we miss the time between the global-search-request and when it get's active (the expand transition, basically). I don't like the solution either, but couldn't find a better way...

Comment 14

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

Comment on attachment 8535561 [details] [review]
[PullReq] albertopq:1093755-utility-tray-rocketbar to mozilla-b2g:master

I am removing the r-.

Alberto, I still wanna to hear how does UX say. I think utility tray should be access-able even when rocket-bar is active.
If UX agree that is what we should do, let's have a follow-up bug to re-enable it.

After watching video in comment 4, the problem here seems to me is:
The keyboard interaction of underlying rocketbar will affect the active app window size. This is totally wrong. We should fix it (in follow-up).

What do you think? Need your own opinion/idea/comment before I grant the patch.

Comment 15

[Alberto Pastor [:albertopq]]

Hi :alive. I was unable to reproduce the issue shown in the video (in comment #4). I do agree we need to fix that if that's still happening. 

Regarding the question if the utility tray should be actionable during the rocketbar, UX will need to answer that. Personally, I agree with you and I don't see why not, but it's just my opinion.
In case they think we need to enable the utility tray in the rocketbar, the bug I'm fixing with the patch is no longer valid. In case they still think that the utility tray shouldn't work on the rocketbar search, we'll need somehow avoid the handle being actionable during the expand transition of the rocketbar, and that's what my patch fixes.

So, let's wait for UX and also, :Corinnel, could you please recheck again if that's still happening and refine the STR in comment #4 in case it is? Thanks!

Comment 16

[Stephany Wilkes]

Flagging Rob on utility tray question, though this may be moot for 2.2.

Comment 17

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

(In reply to Alberto Pastor [:albertopq] from comment #15)
> Hi :alive. I was unable to reproduce the issue shown in the video (in
> comment #4). I do agree we need to fix that if that's still happening. 
> 
> Regarding the question if the utility tray should be actionable during the
> rocketbar, UX will need to answer that. Personally, I agree with you and I
> don't see why not, but it's just my opinion.
> In case they think we need to enable the utility tray in the rocketbar, the
> bug I'm fixing with the patch is no longer valid. In case they still think
> that the utility tray shouldn't work on the rocketbar search, we'll need
> somehow avoid the handle being actionable during the expand transition of
> the rocketbar, and that's what my patch fixes.
> 
> So, let's wait for UX and also, :Corinnel, could you please recheck again if
> that's still happening and refine the STR in comment #4 in case it is?
> Thanks!

Good, I re-think about the issue:
* We should not trigger rocketbar if utility tray is just active (The search bar should not be access-able)
* If the user taps the search bar and open the utility tray at the same time:
  We should just open rocketbar at background of utility tray, but do not focus this input.
  We could do |Service.request('focus', this);| in rocketbar.js when it is being enabled.
  HierarchyManager will take care about this request. If it sees utility tray is active, rocketbar will not be focused so no keyboard will be opened.

Comment 18

[Rob MacDonald [:robmac]]

Hi everyone... 

Thanks for flagging us. I talked with Francis and we agree users should be able to open the utility tray while the rocketbar is open. Opening the utility tray would immediately close search. Francis has added a note to the search app spec (https://mozilla.box.com/s/fhlmfa4xyooqpwaaaczc).

Also flagging Eric for visual considerations.

- Rob

Comment 19

[Eric Pang [:epang] UX]

(In reply to Rob MacDonald [:robmac] from comment #18)
> Hi everyone... 
> 
> Thanks for flagging us. I talked with Francis and we agree users should be
> able to open the utility tray while the rocketbar is open. Opening the
> utility tray would immediately close search. Francis has added a note to the
> search app spec (https://mozilla.box.com/s/fhlmfa4xyooqpwaaaczc).
> 
> Also flagging Eric for visual considerations.
> 
> - Rob

Thanks Rob, the search screen should close the same way it does when the close button is pressed.

Comment 20

[GitHub Autolander Bot]

Attachment: [PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

Comment 21

[GitHub Autolander Bot]

Attachment: [PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

Comment 22

[Alberto Pastor [:albertopq]]

Comment on attachment 8543986 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

Hey Rob, could you please review that is the expected behavior with this patch?
Kevin, could you review? the patch itself?

Thanks!

Comment 23

[Kevin Grandon :kgrandon]

Comment on attachment 8543986 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

Can you please add a unit test in rocketbar_test.js and re-flag me for review? Thanks!

Comment 24

[Alberto Pastor [:albertopq]]

Comment on attachment 8543986 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

Done!

Comment 25

[Kevin Grandon :kgrandon]

Comment on attachment 8543986 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

lgtm!

Comment 26

[Alberto Pastor [:albertopq]]

Comment on attachment 8543986 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

Forwarding to Eric

Comment 27

[Eric Pang [:epang] UX]

Comment on attachment 8543986 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

Francis and I took a look at the patch and we think it looks good.  I have a few reservations about the slight lag at the beginning of the transition but that shouldn't keep this patch from landing.  Great work, thanks for working this Alberto!

Comment 28

[GitHub Autolander Bot]

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/b58299a6b1d2d8c3224893cdc17faa21ddb09f03

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Is this something that should land on v2.1 as well? If so, please request Gaia v2.1 approval on it :)

Comment 30

[Alberto Pastor [:albertopq]]

Not sure if we want to fix it in 2.1. Gregor?

Comment 31

[Gregor Wagner [:gwagner]]

The devices team is driving 2.1. Putting on Kevins radar so he can add the right people for uplifting if needed.

Comment 32

[Josh Cheng [:josh]]

Triage:
Hi Vincent,
Kevin and Keven has approved to land this on 2.1.
Can you help to see whether the patch is able to land on 2.1? Thanks!

Comment 33

[Josh Cheng [:josh]]

Dear Alberto,
Could you please help to raise patch approval for landing on 2.1?
Thanks!

Comment 34

[Alberto Pastor [:albertopq]]

Hi! I'm afraid this caused a regression (Bug 1121707). Let me confirm that first. Thanks!

Comment 35

[Michael Henretty [:mikehenrty][:mhenretty]]

[Blocking Requested - why for this release]:

Hi Josh,

How important is this to fix for 2.1? The fix adds some risk as it caused bug 1121707 which we are not going to fix for 2.2. This means that in order to uplift this to 2.1 we have to also come up with a fix for bug 1121707 which looks non-trivial and will also add risk. Would you reconsider blocking 2.1?

Comment 36

[Josh Cheng [:josh]]

Hi Michael,
I think we can skip this patch for 2.1 base on your assessment until anyone has concern. 
Thank you!

Comment 37

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame 2.2 and Master.

Result: The search bar is not accessible when the notification tray is open on top of it.
 
Device: Flame 2.2 (319mb, full flash)
Build ID: 20150206002505
Gaia: a52999ce7f783177deb17e267bf003a53e6fde06
Gecko: 01446d5231ef
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37

Device: Flame Master (319mb, full flash)
Build ID: 20150206010204
Gaia: 94af4b42d2ace6c9f38f31de77240604fac68af1
Gecko: 7c5f187b65bf
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.