Closed Bug 1023246 Opened 10 years ago Closed 10 years ago

[Flame][v1.4][Gaia::Dialer]The contact’s photo is shown incompletely in the call log edit screen.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
2.1 S1 (1aug)

People

(Reporter: greatwall2686, Assigned: paco)

References

Details

(Whiteboard: torch [planned-sprint])

Attachments

(2 files)

* Description:
The contact’s photo is shown incompletely in the call log edit screen. 
* Precondition:
  There is contact A which has a photo in the phone book.

* Reproduction steps:
  1. Make a MO call to contact A.
  2. Open dialer app and select “edit” icon in the right top corner.
  3. Check the displayed.
* Expected result:
The contact photo and phone number is shown correctly.
* Actual result: 
The contact’s photo is cut off in the right screen.

* Reproduction build:(Buri - Firefox OS V1.4 inside)
 - Gaia      17b102ee8d9a724b62285547cc5f1c5d30bfb01c
 - Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/95be84248033
 - BuildID   20140520000201
 - Version   30.0

* Reproduction Frequency
  - 100%
Dialer issue.
Component: Gaia::SMS → Gaia::Dialer
Flags: needinfo?(etienne)
I'm pretty sure this isn't new.
Rik do you know where to dupe?
Flags: needinfo?(etienne) → needinfo?(anthony)
Can't find a dupe but yeah this is a pretty old issue.
Flags: needinfo?(anthony)
In SMS we just hide the pictures in edit mode :) I'm quite sure this is how it should be here too.
Summary: [Flame][v1.4][Gaia::SMS]The contact’s photo is shown incompletely in the call log edit screen. → [Flame][v1.4][Gaia::Dialer]The contact’s photo is shown incompletely in the call log edit screen.
Assignee: nobody → pacorampas
Whiteboard: torch → torch [planned-sprint]
Target Milestone: --- → 2.1 S1 (1aug)
Attached file patch in github
Attachment #8460075 - Flags: review?(anthony)
Could you check with the devtools that we have the same amount of reflows before and after this change? And that the duration of reflow is similar? I'm afraid this would slow down the interaction here. All the other changes are currently done with transforms.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
The number of reflows is the same. There is only one reflow between default view and edit view. But, the time of the reflows is different.

1- With display: none
 1.1- From default view to edit view reflow: 854.38ms
 1.2- From edit view to default view reflow: 640.62ms


2- With transform (without my patch)
 2.1- From default view to edit view reflow: 986.35ms
 2.2- From edit view to default view reflow: 533.42ms

I have tested it on flame and with: make reference-workload-x-heavy.
1- With display: none
1.1- From default view to edit view
reflow: 842.24ms
reflow: 836.69ms
reflow: 887.36ms
reflow: 840.56ms
reflow: 842.32ms
AVERAGE: 849.83ms

1.2- From edit view to default view
reflow: 599.6ms
reflow: 589.67ms
reflow: 583.85ms
reflow: 587.22ms
reflow: 587.25ms
AVERAGE: 589.52ms

2- With transform (without my patch)
2.1- From default view to edit view
reflow: 997.64ms
reflow: 990.9ms
reflow: 990.98ms
reflow: 995.18ms
reflow: 1011.72ms
AVERAGE: 997.28ms

2.2- From edit view to default view
reflow: 544.07ms
reflow: 529.47ms
reflow: 532.86ms
reflow: 570.27ms
reflow: 534.56ms
AVERAGE:542.25ms
I have also changed the patch because I had forgotten delete the "transform" of the selector: .recents-edit .pack-end
Wait, I did not see that this was for 1.4 only. I don't think we should fix it for 1.4 unless this becomes a 1.4 blocker.

Sorry to have asked all those measurements for nothing.
Attachment #8460075 - Flags: review?(anthony)
I'm going to close this as wontfix because it is 1.4 only. If anyone thinks we should fix it for 1.4, please reopen and ask for a blocker status.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.