670477 - Forms controls stop working

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[CoJaBo]

Fennec 8.0a1, Tested with Droid X Gingerbread, using Swpye as input.

After the browser has been running for a while (varies, sometimes seems to happen right away, sometimes after a few hours, sometimes doesn't happen for a few days), I've noticed the forms controls stop working-
Text inputs stop typing (only backspace works), and submit and onclick event buttons stop functioning (reset buttons and onclick links still work).
The text inputs sometimes work again after switching tabs then back, but the buttons stay broken until the browser is restarted.

Comment 1

[Aaron Train [:aaronmt]]

Console errors?

Comment 2

[CoJaBo]

I've discovered the situation that leads to the forms controls ceasing to function- see Bug 664802 Comment 6.

Comment 3

[Tony Chung [:tchung]]

We need to steps to reproduce, since comment 1 highlights so many possible variables.   

FWIW, i cannot reproduce right now , Nexus S, 2.3.4, 7/11 nightly, but running SwiftKey (not Swype).   Cojabo, can you try reproducing with the stock android keyboard?

Comment 4

[Matt Brubeck (:mbrubeck)]

I encountered this a couple of times in Nightly (Fx8) and Aurora (Fx7) over the past two weeks while I was using Fennec very heavily.  I did not see it at all on another device where I was primarily using Beta (Fx6).  I could not find steps to reproduce the problem.

Comment 5

[CoJaBo]

(In reply to comment #4)
> I encountered this a couple of times in Nightly (Fx8) and Aurora (Fx7) over
> the past two weeks while I was using Fennec very heavily.  I did not see it
> at all on another device where I was primarily using Beta (Fx6).  I could
> not find steps to reproduce the problem.

What were the devices you used to test this?

Comment 6

[Matt Brubeck (:mbrubeck)]

Samsung Galaxy Tab and T-Mobile G2.

Comment 7

[CoJaBo]

I started recording my phone whenever I could, and I managed to get the issue to happen 4 consecutive times while attempting to comment on an unrelated bug.

Video:
http://ge.tt/89JCiK6?c (preferred)
https://rapidshare.com/files/1764613745/Bug-670477.mp4 (mirror- real download button is hidden near bottom of page)

This was tested with the 8.0a1 2011-07-26 nightly on Droid X with the Swype keyboard.

I attempted a 5th time without Swype (after this recording ends), but I was not able to get it to happen- however, the issue frequently occurs during sessions where the keyboard was never opened, and it took approximately 3 hours to get it to happen while recording with Swype (I only tested without Swype for a few minutes).

This seems to be typical- the issue will happen very frequently for a period of time, after which it may not present again for many hours.

In case someone can note any similarities, here are all the version numbers and other info I can find:
Swype version: 2.50.72.21318.21326
Android version: 2.3.3 Gingerbread
System version: 4.596.MB810.Verizon.en.US
Baseband version: BP_C_01.09.12P
Build number: 4.5_57_DX5-26
Kernel version: 2.6.32.9-g34b306d qgd748@il93lnxdroid09 #1
ERI verison: 5
PRL version: 52220

Batteryminder, Irssi ConnectBot, and Advanced Task Killer Free were running in the background.

It would be helpful to know if this ever occurs without Swype or if there are are any similarities between other hardware this occurs on (because, due to the severity of this issue, there would presumably be a LOT more reports of this if it happened in all devices and configurations).

A large number of tabs are open from the previous (unsuccessful) attempts to replicate the bug. I am not sure if the previous attempts failed becuase this issue requires many tabs open, or if this was simply coincidence, as I was not able to replicate it after these 4 attempts, with or without many tabs open. Open tabs include several of each of https://bugzilla.mozilla.org/show_bug.cgi?id=671131 and 
http://qdb.us/latest/3 (A long page I previously noted the issue on).

Video transcript- I haven't noticed anything consistent between these that might be triggering the bug, It'd be helpful if anyone notices anything else odd:
00:00:05.321	Browser is started (1st time) from Gmail. With the newly opened tab, there are a total of 15 tabs open.
00:01:28.638	First occurrence of bug- shortly after backspace was pressed, but while the screen wasn't being touched. Screen jumps downward when URL bar appears.
00:01:29.139	I hadn't noticed this before, but on the next attempt to type a word, Swype unexpectedly switches capitalize-first-letter mode and does not show the "trail" on the next attempt to type a word. The trail is shown on subsequent attempts, but it erratically switches to capital mode.
00:01:38.832	Cut does not work either. The text was not stored to clipboard.
00:01:41.584	Left arrow still responds, which selected some other input.
00:01:52.696	After having de-selected and re-selected the text input, it is possible to type again.
00:01:56.916	Buttons do not function (this applies to any tab until the browser is restarted).
00:02:02.455	The button animates and selects as normal.
00:02:09.362	This rendering glitch (probably unrelated) happens occasionally and will persist until the page is panned.
00:02:26.062	(The home screen is blurred)

00:02:34.921	Browser is started (2nd time) from Gmail. With the newly opened tab, there are a total of 16 tabs open.
00:03:57.604	Second occurrence of bug- this time, moments after typing a word (which does not show up).

00:04:40.113	Browser is started (3rd time) from Gmail. With the newly opened tab, there are a total of 17 tabs open.
00:05:43.593	Swype disappears due to accidental click outside of textbox- not related.
00:05:45.028	Clicking in the box again scrolls the page up and down erratically- I have no idea why this happened.
00:05:49.733	Third occurrence of bug- this time while attempting to correct a word. The correction dialog disappears moments before I can click it.

00:06:14.074	Browser is started (4th time), this time from app launcher. The last tab is re-used, so there are still a total of 17 tabs open.
00:08:08.004	Fourth occurrence of bug- this time when hitting the right-arrow key. The key does not animate as normal, but does move the cursor.
00:08:10.340	Backspace still works. Also, it caused the URL bar to disappear.
00:08:18.665	Copy All did store the text on the clipboard.
00:08:21.334	However, it will not paste.
00:08:44.774	(The All Pages screen is blurred)
00:09:08.331	The issue persists in all tabs until the browser is restarted.

Comment 8

[Martijn Wargers (dead)]

When this issue happens, is it also difficult to scroll a page? Does a page scroll fluently and does the scrollbar appear/disappear fluently?

Comment 9

[CoJaBo]

Attachment: Video demonstrating panning/scrolling as per request in Comment 8.

Video demonstrating panning/scrolling as per request in Comment 8.

The page shown in the video is http://wiki.xkcd.com/geohashing/2010-03-28_global
There were 20 tabs open total. The builds/software versions are the same as the first video.


There is no impact to scrolling (the erratic scrolling in the first video when selecting the text box [00:05:45.028] does not usually occur with this bug).

The page does get "pushed down" each time the bar appears, as shown in the first video (Comment 7). This does not always happen while typing, however it will always stop buttons from working on any page from that point on, even if the page the URL bar appeared in lacks a submit button or text input at all (like the qdb page listed in previous comment). If the URL bar appears while scrolling, the page will jump down the same (the area under my finger will change), but scrolling will continue to function smoothly from that point without lifting my finger. When scrolling after the URL bar has appeared, one of two things will happen-
The bar will smoothly pan off the screen as the page is dragged up (as it does when scrolling down from the top). If the page is dragged down, the bar is unaffected (stays put, even if it is already halfway off screen from scrolling). Panning side to side to show the side menus will cause the bar to display fully, then it returns to whatever state of (partial) visibility it was at prior. This is shown in the second video (see Attachment 1 [details] [diff]).
Alternately (somewhat rarer), it will stick permanently, and not move off screen when the page is scrolled down. When this has happened, the page will keep getting "pushed down" at random intervals, as if the URL bar is reappearing per the previous case, even though it is always visible. This persists when the browser is switched away from (so long as it isn't unloaded), and normal functionality is only returned when it is restarted.

I've noticed that when it appears, it is likely to do so within the first few minutes of the browser starting, and then continue to reappear every few minutes thereafter (and when it sticks, it still pushes the page down by one URL-bar-height every few minutes, even though the bar is always visible). If the bar does not appear within a half-hour or so, it usually wont for the duration the browser continues to run- but in cases where it does, it tends to keep happening frequently after the first occurrence.

Comment 10

[CoJaBo]

I did encounter this with the stock keyboard (Multi-touch keyboard), so it is not Swype-specific.

Has anyone else noticed this issue at all, on Droid X or otherwise?
It is pretty severe (near-complete loss of functionality on most sites) and quite frequent so I'd expect significantly more reports than just this one, unless it is specific to the Droid X or something?
There are still no steps to reproduce, as the issue still appears totally random.

Droid X also got a minor OTA firmware update this week, current version information-
Android version: 2.3.3 Gingerbread
System version: 4.5.602.MB810.Verizon.en.US
Baseband version: BP_C_01.09.13P
Build number: 4.5.1_57_DX5-32
Kernel version: 2.6.32.9-g34b306d tkwp86@ca25rhe81 #2
ERI verison: 5
PRL version: 52220

Comment 12

[CoJaBo]

The frequency of this bug appears to have reduced dramatically after upgrading to CyanogenMod-
I have noted one instance where forms controls stopped working in the 3 days I've been running it (vs several times per hour on stock).
One major difference I've noticed is that, with no/few apps running, there is a LOT more free memory on CM (100-300M) vs stock (8-60M) (Fennec will nearly always stay running in background unless a call is taken, where on stock it will always terminate immediately upon any app switch).
Could this be some kind of low memory/allocation fault?

Comment 13

[CoJaBo]

I've noticed this accompanies other apps getting killed, which also seems to point to low memory as the cause.

This happens quite infrequently in CyanogenMod, both times I've noticed it were when switching to Fennec after using several other apps.

I've tried to replicate this by artificially tying up RAM in a ramdisk- on Droid X this is accomplished by the stock bloatware, which similarly cannot be unloaded.

Note- This caused my device to reboot on the first attempt.

Make sure your device doesn't have swap turned on- run `free` and make sure the swap line is all zeros (swap on Android is unlikely, but some aftermarket ROMs do this and Bad Things might happen if it is).

I rebooted the device and killed all non-essential running apps before starting Fennec, in an attempt to ensure a clean state.
I also had AdblockPlus installed using EasyList, though the bug has previously happened without this.

#Create a tmpfs- do this as root thru adb shell (substitute some other arbitrary path)
mkdir /sdcard/ram
#The max size is arbitrary, it need only exceed the device installed RAM
mount -t tmpfs none /sdcard/ram -o size=2000m

I then ran the following set of commands to grow a filler file by 10m each time, then used the browser for a while before running it again.
dd if=/dev/zero bs=1048576 count=10 >>/sdcard/ram/wasted ; free ; ls -lh /sdcard/ram/wasted

#Afterward done testing, destroy the ramdisk
umount /sdcard/ram/wasted


At 70m ramdisk usage, I encountered the bug after several minutes of using the browser. The device has 488740k of RAM total shown by running free.
I got to 120m on first attempt, at which point the device rebooted upon receiving an email, though I waited a lot less each time.

I was able to get a logcat on this second attempt. The line "E/ActivityManager( 8502): ANR in com.roflharrison.agenda" is approximately when the URL bar reappeared.
The Agenda app was not present when I was running stock firmware, so is very likely unrelated (possibly a casualty of the low memory situation).
The traces.txt referenced in the logcat will also be attached, not sure if it is related.

After the URL bar appears, no forms submit buttons on any site will work until Fennec is restarted. No additional messages are printed when clicking these buttons.

The browser shows no other odd effects (like large pages failing to load) from memory exhaustion, other than the URL bar continuing to pop up randomly (this didn't happen more than once this time, but was the usual case when I was running the stock firmware). The free memory shown by the free command was approximately triple a minute or so after the URL bar appeared vs immediately before (15m vs 5m), though I'm not sure whether Fennec freed this or Android or is it was freed immediately or several seconds after.

Comment 14

[CoJaBo]

Attachment: logcat for Comment #13

Comment 15

[CoJaBo]

Attachment: traces.txt for Comment #13

Comment 16

[Tony Chung [:tchung]]

Cojabo, can you still reproduce this on the latest Xul beta build?   

Build here:  ftp://ftp.mozilla.org/pub/mobile/candidates/11.0b3-candidates/build1/android-xul/multi/fennec-11.0b3.multi.android-arm.apk

Comment 17

[BMO Automation]

Closing all opened bug in a graveyard component

Comment 18

[Chris Peterson [:cpeterson]]

Removing regressionwindow-wanted keyword because this bug has been resolved.

Comment 19

[Chris Peterson [:cpeterson]]

Removing regressionwindow-wanted keyword because this bug has been resolved.

Comment 20

[Chris Peterson [:cpeterson]]

Removing regressionwindow-wanted keyword because this bug has been resolved.