Closed Bug 937101 Opened 11 years ago Closed 11 years ago

[status bar] unable to grab down the status bar

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::System
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:koi+, b2g-v1.2 verified)

Status:
VERIFIED FIXED
Project Flags:
blocking-b2g koi+
Tracking Flags:
Tracking Status
b2g-v1.2 --- verified

People

(Reporter: debian, Assigned: vingtetun)

References

Details

(Keywords: regression)

Attachments

(1 file)

bug937101.patch
973 bytes, patch
alive
: review+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131104173414

Steps to reproduce:

I built b2g v1.2 on inari (zte-open) last night.


Actual results:

I can't grab down the status bar... It's just unresponsive!
Component: Gaia::Homescreen → Gaia::System
Possibly a dupe of bug 902393?
(In reply to Kevin Grandon :kgrandon from comment #1)
> Possibly a dupe of bug 902393?

Oops - maybe not. Seems like they can't pull it down and bug 902393 was about pulling it up?
(In reply to Kevin Grandon :kgrandon from comment #2)
> (In reply to Kevin Grandon :kgrandon from comment #1)
> > Possibly a dupe of bug 902393?
> 
> Oops - maybe not. Seems like they can't pull it down and bug 902393 was
> about pulling it up?

It's right! I can't pull it down! Same issue by random people with inari on the net.

Actually you can only use it with a trick: you need to rotate your screen down! With some app that can rotate! Then you can pull it down. :(
Vivien - possibly related to event fluffing?
Flags: needinfo?(21)
I'm not sure this is a fluffling issue. One easy way to test is to add:

pref("ui.touch.radius.enabled", false);
pref("ui.mouse.radius.enabled", false);

to your user.js file and test.

In order to get it you can:
adb pull /data/local/user.js
edit the file...
adb push user.js /data/local/user.js
adb reboot


If this is not related to fluffing it could be a bug somewhere else. For example I found out that this bug happens depending on how I put my finger on the screen.

(1) If I put my finger straight with a big area covered by it, then I can not open the statusbar.
(2) If I put my finger on the side, with just the end of the finger touching the screen, then it works all the time.

So I suggest fixing user fingers first! More serously I see that there is always a touchstart event in the system app, whatever position your finger is in, but there is no touchmove afterward in the case of (1). First idea is that the touchmove events are absorbed by the underlying app frame. So it worth trying to capture events if they start on the statusbar at first).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(21)
Seems like i can not reproduce with the same steps on all devices. I can on my keon but not on a peek or a hamachi.
Yes it is.
If i add:
pref("ui.touch.radius.enabled", false);
pref("ui.mouse.radius.enabled", false);
to my user.js i solve my problem.

Can I just stick with those options off?
(In reply to debian from comment #7)
> Yes it is.
> If i add:
> pref("ui.touch.radius.enabled", false);
> pref("ui.mouse.radius.enabled", false);
> to my user.js i solve my problem.
> 
> Can I just stick with those options off?

You can but it will make your life harder when it comes to click to web links or any other click-able areas.
The real solution is probably to make the statusbar a real event target area and so the fluffling code will not ignore it. Right now the mouse events that triggers the opening of the notification area are attached directly to the window element, which does not helps. 

If this is really fluffing related replacing: window.addEventListener(this, type); at https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/utility_tray.js#L22 by:

this.overlay.addEventListener(this, type);
this.statusbar.addEventListener(this, type);
this.grippy.addEventListener(this, type);

should helps by making the statusbar a real event target and making it preferred when it comes to fluffling.
Attached patch bug937101.patch — — Splinter Review 
Can you try this patch, turn on fluffing again, and see if it helps?
Can you explain me how to add this patch without recompiling everything and flash?
Actually i'm using nightly patches by mozilla. I compiled my system one time.
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #6)
> Seems like i can not reproduce with the same steps on all devices. I can on
> my keon but not on a peek or a hamachi.

This recalls me other fluffing-related issues (remember the send button in SMS?).

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #8)
> The real solution is probably to make the statusbar a real event target area
> and so the fluffling code will not ignore it. Right now the mouse events
> that triggers the opening of the notification area are attached directly to
> the window element, which does not helps. 

Are you saying that with event fluffing we should not use event delegation anymore? This looks pretty bad... Am I overreacting?

(In reply to debian from comment #10)
> Can you explain me how to add this patch without recompiling everything and
> flash?
> Actually i'm using nightly patches by mozilla. I compiled my system one time.

This is a patch to the system app, so from the B2G directory:

  cd gaia
  apply patch
  APP=system make install-gaia
I noticed today that it's difficult to expand/shorten the various panes on mobile wikipedia. Eg go to "m.wikipedia.org", search for "Ram Jam", try to expand the panes.

In the markup, we see the panes are only headers, and there are "touchstart" and "mouseup" events registered on a parent (the 4th ancestor) of the panes.

Could it be related?

Note thate there is no link or direct event target close to where we tap, and therefore the fluffing code can't mis-use another element. It just looks like we lose events.
(In reply to Julien Wajsberg [:julienw] from comment #11)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #6)
> > Seems like i can not reproduce with the same steps on all devices. I can on
> > my keon but not on a peek or a hamachi.
> 
> This recalls me other fluffing-related issues (remember the send button in
> SMS?).

Yeah. Devices manage touch inputs differently :(.

> 
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #8)
> > The real solution is probably to make the statusbar a real event target area
> > and so the fluffling code will not ignore it. Right now the mouse events
> > that triggers the opening of the notification area are attached directly to
> > the window element, which does not helps. 
> 
> Are you saying that with event fluffing we should not use event delegation
> anymore? This looks pretty bad... Am I overreacting?
> 

Mixing event delagation and direct event targetting will always prioritize the elements itself. It usually do what you want but in the case of the system app it is a bit harder since the system app elements and the app content does not live in the same process we tend to prioritize the app just in case.

So we need to leverage the statusbar at some point.

> (In reply to debian from comment #10)
> > Can you explain me how to add this patch without recompiling everything and
> > flash?
> > Actually i'm using nightly patches by mozilla. I compiled my system one time.
> 
> This is a patch to the system app, so from the B2G directory:
> 
>   cd gaia
>   apply patch
>   APP=system make install-gaia
(In reply to Julien Wajsberg [:julienw] from comment #12)
> I noticed today that it's difficult to expand/shorten the various panes on
> mobile wikipedia. Eg go to "m.wikipedia.org", search for "Ram Jam", try to
> expand the panes.
> 
> In the markup, we see the panes are only headers, and there are "touchstart"
> and "mouseup" events registered on a parent (the 4th ancestor) of the panes.
> 
> Could it be related?
> 

Works well for me but I will see you in the office for a real demo since I can misreproduce yout steps. In any case this is likely a different issues (if any) since there are at least 2 differences I can think of. In the case of this particular bug:
 - the app content is an iframe without any event target handler. But we leverage it in the platform just to be sure.
 - the code path taken for touch inputs is a bit different for mozasyncpanzoom elements.

May worth investigating as a separate issue I believe.
Blocks: 789358
Comment on attachment 833345 [details] [diff] [review]
bug937101.patch

debian, you may break your updates it you apply a custom patch. I feel like this patch should solve your issue though.
Attachment #833345 - Flags: review?(alive)
Keywords: regression
Comment on attachment 833345 [details] [diff] [review]
bug937101.patch

Review of attachment 833345 [details] [diff] [review]:
-----------------------------------------------------------------

Isn't this fixed before?
Attachment #833345 - Flags: review?(alive) → review+
Vivien

The question we had in triage was: 

1) What are the points on the screen where the scroll bar cannot be grabbed?
2) Is this an easily reproducible use case? or a corner case one?
Flags: needinfo?(21)
(In reply to Preeti Raghunath(:Preeti) from comment #17)
> Vivien
> 
> The question we had in triage was: 
> 
> 1) What are the points on the screen where the scroll bar cannot be grabbed?

Sorry, I'm not 100% sure of what is the meaning of the question. The bug is not about scrollbars, but about the top black area, called the statusbar, that lives on the top of the screen most of the time (except when an application is on fullscreen). This bar can not be opened *sometimes*, where sometimes seems to vary based on the device, and the current state of the device.

So basically it happens very often that this statusbar, that contains notifications, can not be opened at all.

> 2) Is this an easily reproducible use case? or a corner case one?

Easily reproducible.
Flags: needinfo?(21)
koi+ as status bar not working is bad.
blocking-b2g: koi? → koi+
Vivien

Given that you are quite active on this bug, can you please own this bug?
Flags: needinfo?(21)
Assignee: nobody → 21
Flags: needinfo?(21)
Uplifted e7edad1c038670db79242901f36fc9b77460f718 to:
v1.2: 46057f13f839ec609bd65683bf799891a8846206
status-b2g-v1.2: --- → fixed
Adding dep for pre-iot 1.2
Blocks: 943796
Sorry that i'm that late.
Here is still not working with the latest night build!
Debian, can you please describe what you're trying to do, and possibly file another bug?
Experiencing no issues pulling down the status bar.

1.2 Environmental Variables:
Device: Buri v1.2 COM RIL
BuildID: 20131205004003
Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a
Gecko: af2c7ebb5967
RIL Version: 01.02.00.019.102 
Version: 26.0
Firmware Version: V1.2_20131115

1.3 Environmental Variables:
Device: Buri v1.3 MOZ RIL
BuildID: 20131205040201
Gaia: 1dd0e5c644b4c677a4e8fa02e50d52136db489d9
Gecko: 725c36b5de1a
Version: 28.0a1
Firmware Version: V1.2_20131115
Status: RESOLVED → VERIFIED
status-b2g-v1.2: fixed → verified
Hi,

After updating to 1.2 including the patch above, it's still absolutely impossible for me to pull the bar/tray down on ZTE Open without doing one of the following:

- disabling the touch/mouse radius;
- or increasing the #statusbar height to 2.5rem at least (affects screen size calculation and has other disadvantages);
- or make the #utility-tray always visible.

The first two points show that's probably an event fluffling issue. Is there a way to just decrease the touch radius without completely disabling it?

---
TIA
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: