Closed Bug 602252 Opened 14 years ago Closed 13 years ago

Some web pages result in a complete freeze for many seconds on Droid

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(fennec-)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
fennec - ---

People

(Reporter: aaronmt, Unassigned)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: [Input], resolveme Dec 7)

Attachments

(1 file)

Droid 2 Screenshot
44.10 KB, image/png
Details 
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
Summary: Lifehacker article results in a browser hang and phone lock → Lifehacker article results in a browser hang and device lock
tracking-fennec: --- → ?
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
I can't reproduce this on my nexus one with beta 1 build 2
Attached image 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
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.
OS: Android → All
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.
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.
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
Summary: Lifehacker article results in a browser hang and device lock → Lifehacker article results in a unresponsive script dialogs
Probably Droid (2?) specific. Those devices tend to lock up when we run out of shared memory.
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.
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?
Summary: Lifehacker article results in a unresponsive script dialogs → Lifehacker article results in a unresponsive script dialogs on Droid, Droid 2
This seems better on build3 for beta 1, or what is now beta 1. Could the JIT fix have an affect on this?
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The dialog is gone, but the OS-wide freeze reported in this bug is still a problem.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Lifehacker article results in a unresponsive script dialogs on Droid, Droid 2 → Some web pages result in a complete freeze for many seconds on Droid, Droid 2
(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.
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.
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.
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.
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);
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.
Assignee: nobody → doug.turner
tracking-fennec: ? → 2.0+
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.
(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
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.
Keywords: relnote
Summary: Some web pages result in a complete freeze for many seconds on Droid, Droid 2 → Some web pages result in a complete freeze for many seconds on Droid
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.
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 :-(
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.
(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.
Aaron, do you still see this with the nightlies?  I have a droid 2 and haven't been able to reproduce.
Whiteboard: [Input] → [Input], resolveme Dec 7
Yes. Albeit, what I get very often is Unresponsive Script dialogues (Motorola Milestone). Happens on huffingtonpost.com.
aaron, what scripts are they?  browser scripts, or content scripts?
(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.
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.
I think it's pretty clear, our devices don't have the ram required for Fennec to operate normally.
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.
Is anyone still seeing this in today's nightly build, since bug 624652 landed?
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.
bug 624652 is specific to the nexus s and does not do anything on other devices.
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.
(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.
Assignee: doug.turner → nobody
tracking-fennec: 2.0+ → 2.0-
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.  :)
Status: REOPENED → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → WONTFIX
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!
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?
(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
> 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?
(In reply to comment #45)
> Should I file a new bug for freezing/phone lockup issues for the Droid X?

Yes, please.
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?
(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?
I've filed bug 645340 to cover the periodic freezing issues I'm experiencing on Droid X.
(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.
(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.
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...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: