1190980 - [Messages][319MB] Duration of the copy paste menu triggered from "To:" field is too short to access

Status: RESOLVED WONTFIX

(Core :: DOM: Selection, defect, P3)

Description

[Nicholas Nelson [:NicholasN]]

Attachment: logcat_messages.txt

Description:
The user cuts or copies a phone number or name from an app outside of messages (dialer, browser, contacts) and then opens Messages. They perform a long tap on the "To:" field, but there is no response while the keyboard is up. If the user taps the middle of the screen to dismiss the keyboard and then long taps the "To:" field, the cut/copy/paste prompt very briefly flashes on the screen and the keyboard comes back up. Text selected in the message body field can be pasted into the "To:" field, and text typed directly into the "To:" field can be cut/copied and re-pasted, so this appears to only affect text from external apps.


Repro Steps:
1) Update a Flame to 20150804030213
2) Go to Contacts, Browser, or Dialer and copy or cut a selection of text.
3) Open messages and perform a long press on the "To:" field.


Actual:
User cannot paste text into "To:" field.


Expected:
User can paste text into "To:" field.


Notes:

Environmental Variables:
Device: Flame 2.5
Build ID: 20150804030213
Gaia: caba8b26c52d3c771e9ea6fe288acdaf74c7707e
Gecko: 5b54831761b1
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0


Repro frequency: 5/5
See attached: video clip, logcat

Comment 1

[Nicholas Nelson [:NicholasN]]

Issue does not occur on Flame 2.2

Flame 2.2

Actual Result

Text can be pasted in "To:" field after keyboard is dismissed.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150804032504
Gaia: f8b119ac30e97df991c97682ac4d4f9ca22e1793
Gecko: 0c7a85251e10
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Functional regression of a common user case

requesting a window.

Comment 3

[Johan Lorenzo [:jlorenzo]]

Comms triage: Functional regression from 2.2.

Comment 4

[Francisco Jordano [:arcturus] [:francisco]]

I cannot reproduce in aries with the foxfood build.

Comment 5

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

I know the cut&paste functionality was just revamped (see bug 1124074 and dependencies). Could this be the reason ?

We do really weird things in this panel but just couldn't find time to refactor it yet.

Comment 6

[Duane Dixon [:ddixon]]

Mozilla Inbound Regression Window

Last Working

Device: Flame 2.5
BuildID: 20150727090146
Gaia: 4e3e21a4ba3f188b45623ee2297f21d0791f8667
Gecko: 34ade6cc41e1
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

First Broken

Device: Flame 2.5
BuildID: 20150727091342
Gaia: 302a448729ff2b336581cf94b66327ea836294c7
Gecko: 2ea0af589ebd
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Last Working Gaia and First Broken Gecko
Issue DOES occur here:
Gaia: 4e3e21a4ba3f188b45623ee2297f21d0791f8667
Gecko: 2ea0af589ebd

Last Working Gecko and First Broken Gaia
Issue DOES NOT occur here:
Gaia: 302a448729ff2b336581cf94b66327ea836294c7
Gecko: 34ade6cc41e1

Mozilla Inbound Pushlog (Gecko): 
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=34ade6cc41e1&tochange=2ea0af589ebd

Possible Cause: 

Bug 1158735 - FetchEvent.client asserting in onFetch when there's no document

Bug 1024056 - Design and implement lexical analyzer to be used in any parser code

Comment 7

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

Honza and Dimi, can you take a look at this? It looks like either the work done for bug 1158735 or for bug 1024056 caused this to occur.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

Does sms or sww.js use fetch event .client attribute?  I'm having trouble searching the github repo.

Comment 9

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

We don't use service workers at all yet; we do have sww.js in the code base but only as a preparation task for future work, it's not loaded anywhere yet.


So I doubt those bugs are the reason.

However I do see bug 1172382 in the push log... which is IMO directly related as I said in comment 5 :)

Ting-Yu, maybe you could have a look at this ?

Comment 10

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

This is likely caused by the new AccessibleCaret. However, I am not able to check this issue today. Will do early next week.

Comment 11

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Working on patches to fix this issue. Gaia has a bug to sync the "cut-or-copied" state between apps. Gecko has a problem to send the message to Gaia on a already-focused empty editing field like "To:" in message app.

Comment 12

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

Ting-Yu, should we move this bug to a separate Component ?

Comment 13

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Julien, I think this bug should remain on SMS component. I hope someone who has better understanding of message app could help diagnose the "To:" field.

After bug 1195672 landed, long tap on an empty editable should correctly bring up the paste shortcut icon. However, the "To:" field is more than a simple editable and focusable field. While inspecting from WebIDE, I found that:

1) If the focus is not yet on "To:", single tapping onto it will get <span class="recipient invalid">, which is focusable and editable.
2) However if the focus is already on "To:", single tapping onto it will get <section id="messages-recipients-list" class="singleline">, which is not focusable. 
3) If the focus is already on "To:" and then long tap the space bar to hide the keyboard, single tapping onto "To:" will get the unfocusable <section> as well like in 2). 

The above observations apply to long tapping as well. To show the paste shortcut by long tap, an empty field must be both focusable and editable. Thus no paste shortcut will show in case 2) nor in case 3).

Comment 14

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

QA: can you please check the various cases from comment 13 in a 2.2 version, and report how the paste functionality works ?

If all these cases used to work in 2.2, then I think something regressed elsewhere. Otherwise maybe the current behavior is not a regression anymore (after bug 1195672 that has not landed yet but should soon).

Thanks !

Comment 15

[Steve Chung [:steveck]]

I think the steps in comment 13 is still reproducible in 2.2. There's actually 2 cases:
(1) Focus on to field and long tap on to field.
(2) Focus on other widgets and long tap on to field.

The main reason we nominated this one as 2.5 blocker is because the copy paste menu didn't show up correctly in (1), and 2.2 works fine. But for (2) menu never show up the no matter in 2.2 or master. So if QA verify the menu could be displayed in (1) after bug 1195672, we should remove the 2.5 blocker because it's not regression.

Comment 16

[Duane Dixon [:ddixon]]

Bug 1195672 needs to be uplifted to 2.2 in order for QA to test what is described in Comment 14.

Comment 17

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Bug 1195672 cannot be uplifted to 2.2 since the fix is against the new caret implementation on the master. 2.2 uses the old caret implementation.

Comment 18

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

(In reply to Duane Dixon [:ddixon] from comment #16)
> Bug 1195672 needs to be uplifted to 2.2 in order for QA to test what is
> described in Comment 14.

Sorry for the misunderstanding.
We needed to wait that Bug 1195672 lands on master to test the behavior with this bug.
And compare against the behavior we have in v2.2.

Thanks !

Comment 19

[Duane Dixon [:ddixon]]

I tested this issue by copying a number in the Contacts app, then attempting to paste in the "To:" field of the Messages app.  I utilized Comment 13 for collecting the information below.  

1) If the focus is not yet on the "To:" field:
 
Flame 2.5 Results:
Long pressing the "To:" field causes paste icon to appear then disappear after 1-2 seconds. 

Flame 2.2 Results:
Long pressing the "To:" field causes paste icon to appear then disappear after about 4 seconds. 
------------------------------------------------------------------------------------------------------------
2) If the focus is already on "To:", single tapping onto it will: 

Flame 2.5 Results: 
The paste icon will NOT appear, the keyboard hides, and long pressing when will cause the keyboard to disappear the pop up again. 

Flame 2.2 Results: 
The paste icon will NOT appear, the keyboard remains up with single tap and when user long presses the "To:" field. 
------------------------------------------------------------------------------------------------------------
3) If the focus is already on "To:" and then long tap the space bar to hide the keyboard, single tapping onto "To:" will get the unfocusable <section> as well like in 2). 

Flame 2.5 Results: 
Long tapping on space bar hides the keyboard. The paste icon will NOT appear in the "To:" field if the user long presses or single taps.

Flame 2.2 Results: 
Long pressing on space bar hides the keyboard. If the user then long presses the "To:" field, the paste, cut, copy, and highlight icons WILL appear and remain.   
------------------------------------------------------------------------------------------------------------

Environmental Variables:

