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

Status: RESOLVED DUPLICATE of bug 1055238

(Core :: DOM: Content Processes, defect)

Description

[Seth Miko [:SMiko]]

Attachment: 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

Comment 1

[Seth Miko [:SMiko]]

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

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

[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?

Comment 3

[Kevin Grandon :kgrandon]

FWIW I think we are seeing this in a lot of cases, not just changing the date.

Comment 5

[Kevin Grandon :kgrandon]

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.

Comment 6

[Yeojin Chung [:YeojinC]]

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

Comment 7

[Gregor Wagner [:gwagner]]

> 
> Caused by bug 1029155

Doug, can you help out here?

Comment 8

[Kevin Grandon :kgrandon]

Garrett - can you help us fix this issue or consider backing out bug 1029155?

Comment 9

[Kevin Grandon :kgrandon]

Alternatively David - since you reviewed bug 1029155, could you take a look here as well?

Comment 10

[Michael Henretty [:mikehenrty][:mhenretty]]

Just FYI, Garrett doesn't work for Mozilla anymore. Not sure if he is checking bugmail.

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

This looks very similar to bug 1055238.

Comment 12

[Michael Henretty [:mikehenrty][:mhenretty]]

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?

Comment 13

[Kevin Grandon :kgrandon]

(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.

Comment 14

[Michael Henretty [:mikehenrty][:mhenretty]]

Sorry, yeah I meant bug 1029155, not bug 1055238. Thanks Kevin.

Comment 15

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Please see if the patches in bug 1055238 also fix this - thanks!

Comment 17

[Candice Serran (:cserran)]

Doug, this is a platform bug...can you confirm if someone on your team is already looking at this? Thanks!

Comment 18

[Kevin Grandon :kgrandon]

Taking to verify if this has been fixed or not.

Comment 19

[Kevin Grandon :kgrandon]

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.

Comment 20

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I think we can mark this as a duplicate.