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)
Tracking
(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 affected, b2g-v2.1 unaffected)
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)
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
Updated•10 years ago
|
Component: Gaia::System::Window Mgmt → Gaia::System
Comment 2•10 years ago
|
||
Can we please have the exact STR and video to help with progressing here?
Flags: needinfo?(poojas)
Comment 3•10 years ago
|
||
Chris, could this be a regression from your animation patch?
Flags: needinfo?(chrislord.net)
Updated•10 years ago
|
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)
Comment 5•10 years ago
|
||
QA Wanted - can we do branch checks here to see if it's a regression?
Keywords: qawanted
Assignee | ||
Comment 6•10 years ago
|
||
(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)
Comment 9•10 years ago
|
||
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]
Comment 10•10 years ago
|
||
Is this actually blocking CAF? I don't see a CR or caf priority in the whiteboard.
Flags: needinfo?(poojas)
Comment 11•10 years ago
|
||
(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)
Comment 12•10 years ago
|
||
(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
Updated•10 years ago
|
Target Milestone: --- → 2.1 S1 (1aug)
Updated•10 years ago
|
QA Contact: jmercado
Comment 13•10 years ago
|
||
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
Updated•10 years ago
|
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
Assignee | ||
Comment 14•10 years ago
|
||
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
Assignee | ||
Comment 15•10 years ago
|
||
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.
Assignee | ||
Comment 16•10 years ago
|
||
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.
Comment 17•10 years ago
|
||
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
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Assignee | ||
Comment 18•10 years ago
|
||
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)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Assignee | ||
Comment 20•10 years ago
|
||
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.
Comment 21•10 years ago
|
||
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)
Comment 22•10 years ago
|
||
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!
Assignee | ||
Updated•10 years ago
|
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.
Description
•