Closed
Bug 868937
Opened 12 years ago
Closed 5 years ago
Taking a camera picture causes page reload because of lack of RAM
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(fennec-)
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
fennec | - | --- |
People
(Reporter: honglilai, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
Steps to reproduce:
I have a short HTML file with just one line:
<input type="file" accept="image/jpg" id="camera" capture="camera">
I visit this HTML file with Firefox Mobile, I click on Browse, then select Camera. I take a picture and press the confirmation button.
Actual results:
Android shut down Firefox when the camera UI was shown, because the device was low on RAM. When the camera UI returns, Firefox is restarted, but it does not populate the file input field with the picture that I just took.
Expected results:
Firefox should populate the file input field with the picture I just took.
I realize that it's not Firefox's fault that the device is low on memory or that it gets killed by the OS as soon as the camera UI shows up, but this problem prevents me from taking any pictures using file input fields, thus making them useless.
My device is just 2 years old: an HTC Desire Z with Android 2.3.3 and 512 MB RAM.
Comment 1•12 years ago
|
||
Not sure if there is anything we can do in all cases. Android has a process killer and when foreground processes need more RAM it will kill background processes.
Is there any way for us to be less aggressive about throwing away the current tab when we hit some of the less important memory pressure events? Especially if we are launching an intent.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
OS: Mac OS X → Android
Hardware: x86 → ARM
Reporter | ||
Comment 2•12 years ago
|
||
Can't you save the form state to persistent storage right before launching an intent, and restore form state upon return?
Updated•12 years ago
|
tracking-fennec: ? → -
Comment 3•11 years ago
|
||
There is a more general problem here than just what is described on the initial report. I've also experienced data loss because of unexpected tab reloads:
* After an incoming call is terminated
* When switching to another tab to look up information, a reload occurs when switching back sometimes
Form contents appear to be preserved across the reload in some cases, but not all:
* data in form fields dynamically created via dom manipulation will be lost (eg the "add comment" field on stack overflow)
* position in any playing videos will be lost
Is there a reason why a tab that is unloaded due to memory pressure cannot have its dom serialized and reloaded locally rather than relying on a full reload?
Comment 4•11 years ago
|
||
(In reply to Julian Hall from comment #3)
> Is there a reason why a tab that is unloaded due to memory pressure cannot
> have its dom serialized and reloaded locally rather than relying on a full
> reload?
The is bug 671993
Comment 5•10 years ago
|
||
Interestingly this is happening quite often on my N9 now (2 GB RAM, Android 5.1.1, Nightly 42.0a1, 2015-07-15). Screencast: https://youtu.be/sSthkrq0xAg
Comment 6•5 years ago
|
||
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•5 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•