Closed Bug 945043 Opened 6 years ago Closed 2 years ago
Web Page session lost when change to read SMS message
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20131112160018 Steps to reproduce: 1. Open City Transport web page to buy monthly ticket 2. Proceed with transaction with specifying transaction details. 3. Redirected to bank web page to proceed with payment. 4. Bank sent back SMS message with Transaction Code. 5. Read SMS message. 6. Back to Web Browser to fill Transaction code from SMS message. Actual results: After back to web page got information that transaction has been cancelled (lost session after web page reloaded). Expected results: The page shouldn't be reloaded. It is improper behavior that page is reloaded when back to browser from other programme (like SMS one). Now it is and it causes lost session and termination of bank transaction. I had to change to desktop computer to execute the task which makes FirefoxOS useless in context of bank transactions which has to be confirmed by SMS codes.
UPDATE for my bug report: Hardware: Alcatel One Touch Fire Software: FirefoxOS Version 18.104.22.168-01012P software branded for T-mobile Poland problem occured on mBank.pl bank transaction page (old 'yellow' version).
This happens with Buri running v1.1 released to the public from partner, as far as I remember.
Michal, do you have any way to investigate on this ? As far as I understood, one needs to have an account at this bank to be able to reproduce this issue.
As far as I remember :sasklacz has an account in there.
Flags: needinfo?(mbudzynski) → needinfo?(owcarnia)
Yes I do. :michalbe do you know if David was able to unlock my Alcatel ?
Although this has not been tested on v1.2 and 1.3, it is reproduced on v1.4.
I've checked by b2g-ps that Browser process is terminated when Messages process is started to read an SMS Transaction Code. Then when trying to back to the browser to finish bank transaction the browser is started again and page is reloaded. It causes session data lost and security error on bank transaction page. STR can be reporduced on every little more complex web page (i.e. forum page when writing down a forum post).
I tried this one. 1. Open random website. 2. Go to home screen and open SMS application. 3. Go back to browser. Result: Website is reloading. With very lightweight sites it doesn't reloading. The truth is 256 MB is really low.
I might have similar behavior on another set of STR. 1. Reboot device, make sure you have network 2. Fire Browser app 3. Go to speedof.me/m/ 4. Start a speed test During the speed test, I monitored the output of the kernel via dmesg. On my HTC Desire Z, I see a bunch of process getting killed: <6>[ 195.203277] lowmem: send sigkill to 1449 (Calendar), adj 12, size 6091 <6>[ 197.605712] lowmem: send sigkill to 1357 (Built-in Keyboa), adj 12, size 4356 <6>[ 198.235992] lowmem: send sigkill to 1468 (Settings), adj 11, size 6100 <6>[ 198.803375] lowmem: send sigkill to 1483 (Messages), adj 11, size 5755 <6>[ 199.117675] lowmem: send sigkill to 1396 (Homescreen), adj 8, size 5183 <6>[ 618.693817] lowmem: send sigkill to 1744 (Usage), adj 11, size 7141 <6>[ 619.720031] lowmem: send sigkill to 1521 (Built-in Keyboa), adj 11, size 3402 <6>[ 620.730834] lowmem: send sigkill to 1794 ((Preallocated a), adj 10, size 2369 <6>[ 622.252990] lowmem: send sigkill to 1571 (Homescreen), adj 8, size 3879 <6>[ 943.601898] lowmem: send sigkill to 1901 ((Preallocated a), adj 10, size 5749 <6>[ 944.483093] lowmem: send sigkill to 1773 (Browser), adj 2, size 59774 Under some circumstances, just starting a second speed test is enough to have the SpeedOf.Me's process getting killed, and having to reload the tab. In the log above, this is the case at timestamp 944.483093: the browser process of SpeedOf.Me is getting killed. This is a 512MB RAM device, with about 367MB available to the kernel: total used free shared buffers Mem: 375916 235864 140052 0 1772 -/+ buffers: 234092 141824 Swap: 0 0 0.
I traced some memory usage on the same HTC Desire Z device while running Speedof.Me: All applications killed, just started browser and loaded the website: > APPLICATION PID Vss Rss Pss Uss cmdline > b2g 1200 113740K 77968K 69270K 66144K /system/b2g/b2g > Browser 2635 87948K 47696K 34437K 29828K /system/b2g/plugin-container > Homescreen 2427 31272K 31272K 18770K 14948K /system/b2g/plugin-container > Usage 2560 28672K 28672K 16613K 13056K /system/b2g/plugin-container > (Preallocated a 2567 22988K 22988K 12456K 9476K /system/b2g/plugin-container > ------ ------ ------ > 166224K 140468K TOTAL While running a first speed test, roughly at 50% of the test: > APPLICATION PID Vss Rss Pss Uss cmdline > Browser 2635 151612K 119928K 106642K 102016K /system/b2g/plugin-container > b2g 1200 113540K 77768K 69049K 65912K /system/b2g/b2g > Homescreen 2427 31268K 31268K 18763K 14944K /system/b2g/plugin-container > Usage 2560 28668K 28668K 16608K 13052K /system/b2g/plugin-container > (Preallocated a 2567 22984K 22984K 12452K 9472K /system/b2g/plugin-container > ------ ------ ------ > 238188K 212408K TOTAL Still running the same test, at ~80% of completion: > APPLICATION PID Vss Rss Pss Uss cmdline > Browser 2635 175652K 143968K 141595K 139288K /system/b2g/plugin-container > b2g 1200 122512K 86740K 84321K 82000K /system/b2g/b2g > ------ ------ ------ > 240478K 228124K TOTAL > A first speed test finished, ~17Mbits detected (quite impossible, this device is only HSDPA Cat10 at best it can get ~14Mbits): > APPLICATION PID Vss Rss Pss Uss cmdline > Browser 2635 177356K 145672K 142727K 139868K /system/b2g/plugin-container > b2g 1200 123564K 87792K 84801K 81924K /system/b2g/b2g > ------ ------ ------ > 242085K 228620K TOTAL Now, we will proceed with a second speed test in the same tab of the Browser. Second speed test at about 25% of completion: > APPLICATION PID Vss Rss Pss Uss cmdline > Browser 2635 97908K 83984K 80500K 77112K /system/b2g/plugin-container > b2g 1200 108200K 72428K 68874K 65460K /system/b2g/b2g > ------ ------ ------ > 163932K 149476K TOTAL And at 50% of completion: > APPLICATION PID Vss Rss Pss Uss cmdline > Browser 2635 161792K 147868K 144384K 140996K /system/b2g/plugin-container > b2g 1200 108456K 72684K 69130K 65716K /system/b2g/b2g > ------ ------ ------ > 228195K 213668K TOTAL This second subsequent round gets killed a couple of seconds after, somewhere around 75% completion of the speed test.
With self built kernel and enabled swap file on SD card (512MB) I was able to finish the transaction - execute STR without reloading the bank transaction page. Moreover I was able to change between Messages and Browser multiple times even with partially filled transaction code on the bank transaction page. Please write to me if you need any more details.
If it's reproducing on 1.1 & 1.4, then I'm pretty sure it's reproducing on 1.2 & 1.3. I doubt we would have a branch-specific bug in this case if it's present on 1.1 & 1.4.
The session being lost via a reload along with the above comments seems to imply that this is likely an OOM.
Component: Gaia::Browser → General
Can we get memory reports from get_about_memory.py, please?
Whiteboard: [MemShrink] → [MemShrink:P2]
(In reply to Nicholas Nethercote [:njn] from comment #14) > Can we get memory reports from get_about_memory.py, please? In what moment you wish to get about_memory? after reload (then after back from Messages to Browser)?
> In what moment you wish to get about_memory? Preferably just before the browser is killed for using too much memory. I'm not sure exactly which step that is; it might take a few goes to find the right place.
I did 3 reads with get_about_memory.py 0: logged in, browser opened, just before change to Messages 1: just after change to Messages and Browser kill 2: back to the killed Browser process, web page has been reloaded instead read back from memory, Messages killed
Whiteboard: [MemShrink:P2] → [c=memory p= u= s=][MemShrink:P2]
Priority: -- → P2
Closing out old Firefox OS specific memshrink bugs.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.