Device: Flame 2.5
Build ID: 20150825210535 (latest engineering build)
Gaia: c1ae9f02f2a9cfb89bf67aeea97e467c41c3362c
Gecko: f61c3cc0eb8b7533818e7379ccc063b611015d9d
Version: 43.0a1 (Master)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0
-----------------------------------------------------------------
Device: Flame 2.2
Build ID: 20150826032503
Gaia: 335cd8e79c20f8d8e93a6efc9b97cc0ec17b5a46
Gecko: 1effc4cb6414
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 20

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

Hey Tim,

I wonder if you can help explaining case 2 from comment 19 from the InputManager point of view? 

I'm sure we do complicated things in this panel but we didn't change anything for some time so if the behavior changed it means something changed in Gecko or the System app. Maybe we could workaround in the SMS application but also maybe there is an issue elsewhere. So I'd like that you check the case 2 first (case 3 is maybe more related to the copy/paste feature).

Thanks!

Comment 21

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Re comment 20:

The case 2 and case 3 from comment 19 on flame 2.5 (master) should be a regression by bug 1195672. After bug 1197739 is landed on m-c, the behavior should be the same as it is on 2.2.

Comment 22

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Input management and selection/copy-paste widget management is entirely separate, FYI.

Comment 23

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

(In reply to Tim Guan-tin Chien [:timdream] (slow response; please ni? to queue) from comment #22)
> Input management and selection/copy-paste widget management is entirely
> separate, FYI.

Yes I know, but case 2 was only input management from what I understood, that's why I asked.

Let's wait for bug 1197739 then.

Comment 24

[Steve Chung [:steveck]]

Hi Duane,

Could you please verify the to filed behavior again after bug 1197739 landed? If current master behavior is as same as 2.2, we can remove the 2.5 block if it's not regression.

Comment 25

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Setting qawanted flag to check comment 24.

Comment 26

[Duane Dixon [:ddixon]]

I'm still seeing the same results in both branches (2.2, 2.5) even after bug 1197739 has landed.  The results I'm seeing are as described in Comment 19 which are: 

1) If the focus is not yet on the "To:" field:
 
Flame 2.5 Results:
Long pressing the "To:" field causes paste icon to appear then disappear after 1-2 seconds. 

Flame 2.2 Results:
Long pressing the "To:" field causes paste icon to appear then disappear after about 4 seconds. 

Environmental Variables:
Device: Flame 2.5
Build ID: 20150903030230
Gaia: 29f363d6236bf7db8141d7a1f1185a1dcd809bf7
Gecko: a6786bf8d71d4cf40c3d40e06d8e3c9866863475
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (Master)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Device: Flame 2.2
BuildID: 20150901092824
Gaia: 335cd8e79c20f8d8e93a6efc9b97cc0ec17b5a46
Gecko: c03e2bc6a3a4
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Side-by-Side Video: 
https://www.youtube.com/watch?edit=vd&v=uJ8tY5j7gmw

Comment 27

[Steve Chung [:steveck]]

Sorry if my description is not clear, the landing of bug 1197739 should address the regression in comment 19 case 2 and case 3, not for case 1. If we can prove both 2.2 and 2.5 have the same behavior in case 1(despite the different of the menu dismiss duration)/case 2/case 3, then we can remove the blocker since it's not a regression.

For the copy paste menu duration:
Hi Ting-Yu, do you have any idea about the menu duration changes from 2.2? In master it did disappear earlier than 2.2 but I'm not sure if it's expected result.

Comment 28

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

The duration should be 3 seconds for both 2.2 and 2.5. However due to internal caret update process triggered by reflow which might reset the timer after the long press, 3 ~ 4 seconds duration is reasonable. Icon disappearing in less than 3 seconds is a bug.

I cannot reproduce on my 2.5 flame as describe in comment 19 that the icon disappears after 1 ~ 2 seconds. If you can still reproduce this, please file a separate bug. Thank you.

Comment 29

[Duane Dixon [:ddixon]]

I have retested the behavior in the latest 2.5 and 2.2 builds on Flame.  Case 2 and Case 3 (described in Comment 19) no longer reproduce in Flame 2.5.  Further, both branches reveal the correct behavior.  However, I am still seeing Case 1 reproduce in 2.5; the paste menu duration is inconsistent.  I have not filed a separate bug for that yet as Comment 28 suggests.   

Device: Flame 2.5
Build ID: 20150908063734
Gaia: b81185d30e548f782770b852473ffb53c641a490
Gecko: b23b2fa33a9dcda59dbbca1d157eca3c32c5b862
Version: 43.0a1 (Master)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Device: Flame 2.2
Build ID: 20150908032505
Gaia: 335cd8e79c20f8d8e93a6efc9b97cc0ec17b5a46
Gecko: 96170c571381
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 30

[Steve Chung [:steveck]]

Renominate the blocking request because it seems not necessary for blocker anymore.

Once we create the bug for menu duration inconsistency per comment 29, can we remove the blocker since the behavior is the same in 2.2/2.5? Just a reminder that the recipient field is not totally disabled for copy/paste menu currently.

Comment 31

[Johan Lorenzo [:jlorenzo]]

Comms triage: Case 1 represents a regression that will likely annoy an end-user. This case is a blocker then. No patch was attached to this current bug, so we can use it to address case 1.

Comment 32

[Steve Chung [:steveck]]

Although I feel it's better to create separated bug, I'm fine if you prefer to create another bug for the copyable to field in general. Rename the title to match the actual problem we want to addressed for 2.5.

Hi Duane,
I can reproduce this issue but with really low rate :/ Could you please give some more information about the reproduce rate and steps? Thanks.

Comment 33

[Steve Chung [:steveck]]

Need more information about the reproduce step and rate about this issue since Ting-Yu is unable to reproduce this issue.

Comment 34

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

Honestly I don't reproduce this properly. We may have a bug here, but it's really difficult to produce and I think it's more general than just SMS.

For example the behavior is quite similar in Google's search box (the one on google website, not the rocket bar). At first everything seems to work fine, but when we play with the input box for some time, longpressing, focussing, etc, at one point the "paste" icon disappears and it's difficult to make it show again.

So I think it's a general bug with contenteditable elements. Moving to Core::Selection. Still I'm not sure this should be a blocker.

Comment 35

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

What do you think Ting-Yu ?

Comment 36

[Pi Wei Cheng [:piwei] (inactive)]

Has it been decided that comment 0 STR is not an issue? Because I can still reproduce it - with focus on To field and keyboard up, long pressing To field does NOT give me a paste menu.

Comment 19 case 1 appears to be memory related. I can reliably reproduce the issue where paste menu disappears within 1 second if I set Flame memory to 319MB. I can NOT reproduce this issue if I set Flame memory to 512MB, nor on Aries. The issue is not limited to Messages app while in 319MB as I can repro the same thing on Contacts app. But it doesn't repro on Rocketbar.

Comment 0 STR is reproducible on:
Device: Flame 2.5 (319/512MB memory)
BuildID: 20151006030203
Gaia: 60cdaa3d3424db3432dc903e7f9c6c8fa099c06d
Gecko: 3edc8d4a1e198314f5d7ebd2967b85842beef602
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Aries 2.5
BuildID: 20151007142909
Gaia: 77d463a009a1425e413edaae92b237e116708560
Gecko: 263526a3368d6e94f31ff526b9f5beba46f56347
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

------

Comment 19 case 1 is reproducible on:
Device: Flame 2.5 (319MB memory)
BuildID: 20151006030203
Gaia: 60cdaa3d3424db3432dc903e7f9c6c8fa099c06d
Gecko: 3edc8d4a1e198314f5d7ebd2967b85842beef602
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Comment 37

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

It is important to note that 319MB Flame is still the baseline for QA so issues cropping up there are still valid until a switch is announced.

Comment 38

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

So I get the paste icon merely focusing the input. Then longpressing works as well ? Am I doing something wrong?

Comment 39

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

I'm talking about comment 0 case.

Comment 40

[Steve Chung [:steveck]]

Thanks Pi Wei! I never know it's related to the memory, so I just have a question about the 319MB Flame: Have you tried it on 2.2 as well?

About the comment 0, menu will not be displayed if you enter the new compose view and longpress on the tofield immediately. It's known issue in 2.2/2.5 that longpress on the tofiled which is already focused could not trigger the menu properly because of the complicate tofield behavior. If you enter the compose view with draft or click other place to force the cursor in tofield disappeared, the longpress gesture for menu will work as expected.

Comment 41

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Re comment 34: 
I guess the paste bubble is timeout after 15 seconds. To show the paste bubble again, you could single tap on the blue caret, or long press on an empty input box. FYI, this is specified in page 8 "FxOS 2.2 UX Spec_Text Selection_v1.4.pdf" in bug 921965.

Re comment 38:
If the copy or cut operation is performed within 15 seconds, focusing on the input should show the bubble immediately. Long pressing on an empty field should bring up the paste bubble as well. Comment 40 is the known issue though.

BTW, I found that I cannot trigger long press in Google's search box. Filed bug 1212700.

Comment 42

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Re comment 36:

After adjusting my flame to 319 mb by the instructions in [1], I'm still unable to reproduce Comment 19 case 1 that caret disappears within 1 second :(

https://developer.mozilla.org/en-US/Firefox_OS/Phone_guide/Flame/Updating_your_Flame#RAM_adjustment

Comment 43

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

(In reply to Ting-Yu Lin [:TYLin] (UTC+8) from comment #41)
> Re comment 34: 
> I guess the paste bubble is timeout after 15 seconds. To show the paste
> bubble again, you could single tap on the blue caret, or long press on an
> empty input box. FYI, this is specified in page 8 "FxOS 2.2 UX Spec_Text
> Selection_v1.4.pdf" in bug 921965.

I don't really like that we have different behaviors before/after 15sec but I guess it was discussed before already, I can ask on that bug instead. Not related to this bug anyway.

But I see on the spec that simply focussing an empty input should not show the paste icon. However I see it in SMS. I actually prefer this so I don't mind ;) but maybe you'd like to look at it.

Comment 44

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

(In reply to Julien Wajsberg [:julienw] (away Oct 1st, 2nd) from comment #43)
> I don't really like that we have different behaviors before/after 15sec but
> I guess it was discussed before already, I can ask on that bug instead. Not
> related to this bug anyway.

I'm not a fan of this, either. If you feel it's better to always display the bubble without 15 seconds timeout, please do so. We could invite UX team to revisit the spec.

> But I see on the spec that simply focussing an empty input should not show
> the paste icon. However I see it in SMS. I actually prefer this so I don't
> mind ;) but maybe you'd like to look at it.

You're right. We do not follow the spec here. Distinguishing between single tap and long tap on an empty input makes the implementation more complex with little gain of usability.

Comment 45

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I can reproduce comment 0 which on flame today! Let me re-iterate the steps.

1. Adjust the memory to 319 MB by the instructions in [1]. This a critical step.
2. Open message app to compose a new message.
3. Type some text on message body, and copy an arbitrary word.
4. Long press on "To:" to show the paste bubble.
5. Long press on the space bar to hide keyboard.
6. Long press on "To:" again. 

Expected results:
Since the "To:" is empty, the paste bubble should show.

Actual results:
1) If you long press very close to the right side of the "To:" label, the paste bubble will hide immediately after your finger leaves the screen.
2) If you long press on the center of the empty "To:" field, both the paste bubble and the keyboard will hide after your finger leaves the screen.

What I found is that, APZ sends another single tap event which consists of mouse move, mouse down, and mouse up after the touch end event at step 6. Morris told me that step 6 might hit the APZ content response timeout on a 319 MB flame since it runs more slowly than a 512 MB flame. I double "apz.content_response_timeout" to 600, and the issue is gone.

[1] 
https://developer.mozilla.org/en-US/Firefox_OS/Phone_guide/Flame/Updating_your_Flame#RAM_adjustment

Comment 46

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Per comment 36, this issue can be reproduced only on 319 MB devices, and the possible root cause had been analyzed in comment 45. 

Since we are moving to 512 MB devices, I'd suggest we unblock this bug for 2.5 release.

Comment 47

[Johan Lorenzo [:jlorenzo]]

This sounds reasonable. Renom'ing it for the triage committee to decide if we block on it or not.

Comment 48

[Mahendra Potharaju [:mahe]]

Removing the nomination for 2.5 based on device affected.

Comment 49

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 24 weeks.