Closed Bug 1007019 Opened 10 years ago Closed 10 years ago

[tarako] Facebook crashes whenever trying to upload a photo

Categories

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:1.3T+, b2g-v1.3T fixed)

RESOLVED FIXED
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- fixed

People

(Reporter: jcheng, Assigned: ying.xu)

References

Details

(Whiteboard: [sprd313365][partner-blocker])

Attachments

(6 files)

i am on build id: 20140504013000
PAC version is 0429

STR:
1. launch facebook app
2. click on Photo
3. tap Gallery
4. Select a photo taken by the phone's camera by tapping on a photo
5. at the crop screen before i can press DONE, Facebook crashed and i was taken to homescreen

this reproduces every time i try to do the actions above
blocking-b2g: --- → 1.3T?
(Note that the step 5 should be confirm screen, not crop screen.)

David, I am not entirely sure how Facebook pick the image after inspecting the UI. Don't see a <input type=file> but the button doesn't call my function when I overwrite window.MozActivity with it either.

Anyhow, it would be better to tell why picker and facebook are both killed in this case.
Flags: needinfo?(dflanagan)
triage: 1.3T+ as Facebook is our top 3rd party app
blocking-b2g: 1.3T? → 1.3T+
Justin will investigate
Assignee: nobody → jdarcangelo
I think this is a dupe of 1005792, which is a regression I caused recently.
There is a fix in 1006882.
Flags: needinfo?(dflanagan)
Closing this as a duplicate of 1006882. The patch in 1006882 is pending review and has been tested to verify that it does resolve this issue.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
REOPENING. 
base on the latest partner image 0512PAC and build ID: 20140518164003, i still cannot upload a photo from gallery (image was taken by the tarako camera) to my facebook.
ni? djf
Status: RESOLVED → REOPENED
Flags: needinfo?(dflanagan)
Resolution: DUPLICATE → ---
Taking this bug to investigate.

Setting qawanted to see if anyone can tell me:

1) How do I install the Facebook app onto a Tarako engineering build?  Can I get it from the marketplace?

2) Do we have a test Facebook account I can use to try this out on?  Or do I need to create one for myself?

Setting needinfo for Joe to ask whether he can reproduce the other bugs that were dupes of this one. If you take a photo with the Tarako camera and then try to attach it to an MMS, do you see a crash then? If you put the 3mp image from bug 1005792 on your sdcard can you cause the crash when attaching it to MMS or email?
Assignee: jdarcangelo → dflanagan
Flags: needinfo?(dflanagan) → needinfo?(jcheng)
Keywords: qawanted
David: Yes, you can get the app from the Marketplace. I believe its just a "hosted" app that points to FB's mobile site. FWIW, I was also able to reproduce this issue prior to the patch in Bug 1006882 using this site: http://m.imgur.com/upload -- so, you can probably check and see if it still crashes using the uploader there as well.
QA Contact: rkuhlman
> 2) Do we have a test Facebook account I can use to try this out on?  Or do I
> need to create one for myself?

We've had no luck using Facebook's built in test accounts so we had to each make our own for the purposes of testing.
I would be ecstatic to learn of a way to use the built in type.

Removing qawanted as the first two questions have an answer.
Keywords: qawanted
(In reply to David Flanagan [:djf] from comment #7)
> Taking this bug to investigate.
> 
> Setting qawanted to see if anyone can tell me:
> 
> 1) How do I install the Facebook app onto a Tarako engineering build?  Can I
> get it from the marketplace?
> 

yes you may download from the marketplace -> lifestyle category

> 2) Do we have a test Facebook account I can use to try this out on?  Or do I
> need to create one for myself?

i use my own account

> Setting needinfo for Joe to ask whether he can reproduce the other bugs that
> were dupes of this one. If you take a photo with the Tarako camera and then
> try to attach it to an MMS, do you see a crash then? If you put the 3mp
> image from bug 1005792 on your sdcard can you cause the crash when attaching
> it to MMS or email?

i can attach images to MMS and i can also attach the 3MP image from bug 1005792 as well. Thanks
Flags: needinfo?(jcheng)
hmmm i rebooted my phone and now i can finally attach an image to facebook but facebook still crash easily when i try to attach an image
I've updated my tarako with the latest base image from Spreadtrum and flashed the nightly gecko/gaia build. I cannot reproduce this bug reliably enough to investigate it.

The very first time I tried attaching an image I saw facebook and the gallery app crash.  I think that was after flashing the spreadtrum base image before updating gecko and gaia to the nightly build.  It was also a first run situation so the gallery app was probably busy scanning photos (and therefore using extra memory) when the crash occurred.

Since then, I've never seen facebook crash. Most of my attempts to attach an image are successful. Some of them (10 or 15% of the time, maybe) do not complete: the gallery app must OOM before it can pass the photo back to facebook, and facebook just sits there like I never clicked the attach photo button.

Once I had a situation where after I'd selected the photo I returned to the facebook app, but it was just blank gray. Like it was reloading and the server was down or something. I suppose it could have been a bad network connection.  It didn't seem like it had crashed, but it wasn't responding either.

In order to load gallery more heavily, I've tried going to camera, taking 10 photos and then opening facebook and trying to attach a photo while the gallery is still scanning photos.  Usually it works.

If we can get more reliable STR and if it turns out that the issue is related to the scanning process then we have some options.  The easiest thing would probably be to make the gallery not scan for new files when invoked to pick a photo.  So the user would have to use the camera, then run the gallery to scan the photos, then use facebook to select the desired photos to upload.  That seems pretty bad, so I don't want to do that unless this really is an easy-to-reproduce bug.

Hmm.  Here's a thought. I created a test account on facebook to try to reproduce this. It has almost nothing in it. When I launch the facebook app and click to add a picture 'adb shell b2g-ps' reports something like 78mb of memory being used.  Joe, if you're using a real facebook account, perhaps you have lots of content and images opened and maybe your app is using lots more memory.  Could you check that? Open Facebook, and after you click to add a photo, but before you tap on the Gallery button, try 'adb shell b2g-ps' and see how much memory Facebook is taking.

If the issue is that Facebook is using too much memory, I'm not optimistic that we'll be able to do much to solve this problem, at least not in Gaia.
Flags: needinfo?(jcheng)
hi David, sorry for the late response

With facebook opened and before tapping on photo upload
APPLICATION      USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
b2g              root      86    1     154060 28364 ffffffff 40029518 S /system/b2g/b2g
(Nuwa)           root      318   86    46824  4468  ffffffff 400df518 S /system/b2g/plugin-container
Facebook         app_3030  3030  318   83080  34364 ffffffff 400df518 S /system/b2g/plugin-container
(Preallocated a  root      3073  318   55008  13244 ffffffff 400df724 S /system/b2g/plugin-container

With facebook opened and after tapping on photo upload
APPLICATION      USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
b2g              root      86    1     155108 34768 ffffffff 40e70ae6 R /system/b2g/b2g
(Nuwa)           root      318   86    46824  4460  ffffffff 400df518 S /system/b2g/plugin-container
Facebook         app_3030  3030  318   83692  34200 ffffffff 400df518 S /system/b2g/plugin-container
(Preallocated a  root      3073  318   55008  12824 ffffffff 40e29740 R /system/b2g/plugin-container
Flags: needinfo?(jcheng)
Thanks for this data, Joe. It showss that the Facebook app is taking about 5mb more for you than it does for me. I wonder if that is enough to make a difference.  If you create a test account with no friends, does it still crash consistently for you?

Also, is the crash correlated with scanning in the gallery? If you wait for scanning to finish before selecting a photo, can you avoid the crash? 

Setting qawanted for help here, because I can't reproduce this reliably and without more information I'm not sure what we can do about it. QA: can you reliably reproduce this issue?  Does it involve scanning in the gallery? Does it require an active facebook account with lots of content displayed?

Mike: can someone on your team try an about:memory analysis of the facebook app when displaying a typical page to see if there is anything we can do to optimize here? If users who have photo-heavy facebook pages can't attach photos to those facebook pages, we're going to be in trouble.

Milan: in 1.3T do apps discard their decoded images when they go to the background? In the case of an image pick activity, the requesting app becomes hidden but doesn't actually go to the background. Is there some other way that we could signal it to discard its images in that case?

Alive: if something like the above is possible, can we modify the window manager to make it work?

Finally, I'm going to unassign myself from this bug because I am not actually able to make any progress on it and I suspect that an unassigned 1.3T+ bug will get a lot more attention than an assigned one!
Assignee: dflanagan → nobody
Flags: needinfo?(mlee)
Flags: needinfo?(milan)
Flags: needinfo?(jcheng)
Flags: needinfo?(alive)
Keywords: qawanted
(In reply to David Flanagan [:djf] from comment #14)
> ...
> 
> Milan: in 1.3T do apps discard their decoded images when they go to the
> background? In the case of an image pick activity, the requesting app
> becomes hidden but doesn't actually go to the background. Is there some
> other way that we could signal it to discard its images in that case?

Timothy, can you answer this question for David?  1.3T is Gecko 28 +uplifts.
Flags: needinfo?(milan) → needinfo?(tnikkel)
(In reply to David Flanagan [:djf] from comment #14)
> QA: can you reliably reproduce this issue?  Does it involve scanning in the gallery?

I experienced 3 OOMs (app exits to Homescreen) out of 10 attempts when posting a picture on Facebook app. So the answer is no I can't reliably reproduce this issue.

Out of the 3 OOM's, twice was experienced when tapping on 'Done' button on picture cropping screen, once was experienced when tapping on 'Gallery' when prompted to select source of pictures.

I only have 12 pictures in my Gallery so I'm not sure if scanning is a factor. I had tried selecting a picture while Gallery was still loading and it didn't result to a crash.

> Does it require an active facebook account with lots of content displayed?

My test account has three friends and there was not much to display on my News Feed except suggestions on Friends and my own test posts.

I found that the device also unreliably OOMs when browsing the News Feed looking at pictures posted by myself.

Tested on:
Device: Tarako 1.3T
BuildID: 20140527083840
Gaia: c8f6ba7aa9a694f5f691555a0d049f5630cdde3d
Gecko: f40734e411c3
Version: 28.1
Firmware Version: sp6821a-gonk-4.0-5-12
Keywords: qawanted
Images in apps on b2g are not locked, so they can be discarded at any time. It doesn't matter if they are in the background or foreground. Images that are in foreground apps will be more likely to be drawn and so they will be more likely to be not discarded when a discard is triggered. When a discard is triggered we discard the image with the oldest last use time. Currently we will trigger a discard
1) when we have more than image.mem.max_decoded_image_kb of decoded images, 30mb currently on b2g
2) when we get a memory pressure event
3) we also have a timer that will discard after a specified time, but its currently effectively disabled on b2g (we set it to discard after 1 day)

None of these seem appropriate for this situation. So perhaps we need something for this use case. Can we put the app in the background? I could more readily see writing a patch that discarded in that case.
Flags: needinfo?(tnikkel)
Timothy, you also suggested we may want to rethink the 30mb max decoded image value on a device like Tarako in another bug. Can we quickly check if lowering that to 25mb (given comment 14) actually makes a difference here?
Johnny,

Can you have Kyle or someone else help here with memory analysis of the Facebook app?

Thanks,
Mike
Flags: needinfo?(mlee) → needinfo?(jst)
fwiw, I set the max decoded image value to 25mb and it seems to help somewhat. I was able to attach 3 pictures to a fb post (1 from the gallery, 1 portrait and 1 landscape from the camera). See https://www.facebook.com/fabrice.desre/posts/813451748680082
I can look into this if needed but it sounds like we just need to adjust the preference values.  needinfo me again if I need to do something here.
Flags: needinfo?(jst)
(In reply to Fabrice Desré [:fabrice] from comment #20)
> fwiw, I set the max decoded image value to 25mb and it seems to help
> somewhat...

Probably worth landing this change and seeing how the testing goes?
James, can you get that landed on the device repo?
Flags: needinfo?(james.zhang)
At Fabrice's request I've investigated why the camera app takes so much longer to return a picked photo to Facebook than it does to return to the SMS app.  I thought maybe there was a bug causing it to use a larger image size or something, but it is using the same size image.

The sluggishness is not specific to the image rotation step. In fact, when I select an image from the camera using Facebook, everything is slow. There is terrible shutter lag--sometimes I wait a second between pressing the shutter before I finally hear the shutter sound.  The camera startup spinner sometimes takes too long to disappear after the camera appears to be ready.  As Fabrice found, sometimes it takes a long time after clicking Confirm to get back to Facebook.  Only 1-2 seconds of this time are the camera app processing the image. Sometimes, the spinner goes away and we just sit there while the system transitions back to facebook from the camera.

My first guess here is that everything is slow because Facebook's memory is being compressed and uncompressed. But I don't understand how memory works on Tarako, so I might be off base here. And if so, I don't think there is anything we can do about this issue.  (Though I can fix the issue where the camera goes back to the viewfinder while it is supposed to be returning the selected image.  That's a one-line fix)

If that is not it, then maybe there is something different about how activities are handled when launched from web content (since facebook is not really an app) that makes them slower than when launched by certified apps.  Is there a window management issue or a process priority issue here, perhaps?

Needinfo Fabrice so he sees my findings here.
Flags: needinfo?(fabrice)
Thanks for investigating David. A couple of comments:
- please do the one-line fix to not go back to the view finder!
- in the sms case, since both the sms and camera app are certified they run in the same process. With facebook however, we run the camera app in its own process, and indeed need to do a real cross process transfer of the blob that seems quite slow in these conditions. There's probably some swap trashing as we get a bunch of memory pressure events in the fb app that make us run the GC, flush caches etc.
Flags: needinfo?(fabrice)
Clearing needinfo, seems nothing system app could help.
Flags: needinfo?(alive)
Loop Ying.Xu.
Flags: needinfo?(james.zhang) → needinfo?(ying.xu)
(In reply to Fabrice Desré [:fabrice] from comment #23)
> Created attachment 8429668 [details] [diff] [review]
> max-decoded.patch
> 
> James, can you get that landed on the device repo?

Can you tell us how to calculate this value?
pref("image.mem.max_decoded_image_kb", 25000);
Flags: needinfo?(ying.xu)
(In reply to ying.xu from comment #28)
> (In reply to Fabrice Desré [:fabrice] from comment #23)
> > Created attachment 8429668 [details] [diff] [review]
> > max-decoded.patch
> > 
> > James, can you get that landed on the device repo?
> 
> Can you tell us how to calculate this value?
> pref("image.mem.max_decoded_image_kb", 25000);

I just lowered the default 30MB to 25MB. That will lead to faster image discarding.
Why not 15MB or 20MB for tarako?
Fabrice, it looks like you are working on this, mind taking? thanks
Flags: needinfo?(jcheng) → needinfo?(fabrice)
(In reply to James Zhang from comment #30)
> Why not 15MB or 20MB for tarako?

If testing shows that it's better, why not. I just went with a conservative improvement.
Flags: needinfo?(fabrice)
Do we have any specific asks from FB here?
Flags: needinfo?(fabrice)
(In reply to Harald Kirschner :digitarald from comment #33)
> Do we have any specific asks from FB here?

I don't think.
Flags: needinfo?(fabrice)
(In reply to Joe Cheng [:jcheng] from comment #31)
> Fabrice, it looks like you are working on this, mind taking? thanks


Assigning to James to get Fabrice's patch landed o device repo based on his comment 23

djf also added the fix on camera side that fabrice requested as well as part of bug 1017243 (waiting for travis and will land that soon)

Thanks
Hema
Assignee: nobody → james.zhang
commit 33f74f7e554b88290a341960d084b245c3408dd4
Author: ying.xu <ying.xu@spreadtrum.com>
Date:   Wed May 28 14:00:27 2014 +0800

    Bug#245770 reduce image cache to 25MB
Thanks Ying!

Can we get QA to verify and close this bug tomorrow?
Flags: needinfo?(nhirata.bugzilla)
After using the e.me version of Facebook ended up getting killed at the same time as Gallery launching when trying to post an image.

I installed the facebook app and had the same thing happen until I rebooted the phone.  I rebooted and could post a picture once.  Following that I still ended up crashing a lot trying to post a picture.

I don't think I would consider this fixed as of yet.  :(
Flags: needinfo?(nhirata.bugzilla) → needinfo?(fabrice)
I've asked Naoki to try the following:

  adb root
  adb remount
  adb pull /system/b2g/defaults/pref/dev-pref.js
  # edit the file to change this line: pref("image.mem.max_decoded_image_kb", 25000);
  adb push dev-pref.js /system/b2g/defaults/pref/
  adb reboot

That should allow us to test facebook with different (smaller) values of the pref to find out whether reducing to 20000 or even 15000 fixes this bug (while still allowing reasonably smooth scrolling).
I've played around with various settings : 
25000 - crashes with gallery
20000 - crashes with gallery
15000 - crashes with gallery; one post with camera seems to be ok?
10000 - gallery - one post got through; second post did not.  
      - tried rebooting and sending another post and that did not work.  
      	- I think there needs to be a little bit of time after reboot before you can
      - second picture still crashed.
8000 - gallery - first post got through; second post LMKed.
5000 - gallery first post goes through after reboot, second post LMKed even after waiting.
0 - gallery will flicker like crazy if there's an animated gif.

Fabrice mentioned the lowest we should consider is 10000.  
5000~8000 seems fairly stable for me for the sending the first image.  10000 sometimes it works and sometimes it doesn't for the first image.  The second image doesn't seem to send until FB process releases some memory.

about-memory report can be found here : 
https://drive.google.com/a/mozilla.com/file/d/0B_0LdM1CVycIbTk3cXVYNS1TTzA/edit?usp=sharing
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #40)
> about-memory report can be found here : 
> https://drive.google.com/a/mozilla.com/file/d/0B_0LdM1CVycIbTk3cXVYNS1TTzA/
> edit?usp=sharing

I can't access your URL. And I can't login the facebook.

Did you notice memory-pressure event was triggered when facebook get killed?
log looks like this 'Memory pressure is over'  
adb shell logcat|grep 'Memory pressure'
Assignee: james.zhang → ying.xu
Hi,Hema Koka .

I can't do other things very helpful here.
Please reassign to a proper person
as Fabrice is on PTO, David, do you think you can take this bug and investigate further? thanks
Flags: needinfo?(dflanagan)
Joe: I don't know of any further investigation I can do. I don't understand how the LMK works, and I don't know much about interpreting about:memory reports. I don't feel qualified to make a decision about reducing the image.mem.max_decoded_image_kb pref, though I think Fabrice indicated that he would be willing to go as low as 10000.  Also, only people with active facebook pages are able to reproduce this bug.  I only have a mostly empty facebook test account, and I don't see the bug.

Mostly I think that the Facebook app is just too much of a memory hog to run well on Tarako and that Facebook will have to modify their mobile app if they want Tarako users to have a good experience with it.

Perhaps someone from Mike Lee's performance team could move this forward. Setting needinfo for him.
Flags: needinfo?(dflanagan) → needinfo?(mlee)
Whiteboard: [sprd313365][partner-blocker]
Can we group Gallery and Camera app into Facebook app to pass this block issue test case?
FaceBook/Youtube/ConnectA2 are tarako top 3 3rd-party apps, but we still can't pass these test case now.
Flags: needinfo?(gal)
Not really, that would be a huge change to the security architecture.
Our customer can't accept that FB can't work fine. It's top 3rd-party app.
Do you have any idea to pass test case?
Facebook only receives the the picture and uploads it. Am I correct to assume that to attempt to fix this on their side is to remove overall memory use?

Also testing on the following build I could attach 2 pictures on 2 messages without a crash.

Gaia      adb258b88485ccf1ff2e971de0fda547e4bb7149
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/e8b77a1c7c78
BuildID   20140609014001
Version   28.1
ro.build.version.incremental=eng.cltbld.20140529.053252
ro.build.date=Thu May 29 05:33:02 EDT 2014
Harald, Fabrice found he couldn't easily reproduce it either; having said that I have a feed that's populated and Facebook ends up taking somewhere around 30 Megs off of start. trying to add an photo ends up causing it to get LMK'ed unless I set the settings to 8000.  See comment 40.

Ying you should be able to access the link now.
Flags: needinfo?(ying.xu)
Odd.  Sorry, Harald.  I'm not able to currently reproduce with today's build either.

I'm not sure what the difference is.  It was LMK'ing before.
Note: I only have ADB on instead of ADB and Devtools in order not to hit this bug.
Okay, after a few conversations today, let's bring this back to where we're at:

1) Naoki used to be able to reproduce the problem with a large feed but is no longer able to reproduce with today's build.

2) Harald uploaded 2 photos and messages w/o any problems or crashes and believes the latest build can not reproduce the problem.

We need to reproduce this ASAP if it's a problem with exact steps AND assets.  Again, as it stands, we don't have a test case that fails.

James, please provide our QA with something that can be reproduced so we can tackle it from that point on...

Thanks.
Flags: needinfo?(james.zhang)
Does FB update new version? We don't have big change from 5/30. I'll ask our QA to verify it.
Flags: needinfo?(james.zhang)
Let's check it again, we have some zram improvement in kernel side.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #50)
> Odd.  Sorry, Harald.  I'm not able to currently reproduce with today's build
> either.
> 
> I'm not sure what the difference is.  It was LMK'ing before.

Please give me your 5/30 and today build manifest.xml, let's find the difference.
Facebook was killed by LMK due to free swap is low, so bug 1016212 helps, the commit as below:

commit 4c82f1be5aafc5a102a3c3d98a641e0724683abe
Author: ying.xu <ying.xu@spreadtrum.com>
Date:   Tue Jun 3 15:56:55 2014 +0800

    Bug#303502  don't kill foreground apps when free of swap disk low
    
    [self test   ] no killing when free of swap disk low
    
    Change-Id: I701e1490201793cd6666a149b9f8d530922dc1b6
It took me sometime to login facebook

with latest build and facebook app, I can add 5+ photos from gallery or camera. without facebook being killed.
And I don't find any crop operations

with 5.30 kernel image and latest facebook app, I can add 5+ photos from gallery or camera. without facebook being killed.

logs with latest build and facebook app
apusr@yingxuubt:~/b2gsource/ffos/monkey.test/test-config$ adb shell procrank
  PID      Vss      Rss      Pss      Uss  cmdline
   85   33472K   30704K   26326K   22284K  /system/b2g/b2g
 2636   31128K   30584K   26252K   22228K  /system/b2g/b2g
  298     924K     924K     476K     260K  /system/b2g/b2g
 2958     436K     432K     284K     232K  procrank
   
                          ------   ------  ------
                          54947K   46356K  TOTAL

RAM: 100396K total, 3948K free, 48K buffers, 24916K cached, 2208K shmem, 5524K slab
apusr@yingxuubt:~/b2gsource/ffos/monkey.test/test-config$ adb shell b2g-ps
APPLICATION      USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
b2g              root      85    1     134032 30708 ffffffff 40152518 S /system/b2g/b2g
(Nuwa)           root      298   85    46964  928   ffffffff 40152518 S /system/b2g/b2g
Facebook         app_2636  2636  298   81820  30584 ffffffff 40152518 S /system/b2g/b2g

apusr@yingxuubt:~/b2gsource/ffos/monkey.test/test-config$ adb shell cat /proc/meminfo
MemTotal:         100396 kB
MemFree:            4104 kB
Buffers:              48 kB
Cached:            24860 kB
SwapCached:         2216 kB
Active:            27144 kB
Inactive:          31580 kB
Active(anon):      18220 kB
Inactive(anon):    26328 kB
Active(file):       8924 kB
Inactive(file):     5252 kB
Unevictable:         332 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         100396 kB
LowFree:            4104 kB
SwapTotal:         65532 kB
SwapFree:          27484 kB
Flags: needinfo?(ying.xu)
Attached image facebook-addphoto
a snapshot of my test

Can you people confirm whether the facebook app was updated?
Attached file sources.xml
6/9/2014 pvtbuild manifest
Note: the changes that happened recently is not just for Facebook.  It appears that Twitter now works as well in terms of composing and selecting a link off of twitter.

Maybe bug 966446 and bug 1018544 helped as well?
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/shortlog

I don't know for certain.
Flags: needinfo?(james.zhang)
Ying, please use our old version to verify Facebook and Twitter. You said Facebook provide new version, I don't think Twitter provide new version too. I think we should find the reason.
Flags: needinfo?(james.zhang)
Ying, is it caused by camera hal thumbnail size change to 640x480?
Please help to find the reason.
Harald requested that I document my experience here:

I flashed to build 20140609014001, opened FB and tried to attach a picture in a chat convo.  After opening the camera, I got a spinner for a few seconds and then it crashed.  Rebooted and tried again, was able to take a photo but then the app froze for 3+ minutes until I tapped the home button and returned to the home screen.  I was seeing this behavior last week, so no improvement for me.
It's clear we're getting inconsistent results here.  Naoki: can you get together with Lisa and at least get the same test results produced?
Just my two-cents -- the FB account used to log into the app may be affecting our results. It may be worth investigating using a fresh, newly-created FB account versus one that is somewhat moderately active to see if there's a difference.
Hi Faramarz, I will try to get in touch with Lisa.
After getting in touch with Lisa, and working with her in regards to getting a reproduction; I was able to reproduce it with the test account she had let me borrow.

I was still LMK'ing with today's build.  She was LMK'ing with yesterday's build.
I modified /system/b2g/defaults/pref/dev-pref.js so that pref("image.mem.max_decoded_image_kb", 8000);

I was able to then take pictures without LMKing if I just take pictures.  If I scroll down to see the feeds, and then go back up and take pictures, I still LMK'ed.


Gaia      2765ccc9bad41f7f696889c4ca33051fb42734f5
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/55ec4880a709
BuildID   20140611014001
Version   28.1
ro.build.version.incremental=eng.cltbld.20140611.050948
ro.build.date=Wed Jun 11 05:09:55 EDT 2014
Harald, could you try again with the account emailed to you please?
Flags: needinfo?(hkirschner)
(In reply to Faramarz [:faramarz] from comment #65)
> It's clear we're getting inconsistent results here.  Naoki: can you get
> together with Lisa and at least get the same test results produced?

I forgot one thing.
I have applied the patches from Bug 977026 - Fork b2g and Nuwa processes from the same process.
which optimized memory usage for app processes.

And my facebook account is very fresh.
Depends on: 977026
bug 977026 saved about 4MB memory.
James: I'm trying to get some help from our performance team to see where we can make the needed improvements. Thanks!
I forgot one other setting to check with Lisa.  By default the adb + devtools is turned on, we should have adb only as the settings.  This is something that Fabrice keeps reminding me of...
Let's keep in mind that the Facebook app is basically just a mobile website, not an app, and that we don't control it.

In general, active Facebook users with busy timelines (like Naoki) can reproduce this bug. People like me, who created a Facebook account just to work on this bug, can not usually reproduce it.  Except when Facebook decides to do something different... Once when I tried testing this, Facebook decided that as a new user it should send me special content (I think it was "do you know any of these people"). So even though I have an empty timeline, the Facebook's app memory usage went way up and I could reproduce the bug. 

As a general thing, no matter how much memory we can save, there is always going to be someone's extra busy facebook page that will use too much memory for Tarako. The same is true of any website. It is a low-spec device, and some content will just be too big for it. The facebook app is a memory-hungry black box. We cannot make it never crash. In order to solve this bug we might want to just pick a number and call that good enough. Maybe the requirement is that the user is able to select a photo from the camera app if the facebook app is using 75mb of memory or less.  And if Facebook is larger than that we offer no guarantees.

From Naoki's work reported in comment #40 we know that modifying the value of the image.mem.max_decoded_image_kb preference seems to make a difference, at least once we get it down to 10000 or below. Does anyone on this bug have the knowledge and understanding of that preference to make a decision to change that.  Milan: can you or someone on your team weigh in on what a reasonable value of this pref would be for this low-memory device?  What are the possible consequences of setting it too low? 

Other thoughts:

- Comment #56 makes it sound like we actually have a swap partition on this device. I didn't know that. Can we increase the size of the partition? Danny, is that something you could comment on?

- The tricky thing in all of this is keeping the Facebook app alive while the Camera or Gallery apps run as activities. Neither Camera nor Gallery are small apps. Is there any way we can modify our activity launching code to interact with our memory management code?  When we launch Camera or Gallery can we first ensure that the Facebook app is fully swapped out? Or could we send a memory pressure event before launching an activity to give Gecko some advance notice of the coming memory squeeze? I have no idea if this is plausible or not. Anyone have ideas here?

- Perhaps as a stop-gap we could impose some kind of free memory requirement before launching an activity. If the foreground app is using more than some number of mb of memory, then we don't allow it to launch an activity and instead display a message to the user? Users would lose features, but at least it wouldn't be via mysterious OOMs.  Can we actually do this? Can the activity code in Gecko (which I think is written in JavaScript) get access to process memory usage information?  This might be the best we can do: to fail with an explanatory message rather than failing with no message.

- Or could we modify memory management for activities so that it is the requesting app that stays alive and the activity handler app that gets killed? The user still wouldn't be able to attach a photo, but at least they'd still have their facebook page open. This would only really make sense if the system app had a way to detect the 'activity-failed-with-OOM' case and display an error message.
Flags: needinfo?(milan)
Flags: needinfo?(dliang)
(In reply to David Flanagan [:djf] from comment #75)
> - Or could we modify memory management for activities so that it is the
> requesting app that stays alive and the activity handler app that gets
> killed? The user still wouldn't be able to attach a photo, but at least
> they'd still have their facebook page open. This would only really make
> sense if the system app had a way to detect the 'activity-failed-with-OOM'
> case and display an error message.

+1 to this idea!

Another question I have (not sure if this is possible).. but when an app requests an activity (such as FB requesting the Pick activity), can we do anything to the requesting app to attempt to free up some memory? (e.g.: garbage collection) -- We might already be doing something like this but it was just a another thought I had after reading David's suggestions.
I flashed to today's build and am now able to take a photo within the Facebook app without freezing or crashing, but with ~30 second delays to complete each step (open the camera, process photo after tapping the shutter button, and then processing after tapping the "Select" button to confirm that's the photo I wanted to post).  

I then followed Naoki's advice in comment 74 to set remote debugging to adb only and then rebooted, which resulted in a huge performance increase.  It now takes 1-2 seconds to complete each step, and is comparable to the experience on other Firefox OS devices.
Timothy, can you comment on the third paragraph from comment 75?
"...From Naoki's work reported in comment #40 we know that modifying the value of the image.mem.max_decoded_image_kb preference seems to make a difference, at least once we get it down to 10000 or below. Does anyone on this bug have the knowledge and understanding of that preference to make a decision to change that.  Milan: can you or someone on your team weigh in on what a reasonable value of this pref would be for this low-memory device?  What are the possible consequences of setting it too low?..."
Flags: needinfo?(milan) → needinfo?(tnikkel)
When the total memory used by decoded images goes over that pref value we will discard the least recently used images until we go under that amount (even if we have to discard an image that is currently visible and on screen). The worst problem with making it too low is that the memory use by the images currently visible on screen will go above the value and we will discard some of them, and then we will have to draw them again, and we will decode them again, and repeat. So we get constant decoding and the image constantly flashes on screen.
Flags: needinfo?(tnikkel)
Didem and I confirmed that the low-fi version of FB does not exhibit the same memory behaviour but behaves very stable on Tarako while providing a sufficient UX.

Switch to the low-res mobile version of m.facebook.com: Add the following pref to your devices user.js. A script to do so is listed @ https://developer.mozilla.org/en-US/Apps/Build/App_development_FAQ#What_are_useful_commands_during_development.3F or in the B2G-flash-tool folder.
  pref("general.useragent.override.facebook.com", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.1) Gecko/28.1 Firefox/28.1");
Open the Facebook app, it will serve the low-fi mobile version.

Memory while using the app will is stable around 10 Mb, even while adding pictures (which only uses standard file inputs). Browsing the newsfeed will load a new page each time and therefor not add memory.

Firewatch screenshot: https://cloudup.com/iUfztCG1EsY
Firewatch dump (open via `firewatch-server -d {folder}`): https://cloudup.com/c2tfj-OP-7P
Flags: needinfo?(hkirschner)
(In reply to Harald Kirschner :digitarald from comment #80)
> Didem and I confirmed that the low-fi version of FB does not exhibit the
> same memory behaviour but behaves very stable on Tarako while providing a
> sufficient UX.

If there is any device that should get a "low-fi" version of Facebook, it seems to me that Tarako is that device. I wish we had known that something like that existed!  

Technically, using a lite version of the app seems like the fix we need here.  So I imagine it is just a matter of getting product sign off on delivering that version of the app on the phone.

Harald: can you summarize the differences between the regular mobile site and the low-fi version? Maybe just attach a couple of screenshots?  What are the significant downsides, if any, to using the low-fi version?
Flags: needinfo?(hkirschner)
To note, comment 79, I can verify that setting to 0 did cause flashing.  
Just to reiterate, Fabrice recommended to stay at a minimum of 10000 before he went on vacation.

Is there a "low-fi" twitter as well?
I propose that we take Fabrice's patch that sets image.mem.max_decoded_image_kb, modify that pref to be a little more agressive (based on Naoki's testing) and add the low-fi Facebook pref that Harald has suggested in comment #80 and get Spreadtrum to start testing that combination aggressively.

I'm cloning the 1.3t gecko tree right now and will prepare a patch to do this.
For David Flanagan's question in comment 81: If you simply visit the url "m.facebook.com" from your desktop, it serves the low-fi version. 

For Naoki's question in comment 83, we've just found out this week that Twitter has a low-fi version as well. We just need to figure out how to test it on Tarakos.
There are lots of places that we can make changes to gecko prefs. Fabrice's patch above changes the max_decoded pref in gonk.

This patch changes it, and the Facebook UA string in gecko.

And it now occurs to me that we could also do it in gaia in the build/preferences.js file.
Joe and James,

The two patches above customize the same two pref values, but one does it in Gecko and the other does it in Gaia.  I prefer the Gaia version because we can control it with the GAIA_MEMORY_PROFILE=low environment variable setting, so it doesn't have to be specific to 1.3t. But both patches should have the same effect.

In addition to changing the UA string to get m.facebook.com to send us the low-fi version of the site, bot versions of this patch also set the max_decoded_image_kb preferenct to 14400. This value is much more agressive that Fabrice's initial patch, but based on Naoki's testing, I think it ought to be a suitable value.

Both changes need testing, and I think we should start that testing now with one or the other of these patches. Note that Harald will be talking to Facebook tomorrow and will hopefully come back with a better recommendation for the UA string to use, or maybe even some other way to get Facebook to send us the low-fi version. So we shouldn't land either of these patches yet, but let's do start testing them.
Flags: needinfo?(jcheng)
Flags: needinfo?(james.zhang)
filed bug 1024783 in regards to twitter UA change.
I think we can put these value in dev_pref.js in device/sprd to overlay the default value.
Ying, can you take it and verify?
Flags: needinfo?(james.zhang)
(In reply to David Flanagan [:djf] from comment #75)

> - Comment #56 makes it sound like we actually have a swap partition on this
> device. I didn't know that. Can we increase the size of the partition?
> Danny, is that something you could comment on?

In fact, the swap disk in also in memory, and the memory put in swap is compressed
currently, the swap disk is 64M . After compressing, it may use 25M memory ,more or less.
we can increase the size, but need more tests.

> send a memory pressure event before launching an activity to give Gecko some
> advance notice of the coming memory squeeze? I have no idea if this is
> plausible or not. Anyone have ideas here?

this has been done from what I know.
nsFrameLoader::SetVisible
  ParticularProcessPriorityManager::SetPriorityNow
       if (aPriority < PROCESS_PRIORITY_FOREGROUND) {
          unused << mContentParent->SendFlushMemory(NS_LITERAL_STRING("low-memory"));
       }
(In reply to ying.xu from comment #90)
> (In reply to David Flanagan [:djf] from comment #75)
> 
> > - Comment #56 makes it sound like we actually have a swap partition on this
> > device. I didn't know that. Can we increase the size of the partition?
> > Danny, is that something you could comment on?
> 
> In fact, the swap disk in also in memory, and the memory put in swap is
> compressed
> currently, the swap disk is 64M . After compressing, it may use 25M memory
> ,more or less.
> we can increase the size, but need more tests.
> 

According to previous test result by Kai-Zhen, device cannot boot up if zram is small, performance (launch time) will be bad if zram is bigger. 64MB zram space should be the optimal value. We had some improvements of memory saving, so I think it's necessary to re-evaluate the size of swap disk. I could try to provide some results to evaluate the zram size in this case.
Land David's patch in device/sprd.

commit b63254db900aa2e83fd1bc0b3bb750af6eadb255
Author: yiwen.liu <yiwen.liu@spreadtrum.com>
Date:   Fri Jun 13 16:33:43 2014 +0800

    Bug #245770 optimize entry of facebook app
    
    [bug number  ]
    [root cause  ]
    [changes     ]
    [side effects]
    [self test   ] ok
    [reviewers   ]
    
    Change-Id: I2d08d91aed6ce79d5082d6865fb2c85d701e4d1d
Gerv is our overall UA string owner, I think we should have him in the discussion of what string is being used. I personally would have us rather put something in that says "LowMemPhone" or such than a specific device code name.
We should definitely talk to Facebook about what strings already trigger their low-fi version. "Tarako" is a particularly bad choice because it's a codename, and it's for a particular single device. We don't want to be stuck with calling other low mem phones "Tarako" in the UA for Facebook compatibility.

But even the idea of a "LowMem" tag isn't ideal; what counts as Low? And we really don't want to be stuffin the UA string with all sorts of hardware parameters, as it becomes a fingerprintability issue.

It would be nice if apps were able to detect low mem and adapt - are there web APIs for that, or not? 

How much of a relationship do we have with the FB team who build this app?

Gerv
> We should definitely talk to Facebook about what strings already trigger their low-fi version.
Any unknown UA that doesn't match a pattern whitelist would trigger it.

I recommend adding the device ID which Spreadtrum would decide on. ZTE, Alcatel and LG did the same for their devices. I agree with you and definitely not recommend tagging it LowMem or with codenames.

> It would be nice if apps were able to detect low mem and adapt - are there web APIs for that, or not? 
Yes. It is a privileged feature API but Twitter isn't packaged.
Flags: needinfo?(hkirschner)
(In reply to Harald Kirschner :digitarald from comment #95)
> > We should definitely talk to Facebook about what strings already trigger their low-fi version.
> Any unknown UA that doesn't match a pattern whitelist would trigger it.

<sigh> So if adding a Device ID causes the low-fi version, all the normal-mem Firefox OS devices where the carrier is insisting that they add a device ID, against our advice, are also going to get the low-fi version?

UA sniffing. Like glue sniffing, only more harmful.

> I recommend adding the device ID which Spreadtrum would decide on. ZTE,
> Alcatel and LG did the same for their devices. I agree with you and
> definitely not recommend tagging it LowMem or with codenames.

Tagging it with a device ID that consumers know, as opposed to a codename, still has most of the disadvantages. If this is a Facebook-only UA hack, then perhaps "128MB" is the right answer. At least it's specific, and it means the UA doesn't match the whitelist. Heck, we could go for "LowFiVersionPlease".

> > It would be nice if apps were able to detect low mem and adapt - are there web APIs for that, or not? 
> Yes. It is a privileged feature API but Twitter isn't packaged.

But Facebook is?

Gerv
> <sigh> So if adding a Device ID causes the low-fi version, all the normal-mem Firefox OS devices where the carrier is insisting that they add a device ID, against our advice, are also going to get the low-fi version?
Sorry, I was unclear. They also have a white (or rather black) list that triggers the low-fi site. We would have the UA with the new device ID added to that list. I assume that their current whitelist for the hi-fi site has something that matches something like /firefox.*mobile/

> UA sniffing. Like glue sniffing, only more harmful.
Worse, FB even uses WURFL but lets not go there now.

> Tagging it with a device ID that consumers know, as opposed to a codename, still has most of the disadvantages.
Can you explain? We are already going that and its the recommendation. LG uses `Mozilla/5.0 (Mobile; LG-D300; rv:18.1) Gecko/18.1 Firefox/18.1`.

> But Facebook is?
No, same problem. Sorry for the mix-up of social networks, both are currently tested for lo-fi versions. Another reason against the feature API is that it only lands in 2.0 and will not help 1.3 devices like Tarako.
Gerv, Harald; I think this discussion is great and healthy.  I agree that we do need to get the UA string resolved for this situation.
  
Having said that, if I understand things correctly, djf's patch has landed in SPRD's repo.  Should we branch the UA string discussion into a different bug under Tech Evangalism/Mobile?
djf, james, I made my own build and it seems that the UA string works for the marketplace app and the browser, but it doesn't seem to work for the e.me version of facebook.

I filed bug 1025144 to track this and ni?ed amir
Flags: needinfo?(mlee)
(In reply to Danny Liang [:dliang] from comment #91)
> (In reply to ying.xu from comment #90)
> > (In reply to David Flanagan [:djf] from comment #75)
> > 
> > > - Comment #56 makes it sound like we actually have a swap partition on this
> > > device. I didn't know that. Can we increase the size of the partition?
> > > Danny, is that something you could comment on?
> > 
> > In fact, the swap disk in also in memory, and the memory put in swap is
> > compressed
> > currently, the swap disk is 64M . After compressing, it may use 25M memory
> > ,more or less.
> > we can increase the size, but need more tests.
> > 
> 
> According to previous test result by Kai-Zhen, device cannot boot up if zram
> is small, performance (launch time) will be bad if zram is bigger. 64MB zram
> space should be the optimal value. We had some improvements of memory
> saving, so I think it's necessary to re-evaluate the size of swap disk. I
> could try to provide some results to evaluate the zram size in this case.

I have done the app launch time test by different swap size, the detail result is in 
https://docs.google.com/a/mozilla.com/spreadsheets/d/1XxIVmG473wqP8jep-hUL-kT496LfRop0cWnklDMGfc0/edit#gid=0

Generally, the app launch time with 64BM and 68MB swap size is similar, it's around 1490ms. If the size became bigger, the launch time increased. With 100MB swap size, the app launch time became 1989ms.

I am also trying to find out the relationship between Faceboot app was killed by LMK and swap size, this test revert the commit I commented on https://bugzilla.mozilla.org/show_bug.cgi?id=1007019#c56.  By my test steps, Facebook will be killed if swap size is lower than 80MB. I cannot let Facebook was killed with 88MB swap size, but performance is not good.

The test step to test the relationship between Facebook was killed and swap size
1. Reboot device
2. Launch Facebook
3. Normal scrolling on Facebook for a while

SW version:
Gecko: defd92b8d097c915d4a73a078dd4ea047582436
Gaia: 16396ef0698d06728589bf3942bd57737e889114
kernel: 01b7fca4642e9422cda553945de609627a84ce99 but revert 4c82f1be5aafc5a102a3c3d98a641e0724683abe

According to above test result, I don't think increase the swap size would be a good solution for Facebook crash.
Flags: needinfo?(dliang)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #98) 
> Having said that, if I understand things correctly, djf's patch has landed
> in SPRD's repo.  Should we branch the UA string discussion into a different
> bug under Tech Evangalism/Mobile?

Sure. Go for it :-)

Gerv
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #98)  
> Having said that, if I understand things correctly, djf's patch has landed
> in SPRD's repo.  Should we branch the UA string discussion into a different
> bug under Tech Evangalism/Mobile?

Who is taking this on? Naoki? Just want to make sure this bug gets filed and shared in this thread asap.
Flags: needinfo?(nhirata.bugzilla)
And note that we want to keep this bug open so that once Harald and the BD team have talked with Facebook about sending the low-fi version to Tarako we can get Spreadtrum to revert the custom UA string preference.
(In reply to David Flanagan [:djf] from comment #103)
> And note that we want to keep this bug open so that once Harald and the BD
> team have talked with Facebook about sending the low-fi version to Tarako we
> can get Spreadtrum to revert the custom UA string preference.

Just to clarify this before this gets read the wrong way: Spreadtrum *must not* spoof the UA for Facebook. We need a UA from Spreadtrum with the right device ID that Spreadtrum choose that we can give to FB to serve the low-fi version of FB.
djf, thomas create bug 1026317.  Please comment in that bug if I got something wrong.
Flags: needinfo?(telin)
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(dflanagan)
See Also: → 1026317
Flags: needinfo?(dflanagan)
Flags: needinfo?(fabrice)
Harald,

Any update
Flags: needinfo?(hkirschner)
FB confirmed that they are working on adding the Tarako UA to their low-fi whitelist. They ran into some issues that it wasn't picked up as expected in their system, but that is on their side.
Flags: needinfo?(hkirschner)
Flags: needinfo?(telin)
Component: Gaia::Gallery → Preinstalled B2G Apps
Product: Firefox OS → Tech Evangelism
Changed the product and component of this bug since this is now an issue between partner engineering and Facebook. It never actually was a Gallery bug...
we are waiting for the new user agent.
FB is already serving the low-fi site for Tarako. This had negative side effects for apps that depend on oauth that we are now investigating.
Hi Thomas,

We are working on FB low-fi version with tarako Specific UA string.
Based on comment110 from Harald, may we know what is the Oauth issue mentioned?

Will this side effect be solved and investigated by FB ?

Thanks a lot.
Flags: needinfo?(telin)
We are using the UA now, "general.useragent.override.m.facebook.com". If FB or mozilla want to change it, please needinfo Ying and me.
As mentioned in comment 107 and comment 110 FB is already detecting the 28.1 version string which is unique for Tarako, please remove *any* overrides!
Flags: needinfo?(james.zhang)
Got it
Flags: needinfo?(james.zhang)
see device/sprd

commit 73da4001fa50070582d047520a9305f5728fb624
Author: ying.xu <ying.xu@spreadtrum.com>
Date:   Fri Jun 27 20:17:52 2014 +0800

    Bug#313365 revert user agent to origin for facebook
    
    [self test   ] OK
    
    Change-Id: Ic6089de283ae58f12bdc739a8821cfdc66e79062
Hi Harald, thanks for your update and tracking.
May we know the progress of the negative side effect of some apps depending on oauth?
could you please kindly explain the side effect?
Thank you very much !
Flags: needinfo?(hkirschner)
Blocks: 1025144
(In reply to Rachelle Yang [:ryang][ryang@mozilla.com] from comment #116)
> May we know the progress of the negative side effect of some apps depending
> on oauth? could you please kindly explain the side effect?

It appears that the low-fi version doesn't support the oauth flow that other apps would request when logging in with Facebook. The FB page that opens redirects endlessly. We are confirming with FB that this is expected behavior, which would mean we'd need to revert to the high-fi site.
Flags: needinfo?(telin)
Flags: needinfo?(hkirschner)
Please take a look at the video here: https://www.dropbox.com/s/u2p6wjnxp90l84h/1007019.3gp
As you can see from the video:
1. It took long time to response when user tap on "Play" button (at 00:47 second)
2. There is some lag when playing the game (at 1:43)
(In reply to pcheng from comment #118)
> Please take a look at the video here:
> https://www.dropbox.com/s/u2p6wjnxp90l84h/1007019.3gp
> As you can see from the video:
> 1. It took long time to response when user tap on "Play" button (at 00:47
> second)
> 2. There is some lag when playing the game (at 1:43)

Please ignore above comment.
Latest update from Facebook is that the lo-fi version supports oauth flow. We are shipping them a Tarako so that they check the issue with the oauth flow.
(In reply to Didem Ersoz [:didem] from comment #120)
> Latest update from Facebook is that the lo-fi version supports oauth flow.
> We are shipping them a Tarako so that they check the issue with the oauth
> flow.

@didem,
After another try today, I still see the oauth flow does not work. 
Sync facebook contacts failed. There is always an error: "Unable to Connect: Firefox has detected that the server is redirecting the request for this address in a way that will never complete.". 
But if I directly access facebook using browser or facebook app, I can login successfully.

Test build:
Gaia 3c896abb05d95ebe3d66634d014dac03a05f4caf
Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/f8a929882cb0
BuildID 20140630014001
Version 28.1
ro.build.version.incremental=eng.cltbld.20140630.045332
ro.build.date=Mon Jun 30 04:53:41 EDT 2014
(In reply to Harald Kirschner :digitarald from comment #117)
> (In reply to Rachelle Yang [:ryang][ryang@mozilla.com] from comment #116)
> > May we know the progress of the negative side effect of some apps depending
> > on oauth? could you please kindly explain the side effect?
> 
> It appears that the low-fi version doesn't support the oauth flow that other
> apps would request when logging in with Facebook. The FB page that opens
> redirects endlessly. We are confirming with FB that this is expected
> behavior, which would mean we'd need to revert to the high-fi site.

Tracking the facebook OAuth problem at bug 1033195
See Also: → 1033195
I was reading http://dev.opera.com/articles/css-will-change-property/


What is the influence of a 
	-moz-transform:translate3d(0px,0px,0px);
on memory/CPU consumption for the Tarako device?



On twitter it is used at least, in their m5_defer.css
.reload-box{
	box-sizing:border-box;
	-webkit-box-sizing:border-box;
	-moz-box-sizing:border-box;
	-webkit-transform:translate3d(0px,0px,0px);
	-moz-transform:translate3d(0px,0px,0px);
	position:absolute;
	top:-290px;
	left:0;
	height:290px;
	width:100%;
	text-align:center;
	background:#eee
}
0,0,0 is a no-op for us. 0.00001 would apply a transform and behave like will-change essentially.
Flags: needinfo?(gal)
we havn't meet this bug for some days.
so close it.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Flags: needinfo?(jcheng)
Blocks: 1062889
See Also: → 1062889
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: