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

VERIFIED FIXED in Firefox OS v2.2

Status

Firefox OS
Gaia::System::Window Mgmt
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: RobertM, Assigned: albertopq)

Tracking

unspecified
2.2 S3 (9jan)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.0 wontfix, b2g-v2.0M wontfix, b2g-v2.1 wontfix, b2g-v2.1S wontfix, b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [2.1-exploratory-3][systemsfe], URL)

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

4 years ago
Created attachment 8516856 [details]
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
(Reporter)

Comment 1

4 years ago
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
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
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
Created attachment 8522485 [details]
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
Flags: needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-v2.0: --- → affected
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][systemsfe]
Created attachment 8531380 [details]
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!)
Flags: needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Nominating to block 2.2 on this due to the status bar not being visible when this issue occurs
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
(Assignee)

Updated

4 years ago
Assignee: nobody → apastor
Created attachment 8535561 [details] [review]
[PullReq] albertopq:1093755-utility-tray-rocketbar to mozilla-b2g:master
(Assignee)

Updated

4 years ago
Attachment #8535561 - Flags: review?(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.
Attachment #8535561 - Flags: review?(alive)
blocking-b2g: 2.2? → 2.2+
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?
Flags: needinfo?(firefoxos-ux-bugzilla)
Attachment #8535561 - Flags: review?(alive) → review-
(Assignee)

Comment 9

4 years ago
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?
Flags: needinfo?(alive)
(Assignee)

Comment 10

4 years ago
Re-reading the bug again I understand why you were confused. The STR was modified on comment #4 :)
(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 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!
Attachment #8535561 - Flags: review?(kgrandon)
(Assignee)

Comment 13

4 years ago
(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 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.
Flags: needinfo?(alive) → needinfo?(apastor)
Attachment #8535561 - Flags: review-
(Assignee)

Comment 15

4 years ago
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!
Flags: needinfo?(apastor) → needinfo?(cinnes)

Comment 16

4 years ago
Flagging Rob on utility tray question, though this may be moot for 2.2.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(rmacdonald)
(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.
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
Flags: needinfo?(rmacdonald) → needinfo?(epang)

Updated

4 years ago
Blocks: 1114945
(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.
Flags: needinfo?(epang)
Created attachment 8543985 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master
Created attachment 8543986 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master
(Assignee)

Updated

3 years ago
Attachment #8535561 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Attachment #8543985 - Attachment is obsolete: true
(Assignee)

Comment 22

3 years ago
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!
Attachment #8543986 - Flags: ui-review?(rmacdonald)
Attachment #8543986 - Flags: review?(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!
Attachment #8543986 - Flags: review?(kgrandon)
(Assignee)

Comment 24

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

Done!
Attachment #8543986 - Flags: review?(kgrandon)
Comment on attachment 8543986 [details] [review]
[PullReq] albertopq:1093755-rocketbar-tray to mozilla-b2g:master

lgtm!
Attachment #8543986 - Flags: review?(kgrandon) → review+
(Assignee)

Comment 26

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

Forwarding to Eric
Attachment #8543986 - Flags: ui-review?(rmacdonald) → ui-review?(epang)
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!
Attachment #8543986 - Flags: ui-review?(epang) → ui-review+
(Assignee)

Updated

3 years ago
Keywords: checkin-needed

Updated

3 years ago
Keywords: checkin-needed

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Is this something that should land on v2.1 as well? If so, please request Gaia v2.1 approval on it :)
status-b2g-v2.2: affected → fixed
Flags: needinfo?(apastor)
Target Milestone: --- → 2.2 S3 (9jan)
(Assignee)

Comment 30

3 years ago
Not sure if we want to fix it in 2.1. Gregor?
Flags: needinfo?(apastor) → needinfo?(anygregor)
The devices team is driving 2.1. Putting on Kevins radar so he can add the right people for uplifting if needed.
Flags: needinfo?(anygregor) → needinfo?(khu)

Updated

3 years ago
status-b2g-v2.0M: --- → wontfix
status-b2g-v2.1S: --- → affected
status-b2g-master: --- → fixed

Comment 32

3 years ago
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!
blocking-b2g: 2.2+ → 2.1+
Flags: needinfo?(khu) → needinfo?(vliu)

Comment 33

3 years ago
Dear Alberto,
Could you please help to raise patch approval for landing on 2.1?
Thanks!
Flags: needinfo?(vliu) → needinfo?(apastor)
(Assignee)

Comment 34

3 years ago
Hi! I'm afraid this caused a regression (Bug 1121707). Let me confirm that first. Thanks!
Flags: needinfo?(apastor)
[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?
blocking-b2g: 2.1+ → 2.1?
Depends on: 1121707
Flags: needinfo?(jocheng)

Comment 36

3 years ago
Hi Michael,
I think we can skip this patch for 2.1 base on your assessment until anyone has concern. 
Thank you!
status-b2g-v2.0: affected → wontfix
status-b2g-v2.1: affected → wontfix
status-b2g-v2.1S: affected → wontfix
Flags: needinfo?(jocheng)

Updated

3 years ago
blocking-b2g: 2.1? → 2.2+
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.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-v2.2: fixed → verified
status-b2g-master: fixed → verified
Flags: needinfo?(cinnes) → needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.