Closed Bug 1063178 Opened 7 years ago Closed 7 years ago

[Browser] Rocketbar searches result in a white screen after changing the date

Categories

(Core :: DOM: Content Processes, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1055238
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- affected
b2g-v2.2 --- fixed

People

(Reporter: smiko, Assigned: kgrandon)

References

Details

(Keywords: dogfood, regression, Whiteboard: [systemsfe][2.1-exploratory])

Attachments

(1 file)

Attached file WhiteSearch.txt
Description:
After changing the date, conducting a Rocketbar search results in a white screen.

Repro Steps:
1: Update a Flame to 20140904000203
2: Open Settings > Date and Time and set the date to anything other than the current one.
3: Click on the Rocketbar and enter any search criteria

Actual:
The page loads to a white screen

Expected:
Search results or error message is displayed 

Flame 2.1 (319mb)

Environmental Variables:
Device: Flame 2.1 (319mb)
Build ID: 20140903000204
Gaia: fbb297c39aab5f17b179533d2a9a6c5166b2c197
Gecko: fb5e796da813
Version: 34.0a2 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Notes:
1: This issue also occurs when searching via Browser

Repro frequency: 100%

See attached: logcat

Video clip: http://youtu.be/5tP8lrA51qY
This issue DOES repro on Flame 2.2(319mb), Open C 2.2, Flame 2.1(319mb),and Open C 2.1

Actual Result: The page loads to a white screen

Flame 2.2(319mb)

Environmental Variables:
Device: Flame Master (319mb)
Build ID: 20140904040204
Gaia: 008026e932b64b4a70b9931c3da96986583bc8d4
Gecko: 776fa9cf70cd
Version: 35.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Open C 2.2

Environmental Variables:
Device: Open_C Master
Build ID: 20140904040204
Gaia: 008026e932b64b4a70b9931c3da96986583bc8d4
Gecko: 776fa9cf70cd
Version: 35.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1(512mb)

Environmental Variables:
Device: Flame 2.1 (512mb)
BuildID: 20140904000203
Gaia: a47ecb6368c015dd72148acde26413fd90ba3136
Gecko: 757931d0149e
Version: 34.0a2 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Open C 2.1

Environmental Variables:
Device: Open_C 2.1
BuildID: 20140904000203
Gaia: a47ecb6368c015dd72148acde26413fd90ba3136
Gecko: 757931d0149e
Version: 34.0a2 (2.1)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

This issue does NOT repro on Flame 2.0(319mb), or Open C 2.0

Actual Result: Search results or error message displays 


Flame 2.0 (319mb)

Environmental Variables:
Device: Flame 2.0 (319mb)
BuildID: 20140904000202
Gaia: d056733f8a7a1a152f5458b323f092c47dbffa48
Gecko: 19383abee78a
Version: 32.0 (2.0)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0"

Open_C 2.0

Environmental Variables:
Device: Open_C 2.0 
Build ID: 20140904000202
Gaia: d056733f8a7a1a152f5458b323f092c47dbffa48
Gecko: 19383abee78a
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regression
Whiteboard: [2.1-exploratory]
[Blocking Requested - why for this release]:

This is a regression from 2.0. The user will not understand why they are getting a white screen when performing a rocketbar search if their date on the device is set to anything but today's date. Nominating 2.1?
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: ychung
Component: Gaia::Browser → Gaia::Search
blocking-b2g: 2.1? → 2.1+
Whiteboard: [2.1-exploratory] → [2.1-exploratory][systemsfe]
FWIW I think we are seeing this in a lot of cases, not just changing the date.
Duplicate of this bug: 1063269
I somehow got lucky and found a 100% STR for this. You can always reproduce this with the following:

1 - On the device open the rocketbar and enter some text, do not press enter.
2 - In a shell, open up adb shell.
3 - Kill the pre-allocated process with kill -9 <pid>
4 - Immediately after the pre-allocated process is killed, press the "Search/enter" key on the keyboard.

Expected STR:
Website is launched.

Actual STR:
White screen.
Component: Gaia::Search → DOM: Content Processes
Product: Firefox OS → Core
Mozilla-inbound Regression Window:

Last Working Environmental Variables:
Device: Flame Master
BuildID: 20140815111214 
Gaia: d0d773c277a9105288ee35da2121f4ae62709be8
Gecko: fd08e61066de
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken Environmental Variables:
Device: Flame Master
BuildID: 20140815112915 
Gaia: d0d773c277a9105288ee35da2121f4ae62709be8
Gecko: 229181c88a3c
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce 
Gaia: d0d773c277a9105288ee35da2121f4ae62709be8
Gecko: 229181c88a3c

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: d0d773c277a9105288ee35da2121f4ae62709be8
Gecko: fd08e61066de

Gecko Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fd08e61066de&tochange=229181c88a3c

Caused by bug 1029155
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
> 
> Caused by bug 1029155

Doug, can you help out here?
Flags: needinfo?(dougt)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Garrett - can you help us fix this issue or consider backing out bug 1029155?
Flags: needinfo?(garrett.f.robinson+mozilla)
Alternatively David - since you reviewed bug 1029155, could you take a look here as well?
Flags: needinfo?(dkeeler)
Just FYI, Garrett doesn't work for Mozilla anymore. Not sure if he is checking bugmail.
This looks very similar to bug 1055238.
Flags: needinfo?(dkeeler)
This is making dogfooding the rocketbar/search app on 2.1 extremely hard. And we need to dogfood and fix bugs here since it is one of new and important features for this release. David, can we backout bug 1055238 until we get a fix?
Flags: needinfo?(dkeeler)
Keywords: dogfood
(In reply to Michael Henretty [:mhenretty] from comment #12)
> This is making dogfooding the rocketbar/search app on 2.1 extremely hard.
> And we need to dogfood and fix bugs here since it is one of new and
> important features for this release. David, can we backout bug 1055238 until
> we get a fix?

Funny - we'd need to backout bug 1029155, and I just asked David in there :) Clearing ni? and adding the dependency to make things more clear.
Blocks: 1029155
Flags: needinfo?(garrett.f.robinson+mozilla)
Flags: needinfo?(dkeeler)
Sorry, yeah I meant bug 1029155, not bug 1055238. Thanks Kevin.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Please see if the patches in bug 1055238 also fix this - thanks!
Duplicate of this bug: 1064921
Doug, this is a platform bug...can you confirm if someone on your team is already looking at this? Thanks!
Whiteboard: [2.1-exploratory][systemsfe] → [2.1-exploratory]
Taking to verify if this has been fixed or not.
Assignee: nobody → kgrandon
Flags: needinfo?(dougt)
Whiteboard: [2.1-exploratory] → [systemsfe][2.1-exploratory]
I can no longer reproduce this issue now that bug 1055238 has been fixed. Marking as fixed via bug 1055238, though I'm not sure what the best way to track this from a qa/uplift standpoint is.
Status: NEW → RESOLVED
Closed: 7 years ago
Depends on: 1055238
Resolution: --- → FIXED
I think we can mark this as a duplicate.
Resolution: FIXED → DUPLICATE
Duplicate of bug: 1055238
You need to log in before you can comment on or make changes to this bug.