Closed Bug 1036671 Opened 10 years ago Closed 10 years ago

[B2G][Homescreen][Rocketbar] - Rocketbar results can't be selected after previously using the Rocketbar.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: Marty, Assigned: alive)

References

()

Details

(Keywords: smoketest, Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [systemsfe])

Attachments

(3 files)

Attached file logcat.txt
Description: If the user has already used the Rocketbar and selected a search result, they will not be able to select any future Rocketbar search results. Repro Steps: 1) Update a Flame device to BuildID: 20140708000322 2) Make sure the Flame device is set to 273mb. 3) Search "Browse" in the Rocketbar, then select the Browser 4) Tap the home button, and search "Video" in the Rocketbar 5) Try to select the Video search result Actual: Rocketbar search results are only selectable the first time. Expected: Rocketbar search results are always selectable. Environmental Variables: Device: Flame 2.0 MOZ ril (273mb) BuildID: 20140708000322 Gaia: e935f4ff190b76c70d9b2af8856c542a6e4a7546 Gecko: 3f9d7a3a0b7b Version: 32.0a2 Firmware Version: v122 2.0 - Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Keywords: Rocketbar, Homescreen, Search Notes: Restarting the phone will temporarily undo the issue. Repro frequency: 100% Link to failed test case: See attached: Video, logcat --------------------------------------- This issue DOES occur on Flame v2.1 (273mb) Environmental Variables: Device: Flame Master BuildID: 20140709040203 Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f Gecko: 196d05832e12 Version: 33.0a1 (Master) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Rocketbar search results are only selectable from the first search. ---------------------------------------- This issue does NOT occur on Flame 2.0 (512mb), Buri v2.0, Buri v2.1, Open-C v2.0, Open-C v2.1 Environmental Variables: Device: Flame 2.0 MOZ ril (512mb) BuildID: 20140708000322 Gaia: e935f4ff190b76c70d9b2af8856c542a6e4a7546 Gecko: 3f9d7a3a0b7b Version: 32.0a2 (2.0) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Environmental Variables: Device: Buri Master Build ID: 20140709073020 Gaia: c394b7b4205b6f1a6ca44915fc08650f3ad127ec Gecko: 2d88803a0b9c Version: 33.0a1 (Master) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Environmental Variables: Device: Buri 2.0 MOZ ril Build ID: 20140709063007 Gaia: 1774027323bb072b4ebdfea9883572bcf2535c87 Gecko: 11b6493a7d8f Version: 32.0a2 (2.0) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Environmental Variables: Device: Open_C Master Build ID: 20140708040218 Gaia: 740faa5d0060fb218b407cf224330654ddf833a5 Gecko: 465280604ea6 Version: 33.0a1 (Master) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Environmental Variables: Device: Open_C 2.0 MOZ ril Build ID: 20140708000322 Gaia: e935f4ff190b76c70d9b2af8856c542a6e4a7546 Gecko: 3f9d7a3a0b7b Version: 32.0a2 (2.0) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 All Rocketbar results are selectable for all searches. --------------------------------------------- This is a new issue for 2.0, and was not implemented in 1.4.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: smoketest
I think this issue might be related to restoring the previous Rocketbar search results. I hit the same problem after recieving an SMS and being returned to the Homescreen. When reopening the Rocketbar, the search field is empty, unlike how it behaves on Flame 2.0 512mb, or Buri 2.0, where it repopulates with the previous search term and search results.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] → [273MB-Flame-Support], [2.0-exploratory] [systemsfe]
Blocks: 1015336
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][VH-FL-blocking-][VH-FC-blocking+]
blocking-b2g: 2.0? → 2.0+
Component: Gaia::Homescreen → Gaia::Search
Martin - can you tell me if you had geolocation enabled or disabled? I'm wondering if you're running into the geolocation bug that is causing problems in this 273mb configuration. Thanks!
Flags: needinfo?(mshuman)
I have this happen when Geolocation is both enabled and disabled, no differences observed either way.
Flags: needinfo?(mshuman)
Assignee: nobody → kgrandon
Status: NEW → ASSIGNED
Target Milestone: --- → 2.0 S6 (18july)
Attached file Github pull request
Hey guys - either of you available to review this one? The problem is that we were not calling destroy() after an OOM. This resulted in multiple container nodes in the markup, overlaying the current container, and not allowing clicks through.
Attachment #8454037 - Flags: review?(alive)
Attachment #8454037 - Flags: review?(21)
Comment on attachment 8454037 [details] [review] Github pull request Odd. AppWindow.prototype._handle_mozbrowsererror should call destroy()(in kill()) for you. Could you investigate why destroy() is not called? This will help for future window management code maintenance.
Attachment #8454037 - Flags: review?(alive)
Attachment #8454037 - Flags: review?(21)
Hey Alive - it looks like we get into this block and destroy never gets called because isActive returns true for the search app, but the _closed event is never fired on the iframe: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_window.js#L420 Any preference on how to solve it? (You can also steal this bug if you'd like)
Flags: needinfo?(alive)
Stealing ;)
Assignee: kgrandon → nobody
Component: Gaia::Search → Gaia::System::Window Mgmt
Flags: needinfo?(alive)
Assignee: nobody → alive
QA Whiteboard: [QAnalyst-Triage+][VH-FL-blocking-][VH-FC-blocking+] → [QAnalyst-Triage+][lead-review+][VH-FL-blocking-][VH-FC-blocking+]
Attached file patch for master
After reading the rocketbar.js I am sure we need someone to clean it because of the state control seems weird now. The fix here is avoiding rewrite it with 1. Use terminated event 2. requestClose to map close when search window crashed 3. Use immediate transition instead of useless zoom-in/zoom-out 4. Use open/close on searchWindow instead of _setVisible when launching/closing rocketbar 5. Check searchWindow.isDead before opening it. It's because in terminated event handler it will call clear->handleInput->showResult->open the searchWindow again. This is terrible :/ The problem is even Kevin is not sure what to do here so the safest way is not changing the logic of terminated handler but have a check.
Attachment #8455254 - Flags: review?(etienne)
Attachment #8455254 - Flags: feedback?(kgrandon)
Comment on attachment 8455254 [details] [review] patch for master The code looks fine to me, I haven't verified yet, but will take a look on device soon. F+ from me though!
Attachment #8455254 - Flags: feedback?(kgrandon) → feedback+
Comment on attachment 8455254 [details] [review] patch for master Haven't looked at the weird state control, but this patch makes sense and I'm happy to remove the _setVisible calls from rocketbar.js anyway :)
Attachment #8455254 - Flags: review?(etienne) → review+
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [systemsfe] → [273MB-Flame-Support], [2.0-exploratory] [systemsfe]ETA=7/15
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [systemsfe]ETA=7/15 → [273MB-Flame-Support], [2.0-exploratory] [systemsfe][ETA=7/15]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [systemsfe][ETA=7/15] → [273MB-Flame-Support], [2.0-exploratory] [systemsfe]
Verified fixed on latest 2.0. Has not been verified on 2.1 yet. 2.0 Environmental Variables: Device: Flame 2.0 BuildID: 20140716000201 Gaia: 5f8b1b8a2da9e3b531eee817a669f57fa4d9b9c6 Gecko: 913827496f65 Version: 32.0a2 Firmware Version: v122
Verified fixed on Flame 2.1. Rocketbar search results are always selectable. Environmental Variables: Device: Flame 2.1 Build ID: 20140905000202 Gaia: 95e9b099aa89ded133e44014dd40b19dc0193c01 Gecko: 92a6bbdfd945 Version: 34.0a2 (2.1) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][lead-review+][VH-FL-blocking-][VH-FC-blocking+] → [QAnalyst-Triage?][lead-review+][VH-FL-blocking-][VH-FC-blocking+]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?][lead-review+][VH-FL-blocking-][VH-FC-blocking+] → [QAnalyst-Triage+][lead-review+][VH-FL-blocking-][VH-FC-blocking+]
Flags: needinfo?(pbylenga)
Depends on: 1065096
No longer depends on: 1065096
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: