Closed Bug 877971 Opened 11 years ago Closed 10 years ago

The call logs menu doesn't show the call time duration

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia::Dialer
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(feature-b2g:2.1, tracking-b2g:backlog)

Status:
VERIFIED FIXED
Milestone:
2.1 S3 (29aug)
Project Flags:
feature-b2g 2.1
tracking-b2g backlog

People

(Reporter: sync-1, Assigned: rik)

References

Details

(Keywords: feature, meta, Whiteboard: [tef-triage][planned-sprint][2.1-feature-qa+])

User Story

https://wiki.mozilla.org/Gaia/Comms/2.1/Call_Length

Attachments

(2 files, 9 obsolete files)

[2.1 Dialer] Call duration in Call log v0.4.pdf
2.47 MB, application/pdf
Details
Call_log_info_Visual spec.zip
487.54 KB, application/zip
Details 
AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.121
 Firefox os  v1.0.1
 Mozilla build ID:20130527070203
 
 DEFECT DESCRIPTION:
 The call logs menu doesn
blocking-b2g: --- → tef?
Summary: [Buri][HOMO]The call logs menu doesn → [Buri][IOT]The call logs menu doesn
DEFECT DESCRIPTION:
The call logs menu doesn´t show the call time duration

 REPRODUCING PROCEDURES:
1.- Make or receive a voice call
2.- End the call
3.- Go to call log
4.- Check the log corresponding to the last call
5.- Verify that only shows the time but not the total duration

 EXPECTED BEHAVIOUR:
The DuT should save the call timer duration on the call log menu

 ASSOCIATE SPECIFICATION:

 TEST PLAN REFERENCE:

 TOOLS AND PLATFORMS USED:
sw v12D

 USER IMPACT:

 REPRODUCING RATE:
100%

 For FT PR, Please list reference mobile's behavior:
This seems to me like a new feature
Whiteboard: [tef-triage]
triage: this is feature request. koi? for future consideration
blocking-b2g: tef? → koi?
Summary: [Buri][IOT]The call logs menu doesn → [Buri][IOT]The call logs menu doesn´t show the call time duration
Assignee: nobody → rexboy
WIP
https://github.com/rexboy7/gaia/commit/5aecaaa7188dba3d54fec3c982840bb1f57b449c

It's not complex to implement, but since we need to add a 'duration'
property to both Groups and Recents DB, I'm not sure if we need to update
database version for it. (This is just a property that doesn't need to be indexed)
Since I'm not sure the criteria that when to do a version update,
Etienne, may you give some suggestions?
Thanks a lot!
Flags: needinfo?(etienne)
First things first, asking for some UX feedback on this one.
Not sure if showing the duration works well with the "grouping" feature.

(In reply to KM Lee [:rexboy] from comment #4)
> WIP
> https://github.com/rexboy7/gaia/commit/
> 5aecaaa7188dba3d54fec3c982840bb1f57b449c
> 
> It's not complex to implement, but since we need to add a 'duration'
> property to both Groups and Recents DB, I'm not sure if we need to update
> database version for it. (This is just a property that doesn't need to be
> indexed)
> Since I'm not sure the criteria that when to do a version update,
> Etienne, may you give some suggestions?

We need a new migration every time we add one or more fields to the indexeddb backend.
Flags: needinfo?(etienne) → needinfo?(firefoxos-ux-bugzilla)
Attached image Screenshot (WIP) (obsolete) — 
Thank you Etienne.

Posting the WIP screenshot as additional information for UX.
For groups, in WIP, the duration is simply the total time of all calls in group.
Flagging Francis on expected behavior.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(fdjabri)
Move it to correct component, Dialer.
Component: Gaia::Keyboard → Gaia::Dialer
Blocks: comms_backlog
blocking-b2g: koi? → ---
any updates here?
QA Contact: atsai
(In reply to Etienne Segonzac (:etienne) from comment #5)
> First things first, asking for some UX feedback on this one.
> Not sure if showing the duration works well with the "grouping" feature.
> 
> (In reply to KM Lee [:rexboy] from comment #4)
> > WIP
> > https://github.com/rexboy7/gaia/commit/
> > 5aecaaa7188dba3d54fec3c982840bb1f57b449c
> > 
> > It's not complex to implement, but since we need to add a 'duration'
> > property to both Groups and Recents DB, I'm not sure if we need to update
> > database version for it. (This is just a property that doesn't need to be
> > indexed)
> > Since I'm not sure the criteria that when to do a version update,
> > Etienne, may you give some suggestions?
> 
> We need a new migration every time we add one or more fields to the
> indexeddb backend.

Actually, for this case, you can safely add the new fields in 'CallLogDBManager.add()'. There is no need for a db version upgrade.
(In reply to KM Lee [:rexboy] from comment #6)
> For groups, in WIP, the duration is simply the total time of all calls in
> group.

That does not really make sense to me. I would just not show the time for group of calls. If we ever expand the groups, we could show the duration of each individual call.

In any case, that's an UX call.
This is coming back as a request from operator for certification for the country they want to launch in.
(In reply to Fernando Jiménez Moreno [:ferjm] (needinfo, please) from comment #13)
> That does not really make sense to me. I would just not show the time for
> group of calls. If we ever expand the groups, we could show the duration of
> each individual call.
> 
> In any case, that's an UX call.
In that way, we may need another UI for showing individual duration of calls in
a group.. Otherwise user have no way to know the duration when calls becomes a group.

(In reply to Wilfred Mathanaraj [:WDM] from comment #14)
> This is coming back as a request from operator for certification for the
> country they want to launch in.
Should we nominate leo? again then?
only to be done, if we do it, in v1.3 and not before.
As a user I want to be able to see in the call log how long the call lasted.

Acceptance Criteria:

* i am able to see the length of call in hh:mm:ss format (if its only seconds then i expect to see "s" next to the length)
* I exepct to see it for both MT and MO calls
Flags: needinfo?(fdjabri)
blocking-b2g: --- → 1.3?
(In reply to Wilfred Mathanaraj [:WDM] from comment #17)
> As a user I want to be able to see in the call log how long the call lasted.

Which call?
The call log displays call groups (each line represents 1 or more calls).

The user story needs to be more precise.
No longer blocks: comms_1.3_targeted
Minused, it's a tracked bug, will be renominated later
minused per comment 19
blocking-b2g: 1.3? → -
Such a feature would be very important for users who have a given amount of minutes per month and don't want to exceed this amount of minutes. I for myself have such a contract for testing and after those 100 minutes the price goes up extremely. Also this operator counts full minutes, so if a call has been taking 1:01min you will get charged for 2:00min. Given that it is very hard to predict at the moment when you have reached the limit. Sadly this operator also doesn't have any online tool to check that in-front.

If the call time would be available someone could at least manually sum up the minutes to check that. Also it would be nice if cost control could support phone calls. I will file a separate bug for that.
Summary: [Buri][IOT]The call logs menu doesn´t show the call time duration → The call logs menu doesn't show the call time duration
Flags: needinfo?(styang)
According product manager's comments, target it in v1.4
Flags: needinfo?(styang)
blocking-b2g: - → 1.5?
to backlog and unassign from Rex since he's not working on this
Assignee: rexboy → nobody
blocking-b2g: 1.5? → backlog
It has been raised during v1.3 IOT processes by TEF OBs. It might be a blocker for the next IOT process so nominating it to 2.0? to be prioritized.
Blocks: comms_2.0_targeted
No longer blocks: comms_backlog
blocking-b2g: backlog → 2.0?
Flags: needinfo?(wmathanaraj)
If this is a blocker then we need to find a way to implement this without adding more items into the already crowded call log. 

If possible perhaps create a sub-menu to have this time displayed. 

I still dont find this to be a very important feature - not sure how the end user will be helped by showing the call duration
Flags: needinfo?(wmathanaraj)
ni? Carrie on where the call duration information can be displayed
Flags: needinfo?(cawang)
(In reply to Wilfred Mathanaraj [:WDM] from comment #26)
> I still dont find this to be a very important feature - not sure how the end
> user will be helped by showing the call duration

Please think about the scenario where a user is on prepaid (with limited minutes) and thus in tight control of his/her limited time. Very often one would think about how many minutes were used with the just-ended call and then have an idea how many are left.

It is really easy to understand this if one is on prepaid with limited minutes versus being on a contract with unlimited minutes.
I don't think we have enough space for this. I'd suggest displaying it in the second screen. However, we will trigger (by long-tap) Contact details/ action menu as second screen from call log and neither of them is good for showing this information. Hence, I'd prefer having this after we redesign the call directly from call log and then reconsider it at that time. Thanks!
Flags: needinfo?(cawang)
Sorry to say it again but this is a future IOT blocker, please prioritize this feature to be included in v2.0 redesign.
(In reply to Carrie Wang [:carrie] from comment #29)
> I don't think we have enough space for this. I'd suggest displaying it in
> the second screen. However, we will trigger (by long-tap) Contact details/
> action menu as second screen from call log and neither of them is good for
> showing this information. Hence, I'd prefer having this after we redesign
> the call directly from call log and then reconsider it at that time. Thanks!

Hi Carrie, 

It looks like this information needs to go in. I have been thinking how to best include this information in the call log and it would be easy if we did not collapse multiple calls. In which case there's no way to include call duration of each single call.

So my suggestion is to have a different approch to show the information, is a bit like IOS does, going to a different screen with the complete detail of that entry including duration of each call, timestamp of each, and a menu with different other options such as adding number to an existing contact or creating a new one. 

This solution would help reduce the amount of info showed in the primary screen, reducing each entry to 2 lines instead of 3 letting more space in the screen to visualize more entries. 

And secondly, it would solve the long press issue to trigger the adding contact action menu.

I know this is a big change but it is something that can be ideally designed and then split into two (plan A and B) to implement it progresively. 

WDYT?
Flags: needinfo?(cawang)
(In reply to Victoria Gerchinhoren [:vicky] from comment #31)
> So my suggestion is to have a different approach to show the information, is
> a bit like IOS does, going to a different screen with the complete detail of
> that entry including duration of each call, timestamp of each, and a menu
> with different other options such as adding number to an existing contact or
> creating a new one. 
> 
> This solution would help to reduce the amount of info showed in the primary
> screen, reducing each entry to 2 lines instead of 3 letting more space in
> the screen to visualize more entries. 
> 

nice approach!, we could consider going to a different screen with the complete detail of
each entry (including timestamp, duration) as a first phase (plan A) and thinking on adding the contact action menu in a second phase (plan B). Let's wait for Carrie's input/specs here. Thanks!
Now the second page triggered from call log is contact details/ action menu. Either of them is suitable for displaying the call duration. Hence, I still suggest redesigning the whole call log interaction and think of all the features here comprehensively. Thanks!
Flags: needinfo?(cawang)
(In reply to Carrie Wang [PTO from 5/14 -23 ] [:carrie] from comment #33)
> Now the second page triggered from call log is contact details/ action menu.
> Either of them is suitable for displaying the call duration. Hence, I still
> suggest redesigning the whole call log interaction and think of all the
> features here comprehensively. Thanks!

Hi Carrie,

Thanks for your input. Just clarifying a bit more the scenario we were proposing, the idea would be to have some kind of icon associated to each call log entry allowing the access to the contact info, something like this:
Phase1
*icon tap -> access contact info (timestamp, duration)
*short tap in the call log entry -> makes a call
*long tap in the call log entry -> launches action menu

Phase2
*icon tap -> accesses contact info (timestamp, duration) and action menu
*short tap in the call log entry -> makes a call

wdyt?
Flags: needinfo?(cawang)
Hi Noemi, 

Yes I understand your point here. Currently if we are going to add any "tap" action on call log, we need approval from legal review. As what I learned from direct call feature, we cannot have two "tap" interaction on each call log item (no matter it's the tap on icon or photo or whatever). So phase 1 doesn't make sense to me. However, I agree with you this is a really important feature and we cannot add everything on the first screen of the call log whenever we need. Hence, I'm thinking about redesigning the action and info in call log (like what you suggest in phase 2, but legally correct). I'll work on this and provide some proposals and have legal review afterwards. Thanks!
Flags: needinfo?(cawang)
Keywords: feature
blocking-b2g: 2.0? → backlog
feature-b2g: --- → 2.1
Considering we'll need UX and more discussion, let's move this to 2.1.
Whiteboard: [tef-triage] → [tef-triage] [priority]
Attached image Visual Spec. Call log (obsolete) — 

    
    

    
  

      
      
      
      

        Attached image
          
        Visual Mockup. CallLog (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Assets. PNG. Call Log Details (obsolete)
        — 
      

    


  
Here I attach the related icons
Assignee: nobody → drs+bugzilla

    
    

    
  
Carrie, how many calls do you think we should display in this list? Assuming some large amount of calls have taken place with this contact, I don't think we should show them all.
Flags: needinfo?(cawang)

    
    

    
  
Comment on attachment 8451533 [details]
Visual Mockup. Contact_Details_Calllog

Vicky, is the incoming/outgoing icon a standardized thing now? I don't think it's really clear which direction is which based on the images. I would think the first is outgoing and the second incoming, but I had to think about that and it wasn't obvious.
Flags: needinfo?(vpg)
No longer blocks: comms_2.0_targeted
Whiteboard: [tef-triage] [priority] → [tef-triage]

    
    

    
  
There is a wiki page for this feature:
https://wiki.mozilla.org/Gaia/Comms/2.1/Call_Length

I wanted to add it to the "See also" field, but Bugzilla won't let me. Filed bug 1036377.

    
    

    
  
(In reply to Doug Sherk (:drs) from comment #44)
> Comment on attachment 8451533 [details]
> Visual Mockup. Contact_Details_Calllog
> 
> Vicky, is the incoming/outgoing icon a standardized thing now? I don't think
> it's really clear which direction is which based on the images. I would
> think the first is outgoing and the second incoming, but I had to think
> about that and it wasn't obvious.

It comes from the call log ones, but a reduced version to have a lighter list. If you don't know here, you won't know in the call log either. But it is something the user for sure learns.
Flags: needinfo?(vpg)

    
    

    
  
(In reply to Doug Sherk (:drs) from comment #45)
> There is a wiki page for this feature:
> https://wiki.mozilla.org/Gaia/Comms/2.1/Call_Length
> 
> I wanted to add it to the "See also" field, but Bugzilla won't let me. Filed
> bug 1036377.

I put it in the "user story" section.
User Story: (updated)
Whiteboard: [tef-triage] → [tef-triage][planned-sprint]
Target Milestone: --- → 2.1 S1 (1aug)
QA Contact: atsai → echang

    
    

    
  


  
As far as I know, everything here is now out of date, so I'm marking it as such. Anyone can feel free to un-obsolete these.

I'm needinfoing both Carol and Fang as Carol would normally cover dialer visual designs, but Carrie said in an email that Fang will be for this.

        Attachment #786247 -
        Attachment is obsolete: true

        Attachment #8451530 -
        Attachment is obsolete: true

        Attachment #8451531 -
        Attachment is obsolete: true

        Attachment #8451533 -
        Attachment is obsolete: true

        Attachment #8451534 -
        Attachment is obsolete: true

        Attachment #8451535 -
        Attachment is obsolete: true

        Attachment #8451572 -
        Attachment is obsolete: true
Flags: needinfo?(fshih)
Flags: needinfo?(chuang)
Flags: needinfo?(cawang)
Whiteboard: [tef-triage][planned-sprint] → [tef-triage][planned-sprint c=5]
Assignee: drs+bugzilla → anthony
Depends on: 998147
Whiteboard: [tef-triage][planned-sprint c=5] → [tef-triage][planned-sprint c=8]
Depends on: 1041601

    
    

    
  


  
Spec updated.

        Attachment #8459451 -
        Attachment is obsolete: true

    
    

    
  
Hi, I think some changes might relate to this bug. Please take a look. Thanks!
https://bugzilla.mozilla.org/show_bug.cgi?id=1045499

    
    

    
  


  
Hi,
The attachment is the "Call_log_info" Visual spec.
Please let me know if you have any question on the spec.Thanks!
Flags: needinfo?(fshih)
Flags: needinfo?(chuang)

    
  
Depends on: 1047351

    
  
Depends on: 1047353

    
  
Keywords: meta

    
    

    
  
Is there any reason why we only show the call log for today but not for the x number of last calls?
Flags: needinfo?(chuang)
Whiteboard: [tef-triage][planned-sprint c=8] → [tef-triage][planned-sprint][in-sprint=v2.1-S1]
Target Milestone: 2.1 S1 (1aug) → 2.1 S2 (15aug)
QA Whiteboard: [COM=Gaia::Dialer]

    
    

    
  
Hi Henrik,
Because we'll always have the call # on the button for dialing out. It's redundant to have the same # repeating on the screen. Especially in the unknown number situation (please see "Calllog_Details_existing contact2.jpg" from attachment), we have the unknown # on the header, there will be 3 of the same information on the page.
That's why I removed the call # in the call log list.

Thanks!
Flags: needinfo?(chuang)

    
    

    
  
Carol, I think you misunderstood my question. I didn't talk about the call number but the call duration. As seen in the attachment you list 'TODAY', but what when I called this person a day or more ago? Are we going to add a more button, to even display those older call entries?

    
    

    
  
Hi Carrie,
Could you explain this interaction for Henrik? Thanks!
Flags: needinfo?(cawang)

    
    

    
  
Hi Henrik, 


I think the rule of dividing the call logs is based on the call types and call stamp.
For example, if Carol had two successive calls with me, one is a missed call and one is an incoming call and I've answered it, then that will be two different call logs and we only display the call info which is related to that call log. Hence, we will not show the old history with that contact in call info page, that will be in other call logs. Thanks!
Flags: needinfo?(cawang)

    
    

    
  
Henrik: For now, we are not gonna do that. The way we store calls does not permit to list all the calls from one number. If we have a good UI for that, we can do it in another iteration.

    
  
Status: NEW → ASSIGNED

    
  
Status: ASSIGNED → NEW
Assignee: anthony → nobody

    
    

    
  
Sounds good, Anthony.
QA Contact: echang → jlorenzo
Flags: in-moztrap?(jlorenzo)
Whiteboard: [tef-triage][planned-sprint][in-sprint=v2.1-S1] → [tef-triage][planned-sprint]
Target Milestone: 2.1 S2 (15aug) → 2.1 S3 (29aug)

    
    

    
  
This feature has not been committed to 2.1 on the QA side. Removing in-moztrap.
Flags: in-moztrap?(jlorenzo)
QA Contact: jlorenzo
Assignee: nobody → anthony

    
    

    
  
(In reply to Johan Lorenzo [:jlorenzo] from comment #60)
> This feature has not been committed to 2.1 on the QA side. Removing
> in-moztrap.

This feature is targeted for 2.1, in fact it has the flag feature-bg2 set to 2.1, setting ni to Wilfred to confirm it.
Flags: needinfo?(wmathanaraj)

    
    

    
  
(In reply to Maria Angeles Oteo (:oteo) from comment #61)
> (In reply to Johan Lorenzo [:jlorenzo] from comment #60)
> > This feature has not been committed to 2.1 on the QA side. Removing
> > in-moztrap.
> 
> This feature is targeted for 2.1, in fact it has the flag feature-bg2 set to
> 2.1, setting ni to Wilfred to confirm it.

On QA side, maybe Eric can support. We'll confirm and update soon.

    
    

    
  
Wilfred, should we include the Loop call buttons on the call information page?
Depends on: 1054995
Flags: in-moztrap?(echang)
QA Contact: echang
Whiteboard: [tef-triage][planned-sprint] → [tef-triage][planned-sprint][2.1-feature-qa+]
Depends on: 1059336

    
    

    
  
(In reply to Doug Sherk (:drs) from comment #63)
> Wilfred, should we include the Loop call buttons on the call information
> page?

I talked with Wilfred about this on IRC. He says we'll handle this in a later release; possibly 2.2.

    
    

    
  
Removing 2.1 flag per comment #65.
feature-b2g: 2.1 → ---

    
    

    
  
Wilfred or Bhavana, please re-set the 2.1 flag, since I misread Doug's comment #65. I am not sure why I can remove a flag and not re-set it. We may want to check the permissions there: chances are if I can't do one I shouldn't be able to do the other. Though I should (and was?) previously able to set this flag for backlog planning and such. Thanks!
Flags: needinfo?(bbajaj)
feature-b2g: --- → 2.1
Flags: needinfo?(bbajaj)

    
    

    
  
(In reply to Stephany Wilkes from comment #67)
> Wilfred or Bhavana, please re-set the 2.1 flag, since I misread Doug's
> comment #65. I am not sure why I can remove a flag and not re-set it. We may
> want to check the permissions there: chances are if I can't do one I
> shouldn't be able to do the other. Though I should (and was?) previously
> able to set this flag for backlog planning and such. Thanks!

Hey Steph,

I reset the flag.

Might want to check with Kevin Hu on you not being able to reset ? Ni him here anyways.
Flags: needinfo?(khu)

    
    

    
  
Resolving as all of the blocking bugs have been resolved. Bug 1041601 is not in the scope of this feature and will come later.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Depends on: 1060801

    
    

    
  
(In reply to Stephany Wilkes from comment #67)
> Wilfred or Bhavana, please re-set the 2.1 flag, since I misread Doug's
> comment #65. I am not sure why I can remove a flag and not re-set it. We may
> want to check the permissions there: chances are if I can't do one I
> shouldn't be able to do the other. Though I should (and was?) previously
> able to set this flag for backlog planning and such. Thanks!

Since you're doing the project management, I think you should have this permission. I already added you to the group that can configure this flag. Thank you.
Flags: needinfo?(khu)

    
    

    
  
Verified User story is fixed. Call information page shown with call duration & detail.

Gaia      2be78d83a760fa3b9638fe51c266b442d14597f1
Gecko     https://hg.mozilla.org/mozilla-central/rev/1db35d2c9a2f
BuildID   20140831160203
Version   34.0a1
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230

1061122 [Calllog][Dialer] Unable to make call when tapping on call log items 
1061120 [Calllog][Dialer] Time duration format is not showing 'min' or 's' in 'Call Information'
Status: RESOLVED → VERIFIED

    
    

    
  
Flame
2.1
Gecko-4d85c35
Gaia-561f053

1061145 [Calllog][Dialer] In "Call info" screen the text lengthens when user taps in scrolls.
1061149 [Calllog][Dialer] Phone number is showed with different color in incoming/out/missed calls (in "Call info" screen)

    
    

    
  
(In reply to Loli (:lolimartinezcr) from comment #72)
> Flame
> 2.1
> Gecko-4d85c35
> Gaia-561f053
> 
> 1061145 [Calllog][Dialer] In "Call info" screen the text lengthens when user
> taps in scrolls.
> 1061149 [Calllog][Dialer] Phone number is showed with different color in
> incoming/out/missed calls (in "Call info" screen)

Also:
1061153 [Calllog][Dialer] Time format is not showing 'PM' or 'AM' in 'Call Information'

    
    

    
  
(In reply to Loli (:lolimartinezcr) from comment #73)
> (In reply to Loli (:lolimartinezcr) from comment #72)
> > Flame
> > 2.1
> > Gecko-4d85c35
> > Gaia-561f053
> > 
> > 1061145 [Calllog][Dialer] In "Call info" screen the text lengthens when user
> > taps in scrolls.
> > 1061149 [Calllog][Dialer] Phone number is showed with different color in
> > incoming/out/missed calls (in "Call info" screen)
> 
> Also:
> 1061153 [Calllog][Dialer] Time format is not showing 'PM' or 'AM' in 'Call
> Information'

And
1061184 [Calllog][Dialer] Unable to send message when tapping on call log items

    
    

    
  
Eric, Loli,

When you list bugs like this, please write them in the format "bug ******" instead of just "******". Bugzilla adds a link to any bugs formatted this way. Example:

No formatting:
1061184 [Calllog][Dialer] Unable to send message when tapping on call log items

With formatting:
bug 1061184 [Calllog][Dialer] Unable to send message when tapping on call log items
Flags: needinfo?(lolimartinezcr)
Flags: needinfo?(echang)

    
    

    
  
Also, you can set them as blockers for the original issue, since they're regressions caused by it.
Blocks: 1061122, 1061120, 1061145, 1061149, 1061153, 1061184

    
  
No longer blocks: 1061122

    
    

    
  
(In reply to Doug Sherk (:drs) from comment #75)
> Eric, Loli,
> 
> When you list bugs like this, please write them in the format "bug ******"
> instead of just "******". Bugzilla adds a link to any bugs formatted this
> way. Example:
> 
> No formatting:
> 1061184 [Calllog][Dialer] Unable to send message when tapping on call log
> items
> 
> With formatting:
> bug 1061184 [Calllog][Dialer] Unable to send message when tapping on call
> log items

OK!

bug 1061145 [Calllog][Dialer] In "Call info" screen the text lengthens when user taps in scrolls.
bug 1061149 [Calllog][Dialer] Phone number is showed with different color in incoming/out/missed calls (in "Call info" screen)
bug 1061153 [Calllog][Dialer] Time format is not showing 'PM' or 'AM' in 'Call Information'
bug 1061184 [Calllog][Dialer] Unable to send message when tapping on call log items
Flags: needinfo?(lolimartinezcr)

    
  
Depends on: 1061463

    
  
Depends on: 1062799
Flags: needinfo?(wmathanaraj)
Depends on: 1121652
No longer depends on: 1121652
See Also:  → 1121652
blocking-b2g: backlog → ---

          tracking-b2g:
          --- → backlog

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: