Closed Bug 525323 Opened 10 years ago Closed 10 years ago

Windows CE ux/perf regression between Alpha 2 and Beta 1


(Firefox :: General, defect)

Windows CE
Not set



Firefox 3.7a1
Tracking Status
status1.9.2 --- beta2-fixed


(Reporter: Dolske, Assigned: Dolske)



(Keywords: verified1.9.2, Whiteboard: [nv])


(1 file, 1 obsolete file)

On the newest (10/16) OS build, the preinstalled Firefox (Alpha 2) is fast and snappy, but Beta 1 is not. Specifically, it seems fast for brief spurts, and otherwise bogs down and is almost completely frozen for up to a minute at a time. I tested with downloading the A1/B2 .zip builds and running them from the SD card, so it seems to be related to something that changed in our code.

1) Ensure Firefox faststart process is not running. [You may want to just install Firefox from the OS, so that a reboot ensures it's always gone. File->Exit from the browser will also ensure it's gone -- just closing the browser window with [x] does not]

2) Run a Firefox build.

3) Browse a couple of sites, wiggle the mouse pointer around with the trackpad.
   Good: sites load quickly, mouse pointer generally moves smoothly
   Bad: browser seems frozed (loading, or typing in URL bar, or opening menus),
        mouse pointer moves in jerky steps.

A few interesting quirks I've noticed:

* When things freeze up, moving the pointer with the trackpad exhibits jerky motion, but moving it with a USB mouse is fine.

* After a page is loaded and things seem fine, I can generally wiggle the pointer in an empty area of the page, but touching a link or UI button will often trigger the freezing / slow cursor.

* On the 10/16 OS build, the difference between A2 and B1 is night-and-day. On earlier builds and the last Oban build, I have a hard time telling them apart -- they're both really slow.
Flags: blocking-firefox3.6?
CCing QA, narrowing down the regression window would be a huge help.
Assignee: nobody → dolske
Yes, I just mentioned that I was seeing this to rstrong. Will start the regression hunt.
Any progress on a regression range for this?  This bug is critical for us atm, we can't deliver builds unless we track it down.
none to report atm.   however, marcia and i will get onto hunting this down as soon as we ship 3.6b1 today.  dolske, is there a particular site or sites you can point out that will help us narrow down this rat race?  Also, i assume we want to target builds between Alpha 2 (9/20/09) and (10/16) nightlies?
I am working on this intermittently as we try to ship B1.

I did install the 20090929 build and I see the same horked state. However, the OS becomes unstable when I try to restart, which makes testing difficult. At times I have still had this version of the OS become unstable - the Namoroka nightlies freeze in the middle of loading.

Also, rstrong suggested I try shutting off JIT chrome as well as deleting compreg.dat and compatibility.ini. But I haven't had too much luck getting the browser into a state where I could actually change the JIT state yet.
(In reply to comment #4)
> dolske, is there a particular site or sites you
> can point out that will help us narrow down this rat race?

Just try going to a couple of basic sites like and It's quickly obvious if it's working or not. [I'd avoid complicated sites pulling in Flash and other crud for the purposes of this bug.]
Narrowed down range:

09-15-04 nightly is ok.
09-19-03 nightly is bad.

Alpha 2 build 1 branched on 9/16, so this seems likely to be something that landed soon after branching.
09-16-03 nightly is ok
09-17-03 nightly is bad.

Checked each build twice, rebooting in between.

Regression range:

Bug 511167 immediately makes me suspicious (as it did when it landed, now I wish I has tested that specifically), especially after having dealt with bug 510627. It looks like that was intended to be WinMo-only, though it had a rough landing so maybe some of the post-landing fixups were not quite right.

I'll do some build bisecting to see where blame lies.
Checked the regression range for mozilla-central, dougt suggests bug 475595 may be the more likely cause, and it landed on a different day than 511167.

trunk 08-27-03 nightly is ok.
trunk 08-28-03 nightly is ok.
trunk 09-14-03 nightly is ok.
trunk 09-15-03 nightly is bad.

Regression range on trunk:

Bug 475595 and bug 515818 are the only common bugs in these two regression range.
Confirmed that this is bug 475595... Commenting out the calls to GlobalMemoryStatus() in IsLowMemory() [and returning PR_FALSE instead] made the browser fast again.

The comment is also a dead giveaway. :-/

118 #if defined(WINCE)
119     *result = PR_FALSE;
120     // See bug 475595 -- this is incorrect right now, and causes a big
121     // perf hit since GlobalMemoryStatus has to grab a kernel VM lock
122     // and do a bunch of munging through VM pages to get the data
123     // that's requested.  We call IsLowMemory in some performance
124     // critical code (e.g. during painting), so that's bad.
125     MEMORYSTATUS stat;
126     GlobalMemoryStatus(&stat);
127     *result = (stat.dwMemoryLoad >= 98);
128 #elif defined(XP_WIN)
Blocks: 475595
Target Milestone: --- → Firefox 3.7a1
Attached patch Patch v.1 (obsolete) — Splinter Review
Needs a better long term solution, but I think we should land this ASAP to make nightlies usable again.
Attachment #409476 - Flags: review?(vladimir)
Comment on attachment 409476 [details] [diff] [review]
Patch v.1

can you only return FALSE on WINCE, and just make what it currently is doing WINCE_WINDOWS_MOBILE.

For whatever reason, i am not seeing a terrible perf problem on windows mobile 6.5.
Attachment #409476 - Flags: review?(vladimir) → review-
Attached patch Patch v.2Splinter Review
Patch to leave it as-is on WinMo, but disabled on WinCE.

Vlad r+a192'd this via email from a hockey game, so I'll check it in now. :)
Attachment #409476 - Attachment is obsolete: true
Pushed to 192:

Do we need a followup bug to implement something real here?
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 409477 [details] [diff] [review]
Patch v.2

We could look at a followup bug, but I'm not too worried about doing so.
Attachment #409477 - Flags: review+
Attachment #409477 - Flags: approval1.9.2+
Thanks for the quick fix. Going to grab the latest nightly to take it for a whirl.
Whiteboard: [nv]
Verified fixed using Mozilla/5.0 (Windows; U; WindowsCE 6.0; en-US; rv:1.9.2b2pre) Gecko/20091031 Namoroka/3.6b2pre. Build runs much smoother. Adding keyword.
Keywords: verified1.9.2
i concur the build is now in a usable and responsive state.  verifying on trunk: Mozilla/5.0 (Windows; U; WindowsCE 6.0; en-US; rv:1.9.3a1pre) Gecko/20091031 Minefield/3.7a1pre

the only thing though, its crashy.  i had to restart 3 times here on bugzilla.  but will investigate more and track in another bug.
Already fixed, but we would have held the release to understand why WinCE was unusable, marking this blocking+ for bookkeeping.
Flags: blocking-firefox3.6? → blocking-firefox3.6+
I noticed that there may be a bug in the original implementation:
 dwLength of struct MEMORYSTATUS should be initialized before calling GlobalMemoryStatus

+   stat.dwLength = sizeof(stat);

BTW: I'm not sure if this caused the problem, but I'm goint to use a Win32 Timer to track memory in my private build.
Just FYI, the timer-based patch is working on my CE 6 device well. Once the free memory hitted the limit, all graphics rendering was stopped, and I could stop firefox without crashing.

I used dwAvailPhys other than dwMemoryLoad, which may be more precise.
You need to log in before you can comment on or make changes to this bug.