Last Comment Bug 602252 - Some web pages result in a complete freeze for many seconds on Droid
: Some web pages result in a complete freeze for many seconds on Droid
Status: RESOLVED WONTFIX
[Input], resolveme Dec 7
: relnote
Product: Fennec Graveyard
Classification: Graveyard
Component: General (show other bugs)
: Trunk
: ARM All
: -- major with 8 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://m.lifehacker.com/5656214/how-t...
: 602328 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-06 10:42 PDT by Aaron Train [:aaronmt]
Modified: 2011-03-29 12:34 PDT (History)
19 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Droid 2 Screenshot (44.10 KB, image/png)
2010-10-06 11:43 PDT, Naoki Hirata :nhirata (please use needinfo instead of cc)
no flags Details

Description Aaron Train [:aaronmt] 2010-10-06 10:42:09 PDT
Mozilla/5.0 (Android; Linux armv7l; rv:2.0b7pre) Gecko/20101005 Firefox/4.0b7pre Fennec/4.0b1

Visiting the URL listed above will result in a browser hang and ultimately a phone lock (removal of battery).

Tested on my Motorola Milestone (Verizon Droid) and confirmed on Droid 2
Comment 1 Naoki Hirata :nhirata (please use needinfo instead of cc) 2010-10-06 11:36:52 PDT
Mozille/5.0 (Android; Linux armv71; rv:2.0b7pre) Gecko20101005 Firefox/4.0b7pre Fennec/4.0b1

If the page is viewed in portrait, the page does not lock.  The page also does not lock when going from portrait to landscape.  Refreshing while in landscape mode does not show the issue either.  Plugin is found on the page.

The bug only occurs on the initial download in landscape mode and then panning down.

smaller versions of the url:
http://goo.gl/N1P4
http://tinyurl.com/2bdnkvd
Comment 2 Brad Lassey [:blassey] (use needinfo?) 2010-10-06 11:41:03 PDT
I can't reproduce this on my nexus one with beta 1 build 2
Comment 3 Naoki Hirata :nhirata (please use needinfo instead of cc) 2010-10-06 11:43:50 PDT
Created attachment 481295 [details]
Droid 2 Screenshot

I had left the droid 2 alone for a while to see if there's any response what so ever.  Sync account was disconnected.  Received error message : Unresponsive script ; script : chrome://browser/content/browser.js:2333

See attached screenshot
Comment 4 Aaron Train [:aaronmt] 2010-10-06 11:55:43 PDT
This happens if I start in landscape and scroll down, the content area will turn grey and my device locks up. I'll let it sit for a while and see if I get the same message.
Comment 5 Matt Brubeck (:mbrubeck) 2010-10-06 13:26:06 PDT
I can't produce this in a trunk Android build on G2.  (I haven't tested b1 build 2 yet.)  If this is fixed on trunk, it would be good to find a regression range for when it appeared and/or disappeared.
Comment 6 Matt Brubeck (:mbrubeck) 2010-10-06 13:28:30 PDT
I couldn't reproduce this in 4.0b1-build2 on my G2 either (launching Fennec in landscape and immediately opening the Lifehacker link).  So maybe it's not different on trunk after all.
Comment 7 Aaron Train [:aaronmt] 2010-10-06 14:25:26 PDT
I've left my device for a couple hours, and I have returned to it on the same page with Warning: Unresponsive Script @ PromptService.js:118, clicking Stop Script prompts again @ browser.js:2333 - So I am getting two dialogs
Comment 8 Jim Chen [:jchen] [:darchons] 2010-10-06 14:40:55 PDT
Probably Droid (2?) specific. Those devices tend to lock up when we run out of shared memory.
Comment 9 Matt Brubeck (:mbrubeck) 2010-10-06 15:03:16 PDT
When I unzip the 4.0b1-build2 APK, browser.js line 2333 is Tab.prototype["get browser"].  PromptService.js:118 is in PromptService.prototype.getDocument.  Neither of these seems likely to cause the hang.  If jchen is right then it might not be directly related to any particular frontend code.
Comment 10 Patrick Walton (:pcwalton) 2010-10-07 14:42:27 PDT
I get this often on TechCrunch articles, such as this on my Droid 1: http://bit.ly/9uLh8p

Perhaps this is related to the large number of iframes that these sites create for the Like button?
Comment 11 Aaron Train [:aaronmt] 2010-10-07 16:38:02 PDT
This seems better on build3 for beta 1, or what is now beta 1. Could the JIT fix have an affect on this?
Comment 12 Mark Finkle (:mfinkle) (use needinfo?) 2010-10-07 18:16:08 PDT
Bug 602670 disables the slow script dialog for chrome scripts. More times than not, if a chrome script warning appears in Fennec, the device is dying from CPU or memory starvation. Usually not caused at all by the chrome script in question.
Comment 13 Matt Brubeck (:mbrubeck) 2010-10-07 22:59:22 PDT
The dialog is gone, but the OS-wide freeze reported in this bug is still a problem.
Comment 14 Mark Finkle (:mfinkle) (use needinfo?) 2010-10-07 23:09:30 PDT
(In reply to comment #13)
> The dialog is gone, but the OS-wide freeze reported in this bug is still a
> problem.

Do we have other bugs for freezes, hangs and memory usage? If not, then yeah we need one.
Comment 15 Vekter 2010-10-08 11:31:36 PDT
Happening to me on any page I visit in landscape. Using portrait works fine, though I still hang on email/twitter syncs and zooming takes FOREVER to render.

Looking forward to a fix for this. It's a damn shame this bug got through; otherwise, this is a definite replacement for the default browser for me.
Comment 16 Vekter 2010-10-08 15:19:24 PDT
Posting to confirm: As far as I can see, moving Firefox to the SD card (using external apps or CyanogenMod) goes a long way to fixing this bug.
Comment 17 Aaron Train [:aaronmt] 2010-10-08 18:04:04 PDT
Digg.com, is another website (mobile version), where loading it on my Milestone results in a complete hang of my device, and the only way out is through battery removal.
Comment 18 Matt Brubeck (:mbrubeck) 2010-10-09 13:12:01 PDT
I wonder if this is happening only in landscape mode on Droid(2) because it is 854 pixels wide (unlike our other target devices which are 800 pixels).

If you change this pref to 854 or higher using about:config, does it affect this bug?

pref("toolkit.browser.cachePixelX", 800);
Comment 19 Aaron Train [:aaronmt] 2010-10-09 14:23:02 PDT
Build: Mozilla/5.0 (Android; Linux armv7l; rv:2.0b8pre) Gecko/20101009
Firefox/4.0b8pre Fennec/4.0b2pre

With today's nightly and landscape browsing at bug URL I'm not getting complete device locks, but process hangs

Preference: toolkit.browser.cachePixelX

Pref value:  800
Result: Page load after a minute of locking up, (UI and content) scroll down a bit, content area turns grey and eventually get (Sorry! Fennec is not responding force close dialog). Return to Homescreen.

Pref: value: 854 (default)
Result: Page loads, still a lock up, scroll down a bit and content area turns grey. Unable to access the UI, panning doesn't do anything. Able to escape with Home button to Homescreen.

--

Now a site like http://m.680news.com loads without issue, no hangs and able to scroll up and down rather fast without issue.
Comment 20 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2010-10-13 15:14:12 PDT
Do the droid phones use swap space?  If so, us gobbling memory for gfx surfaces might be causing the phone to thrash swap.  That would explain the hanginess across chrome/content.
Comment 21 Aaron Train [:aaronmt] 2010-10-14 08:41:00 PDT
(In reply to comment #20)
> Do the droid phones use swap space?  If so, us gobbling memory for gfx surfaces
> might be causing the phone to thrash swap.  That would explain the hanginess
> across chrome/content.

Yes, and most likely
Comment 23 Aaron Train [:aaronmt] 2010-10-21 18:24:08 PDT
Not so much seeing hangs anymore as I am now experiencing a plethora of website loading crashes. If there are other Droid/Milestone users out there who are experiencing the same, please comment.
Comment 24 Tim Martin 2010-10-24 17:26:48 PDT
I'm using a droid 1, stock 2.2 android.

The last several days, fennec has crashed frequently on all sorts of sites, many of which were stable before.
Comment 25 CoJaBo 2010-10-31 05:34:39 PDT
Droid X, 2.1 firmware-
I seem to be experiencing this bug, mostly on face book. Browser becomes slow, then phone completely stops responding. Happens frequently enough that I'm still stuck with the stock browser :-(
Comment 26 Tim Martin 2010-11-06 08:35:52 PDT
I'm not seeing the crazy amount of crashes I saw before, but still see freezes fairly often.  I _think_ it most often happens on pages with several images.  (related, Bug 608385?)

I've always had the impression that zooming in increases performance problems.
Comment 27 Mark Finkle (:mfinkle) (use needinfo?) 2010-11-06 10:53:18 PDT
(In reply to comment #26)
> I'm not seeing the crazy amount of crashes I saw before, but still see freezes
> fairly often.  I _think_ it most often happens on pages with several images. 
> (related, Bug 608385?)

Could be related. We landed some memory leak fixes (see bug 609678) which might help too.

Also, make sure you submit any crash stacks. Links to the http://crash-stats.mozilla.com/products/Fennec would be very helpful.
Comment 28 Doug Turner (:dougt) 2010-11-16 15:51:04 PST
*** Bug 602328 has been marked as a duplicate of this bug. ***
Comment 29 Doug Turner (:dougt) 2010-11-30 13:05:22 PST
Aaron, do you still see this with the nightlies?  I have a droid 2 and haven't been able to reproduce.
Comment 30 Aaron Train [:aaronmt] 2010-11-30 13:38:17 PST
Yes. Albeit, what I get very often is Unresponsive Script dialogues (Motorola Milestone). Happens on huffingtonpost.com.
Comment 31 Doug Turner (:dougt) 2010-11-30 14:47:20 PST
aaron, what scripts are they?  browser scripts, or content scripts?
Comment 32 Aaron Train [:aaronmt] 2010-12-02 07:37:11 PST
(In reply to comment #31)
> aaron, what scripts are they?  browser scripts, or content scripts?

Content scripts that trigger the stop script prompt, followed by the the Close/Reload Tab prompt.
Comment 33 Keith Davis 2011-01-07 05:59:25 PST
We're seeing what appears to be the same (or same type) of bug using the Archos 101 on our Intranet site. It's heavily laden with load, reload scripts.

Freezes after loading and won't ever start responding. Even crashes Android and reboots the device.
Comment 34 Aaron Train [:aaronmt] 2011-01-07 06:14:53 PST
I think it's pretty clear, our devices don't have the ram required for Fennec to operate normally.
Comment 35 bz.marv 2011-01-17 04:33:46 PST
Hi, I had this problem on my milestone, but it seems to be gone since the nightly of january 14th. It gets slow sometimes and other apps are slowed down too as long as fennect lives in background, but there are no freezes anymore for me.
Comment 36 Matt Brubeck (:mbrubeck) 2011-01-21 06:22:38 PST
Is anyone still seeing this in today's nightly build, since bug 624652 landed?
Comment 37 Tim Martin 2011-01-21 13:46:13 PST
I think so?  planet.mozilla.org still crashes for me.  (For whatever reason that site destroys Fennec worse than any other I might wish to browse.)

Err, I now see that the bug you link to was reopened, citing exactly the same page!  Well, guess this is confirmation that I see the same on a Droid 1.
Comment 38 Doug Turner (:dougt) 2011-01-25 13:17:02 PST
bug 624652 is specific to the nexus s and does not do anything on other devices.
Comment 39 Stuart Parmenter 2011-02-09 10:33:42 PST
We are not blocking the release on performance on the Droid 1.  We will continue to improve overall performance it should get better and faster, but given the low amount of memory on the device there just isn't much memory available.
Comment 40 Aaron Train [:aaronmt] 2011-02-09 14:50:56 PST
(In reply to comment #37)
> I think so?  planet.mozilla.org still crashes for me.  (For whatever reason
> that site destroys Fennec worse than any other I might wish to browse.)
> 
> Err, I now see that the bug you link to was reopened, citing exactly the same
> page!  Well, guess this is confirmation that I see the same on a Droid 1.

No crashes on pmo, but 'close/reload tab prompt. In general, I have been seeing less crashes, but overall more close tab prompts and content (e.g, jquery) stop-script warnings. Tested on 02/09 nightly.
Comment 41 Tim Martin 2011-02-19 09:19:06 PST
With the current (Feb 19th) nightly, I have seen no freezing or crashing on previously problematic pages, such as planet.mozilla.org.  I did switch to Gingerbread and start overclocking though, so not sure if it's an actual change in fennec behavior (possibly the decode-on-draw stuff?) or not.

If anyone cares to find out I can revert back to my old configuration to test, but since the Droid 1 isn't officially supported not sure if matters.  :)
Comment 42 Calife 2011-03-26 07:37:22 PDT
Why is this a "wontfix" resolution?  This has been transitioned between won't and will fix at least once before.  Such a transition warrants a comment at the very least!
Comment 43 CoJaBo 2011-03-26 07:46:02 PDT
Also wondering why this is a wontfix-
Current Firefox still crashes Droid X quite frequently. Is there no intent to support the entire Droid line of phones, and if so, why?
Comment 44 Aaron Train [:aaronmt] 2011-03-26 08:09:39 PDT
(In reply to comment #42)
> Why is this a "wontfix" resolution?  This has been transitioned between won't
> and will fix at least once before.  Such a transition warrants a comment at the
> very least!

(In reply to comment #43)
> Also wondering why this is a wontfix-
> Current Firefox still crashes Droid X quite frequently. Is there no intent to
> support the entire Droid line of phones, and if so, why?

This bug is in particular to the Motorola Droid/Milestone. Please read comment #39
Comment 45 CoJaBo 2011-03-26 08:22:24 PDT
> This bug is in particular to the Motorola Droid/Milestone. Please read comment
> #39
The original description confirms on Droid 2, which has 512 mb ram like the X- though the specific url given no longer causes an immediate crash.
Should I file a new bug for freezing/phone lockup issues for the Droid X?
Comment 46 Matt Brubeck (:mbrubeck) 2011-03-26 08:48:16 PDT
(In reply to comment #45)
> Should I file a new bug for freezing/phone lockup issues for the Droid X?

Yes, please.
Comment 47 Vekter 2011-03-26 08:57:18 PDT
In regards to comment #39, Mozilla was all about fixing this until recently. I'd still like to know why, all of a sudden, there's no support for Droid 1. Why cut out a good fraction of your userbase just because of a bug? Is it that hard to fix?
Comment 48 Calife 2011-03-26 09:23:47 PDT
(In reply to comment #47)
> In regards to comment #39, Mozilla was all about fixing this until recently.
> I'd still like to know why, all of a sudden, there's no support for Droid 1.
> Why cut out a good fraction of your userbase just because of a bug? Is it that
> hard to fix?

I must agree with Vekter... the beta 5 release actually worked rather smoothly on my d1 for 3 days before it started to flake out.  Tim Martin's post (41) indicated no apparent problems on his d1 albeit he's on GB and overclocked.  Does that somehow magically increase that phone's memory?  If it really worked for him doesn't that mean it isn't a memory issue?
Comment 49 CoJaBo 2011-03-26 09:26:55 PDT
I've filed bug 645340 to cover the periodic freezing issues I'm experiencing on Droid X.
Comment 50 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2011-03-26 09:32:06 PDT
(In reply to comment #48) 
> Does that somehow magically increase that phone's memory?  If it really worked
> for him doesn't that mean it isn't a memory issue?

For me, I've seen these problems (freezing/crashing) all the time on the Droid 1. For me, things gradually started improving in the more recent builds.
Comment 51 Aaron Train [:aaronmt] 2011-03-26 09:48:38 PDT
(In reply to comment #47)
> In regards to comment #39, Mozilla was all about fixing this until recently.
> I'd still like to know why, all of a sudden, there's no support for Droid 1.
> Why cut out a good fraction of your userbase just because of a bug? Is it that
> hard to fix?

Please re-read comment #39. This bug *in particular* was denied blocking our upcoming release. This has no bearing on or any future performance gains if any on the Motorola Droid/Milestone.
Comment 52 Calife 2011-03-27 08:12:02 PDT
My feeling is that I have absolutely no problem with this particular defect not holding up the release.  Fennec still sort of works on the Droid/Milestone.  However IF the issue IS due to the lack of memory, it's usually not a bad thing to try and optimize the footprint of an application.  I'll even concede that it may not be possible...

Note You need to log in before you can comment on or make changes to this bug.