Closed Bug 796688 Opened 12 years ago Closed 12 years ago

Call log is not populated if the dialer application is closed

Categories

(Firefox OS Graveyard :: Gaia, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: ghtobz, Assigned: alberto.pastor)

Details

(Whiteboard: [label:dialer][gh-assignee:borjasalguero])

Attachments

(1 file)

[GitHub issue by vingtetun on 2012-09-20T14:55:14Z, https://github.com/mozilla-b2g/gaia/issues/4980]
If you receive a call with the dialer close the call log is not populated (which is wrong). If you receive an other call when the dialer is opened you can observe that there is now 2 calls from the same number (which is right).

@borjasalguero @etiennesegonzac any ideas?
[GitHub comment by etiennesegonzac on 2012-09-20T17:35:41Z]
Didn't look yet but looks like the database is being updated but the call log is not being re-rendered.
[GitHub comment by borjasalguero on 2012-09-21T11:33:45Z]
@etiennesegonzac +1. Because the DB is populated in the 'Attention-screen', so it should be an issue of the 'rendering'.  I'm downloading the latest build+code and I will test it again :S
Assignee: nobody → alberto.pastor
The problem here is that the attention screen is launching the Dialer app. In this inicialization, the Recents are retrieved from the DB before adding the missed call. As the app was already opened, when clicking the Dialer won't cause a "mozvisibilitychange" event, and the Recents view won't be refreshed.

In my opinion, the attention screen launch should ensure the Dialer has setVisible to false, ensuring then that the mozvisibilitychange event will be raised. There are other options, but I think that's the cleanes way.

Thoughts?
Hi guys! In my opinion, and as Alberto is for sure aware of ;-) , the "mozvisibilitychange" is not raised not because the Dialer app is already open but for some other "strange" reason. In fact, what it is really surprising to me is the fact that if you (with the Dialer app closed):
1.-Call the Otoro.
2.- Reject the call.
3.- Open any other app. At this time the Dialer app should not be the visible (front) one.
4.- Open the Dialer app and once again the "mozvisibilitychange" is not dispatched :-O
If I'm not wrong, the mozvisiblitychange event is not raised the first time you open an app, and that's because that event depends on setVisible set to true or false. In fact, in the attention screen we ensure that happens for the current app [1]. In the case we are talking about, the current app is the homescreen. We need also the Dialer ensuring that event.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/attention_screen.js#L95
You are absolutely right @pastoret ;-) I have just confirmed it (in case it was even necessary) using the remote debugging feature :-)

I have also included some code in the attention_screen.js file to check that Alberto's proposal would work. More concretely, I included this code after https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/attention_screen.js#L98 :

var commsFrame = WindowManager.getAppFrame(
      "app://communications.gaiamobile.org/dialer/index.html");
if(commsFrame && 'setVisible' in commsFrame)
   commsFrame.setVisible(false);

and it works. The problem is that it is kind of too Communications app specific in the general purpose attention screen file.

Any suggestions? Thanks!
Thanks German for the checking.
Attention Screen is launched by an app. Why do you need to hardcode communications origin when you know which app opened the attention screen? The only problem I see here is the multiple entry points...

Anyway, I can add the needed code, but I would like Etienne also agreeing with the solution.
Flags: needinfo?(etienne)
Ups, it seems one of my comments just disappeared or maybe I didn't click on "Save Changes" at the end ;-999

Yeah @pastoret , we know the launching app but in the case of incoming calls (when the Comms app is not open) that app is the Homescreen (value of "displayedOrigin" in https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/attention_screen.js#L91) and consequently it is that app the one whose frame is setVisible(false) whereas we need the Comms one to be also setVisible(false).

I do agree 100% that the problem here is the multiple entry points ;-)
Sorry, when I said "launched by an app" I meant "launches an app". What's the value of app in [1]? That's the reason I say we don't need hardcode it. There is where the multiple entry points are a problem.

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/attention_screen.js#L66
Let me inspect it with the remote debugger ;-)
As discussed with @pastoret offline, there would be a way not to hardcode the Comms origin as a string although the multiple entry points are still a problem, not to particularize it "too much" to the Comms app. For the time being, the solution could be something such as:

var mainAppManifest = app.manifest;
if (mainAppManifest.entry_points && mainAppManifest.entry_points.dialer && mainAppManifest.entry_points.dialer.launch_path) {
  var mainAppOrigin = app.origin + mainAppManifest.entry_points.dialer.launch_path;
  var mainAppFrame = WindowManager.getAppFrame(mainAppOrigin);
  if(mainAppFrame && 'setVisible' in mainAppFrame)
    mainAppFrame.setVisible(false);
}

which actually works.
BTW, I just found that this issue is somehow two-fold :-O In fact, if the Comms app is not open and the device is in stand-by mode or with the lock-screen shown, any incoming call is not even registered, I mean it is not even stored in the "dialerRecents" IndexedDB database :-O

I will continue tracking it tomorrow... ;-)
Germán, no way we are hardcoding "dialer" or similar on the attention screen. This is a common thing with all the apps that are closed and opens an attention screen. We only need to figure out how to handle multiple entry points.

Makes no sense 2 people working on this bug. I just wanted to agree the solution. I'm happy to pass you the bug if you want. Let me know and I'll assign it to you in that case.

Thanks for the help!
Yeah, that's why I included the code as a comment and not in a PR or patch ;-)

On the other hand, I kept on working on the bug because I started to find buggy behaviors related to the original bug such as the one previously commented or even cases where some of the missed calls were lost (I have not been able to figure out the precise flow to reproduce it yet). The code I included in some of my comments just let me dismiss possible causes of the strange behaviors I was noticing, not the final solution at all, just part of the discussion ;-)

Let's do this, you can focus on the multiple entry point issue and I'll focus on the "no registering" of calls. If you consider it appropriate I could create another bug for these other buggy behaviors which, although related to this bug, I think could be caused by other reasons :-) Something such as: "Missed calls not registered if Dialer app closed and stand-by mode" :-) 

What do you think?
I don't think we should separate in 2 bugs. I had already investigated some of the things you where commenting here. The bug describes exactly what is happening: the missed call is not displayed in the call log when the app is closed. Let me just finish it with a patch and we'll see after it.

Sounds good?
Pointer to Github pull-request
Attachment #672146 - Flags: review?(gtorodelvalle)
Attachment #672146 - Flags: review?(etienne)
Sorry @gtorodelvalle, couldn't reproduce the error you commented with the patch. If you want to quickly test it, I'd appreciate it. 
Thanks!
Let me try to state the steps to reproduce it:
1.- Open the Comms app and check the status of the call log.
2.- Close the Comms app via the Home button and swiping on the "Phone" card upward. I mean, you have to close the Comms app, not just "hide" it.
3.- Click on the switch on/off button on the top to enter stand-by mode (the screen turns off). You can click here again the switch on/off button since this does not seem to affect the results.
4.- With the lock screen shown or the screen turned off, make a missed call to the Otoro (you can hang the call in the Otoro or in the calling phone).
5.- Unlock the Otoro.
6.- Open de Comms app.
7.- Check the call log. It "will" be as it was at the beginning of this test with no entry related to the latest missed call.
8.- No matter how many times you close and open the Comms app (to cause a refresh or reload of the call log), no entry appears for the latest missed call.

Does it reproduce in your device too? :-O
Attachment #672146 - Flags: review?(etienne) → review+
Sorry, I did the exact same steps and can't reproduce.

gaia from the pull request
gecko 1ec4bdea9de7c0567810fd09cb55b02304b3186d

Thanks!
Hi! I have just tried it again after updating the backend and it works so congrats!!! ;-)
https://github.com/mozilla-b2g/gaia/commit/3bdf9c46738a4bab9485552fc28708ac1603a73f
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Attachment #672146 - Flags: review?(gtorodelvalle)
Flags: needinfo?(etienne)
Unagi Build ID:20121231070201 - no repro
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: