Closed Bug 1042009 Opened 10 years ago Closed 10 years ago

Notification Bar scroll got stuck while browsing

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::System
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 affected, b2g-v2.1 unaffected)

Status:
RESOLVED DUPLICATE of bug 1027035
Milestone:
2.1 S1 (1aug)
Project Flags:
blocking-b2g 2.0+
Tracking Flags:
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- affected
b2g-v2.1 --- unaffected

People

(Reporter: poojas, Assigned: cwiiis)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(2 files)

Notification bar scroll stucks in between while browsing
75 bytes, text/plain
Details
Notification bar scroll stuck in between
87 bytes, text/plain
Details 
When we pull down the notification bar, sometimes it got stuck in the middle. Once stuck, it is neither going up or down.

Steps to reproduce:
1. Open Browser
2. Browse for any websites.
3. There are two ways to reproduce this issue
  a. While loading the web page, pull down the notification bar slightly.     
     Reproducibility is 5/5
  b. After loading the webpage, pull down the notification bar slightly. 
     Reproducibility is 3/5
[Blocking Requested - why for this release]:
Blocks: CAF-v2.0-FC-metabug
blocking-b2g: --- → 2.0?
Component: Gaia::System::Window Mgmt → Gaia::System
Can we please have the exact STR and video to help with progressing here?
Flags: needinfo?(poojas)
Chris, could this be a regression from your animation patch?
Flags: needinfo?(chrislord.net)
blocking-b2g: 2.0? → 2.0+
STR is similar as before
1. Open Browser

2. Browse for any websites.

3. While loading the web page, pull down the notification bar slightly.
   Try pulling it multiple times. After few trail its stuck in half way 

Please refer Attached video
Flags: needinfo?(poojas)
QA Wanted - can we do branch checks here to see if it's a regression?
Keywords: qawanted
(In reply to Gregor Wagner [:gwagner] from comment #3)
> Chris, could this be a regression from your animation patch?

I guess it's possible, but I wouldn't have expected it. I'll wait for the regression window to confirm, I can't imagine it's too hard to fix either way (famous last words...)
Flags: needinfo?(chrislord.net)
The bug in question is bug 1038185.
Can we get a logcat as well?
Assigning to chris for now. Lets re-assign if we find a better owner after we get a regression window.
Assignee: nobody → chrislord.net
Whiteboard: [systemsfe]
Is this actually blocking CAF? I don't see a CR or caf priority in the whiteboard.
Flags: needinfo?(poojas)
(In reply to Lucas Adamski [:ladamski] (plz needinfo) from comment #10)
> Is this actually blocking CAF? I don't see a CR or caf priority in the
> whiteboard.

this issue has been found in dogfood program
Flags: needinfo?(poojas)
(In reply to bhargavg1 from comment #11)
> (In reply to Lucas Adamski [:ladamski] (plz needinfo) from comment #10)
> > Is this actually blocking CAF? I don't see a CR or caf priority in the
> > whiteboard.
> 
> this issue has been found in dogfood program

Oops, yes still it will have a CR
Target Milestone: --- → 2.1 S1 (1aug)
QA Contact: jmercado
This issue DOES occur on 2.0 Flame and 2.0 Buri.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140724081209
Gaia: 68226b3fd4eba752307daa5e917238bde253f5ab
Gecko: 8b920340ee28
Version: 32.0 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Buri 2.0
BuildID: 20140724081209
Gaia: 68226b3fd4eba752307daa5e917238bde253f5ab
Gecko: 8b920340ee28
Version: 32.0 (2.0) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0




This issue does NOT occur on 2.1 Flame, and 1.4 Flame.

Device: Flame Master
BuildID: 20140724063605
Gaia: c72257b2d27135bfcd68e89dd584182797784016
Gecko: 616e6924cb0b
Version: 34.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 1.4
BuildID: 20140724110218
Gaia: 6e4eaa5befce9c1812e07bcc78b2138645bdbe7a
Gecko: 6247843f09f1
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → unaffected
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Weird, I can reproduce this in 2.0 but it's strange to me that it doesn't happen in 2.1 - I guess the uplifted patch conflicted with some behaviour that was changed in the interim? Looking into it.
Status: NEW → ASSIGNED
Blocks: CAF-v2.0-CC-metabug
No longer blocks: CAF-v2.0-FC-metabug
This is happening because we're not preventing default on the touch-start, and presumably something else with higher priority wrt the event chain is swallowing the subsequent events.

I'm not sure why we don't see this in 2.1, possibly because the browser has changed behaviour or some other reason, but we probably should just always preventDefault on these events - I'm not sure why we don't.

I think we can simplify this code a bit, it seems to be doing a lot of seemingly redundant things.
Ok, this is weird, even having fixed that, I'm still getting strange behaviour... Starting to think that perhaps this is a platform bug? I'll test with master Gecko after a bit more digging.
This issue seems to be caused by Bug 1021512.  Seems related to what Chris is talking about.

B2g-inbound Regression Window

Last working 
Environmental Variables:
Device: Flame Master
BuildID: 20140612013332
Gaia: 49c56c9e1bf1c25f1b4c34a1aef97b25455f23d0
Gecko: f3ba91f22390
Version: 33.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken 
Environmental Variables:
Device: Flame Master
BuildID: 20140612015232
Gaia: 8d40a9499457c511db955ca9c81ee2931543d071
Gecko: b0fa8291f666
Version: 33.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Last working gaia / First broken gecko - Issue does NOT occur
Gaia: 49c56c9e1bf1c25f1b4c34a1aef97b25455f23d0
Gecko: b0fa8291f666

First broken gaia / Last working gecko - Issue DOES occur
Gaia: 8d40a9499457c511db955ca9c81ee2931543d071
Gecko: f3ba91f22390

Gaia Pushlog:  https://github.com/mozilla-b2g/gaia/compare/49c56c9e1bf1c25f1b4c34a1aef97b25455f23d0...8d40a9499457c511db955ca9c81ee2931543d071
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Blocks: 1021512
Can confirm that this isn't a Gecko bug... Looking at bug 1021512 I'm not sure why that would cause this, unless the touchcancel we synthesise ends up cancelling our touch event block?

n?etienne for comment, I'm kinda stumped on this right now. I'll carry on looking though.
Flags: needinfo?(etienne)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
I had a thought about this last night, is the browser still sharing the system process like it used to? Because if so, this behaviour makes some sense and we just need to special-case the browser in the code added in bug 1021512.
We are special casing [1]... |config.oop| should be false for the browser.

https://github.com/mozilla-b2g/gaia/blob/772746d840f949df90bdbac0f662066e3207d6be/apps/system/js/utility_tray.js#L220
Flags: needinfo?(etienne)
Ah! Not on 2.0.

Sorry for the noise, I'm pretty sure we just need to uplift bug 1027035.
And probably mark this one as a dupe.

Cheers!
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: