Launch Firefox. The non-interactive image display a white "content area" in the correct position, but when the UI and page actually load, the content area is offset a few pixels to the right. Upon sliding one's finger to pan the UI to the left, the UI corrects itself, and the anomaly no longer appears.
This happens as long as it was a cold startup (i.e. Firefox hadn't been quit or killed by the OS). It doesn't matter whether it's loading about:home or restoring a tab from a previous session.
I encountered this while running the latest nightly.
User agent: Mozilla/5.0 (Android; Linux armv7I; rv:10.0a1) Gecko/20111003 Firefox 10.0a1 Fennec/10.0a1
OS: Android 2.3.4
Phone: Samsung Galaxy S 4G
dupe of bug689928
*** This bug has been marked as a duplicate of bug 689928 ***
I don't think this was a duplicate of bug 689928.
Matt Brubeck said in bug 689928 comment #11 that bug 689928 was "a user-visible regression in the first-run animation on Android 2.2 devices."
I'm still seeing this bug in a nightly build that contains the changeset to fix that bug , and I'm on Android 2.3. It occurs on every cold start (i.e. Firefox had been quit or killed by OS ), not just first run.
User agent: Mozilla/5.0 (Android; Linux armv7I; rv:10.0a1) Gecko/20111009 Firefox/10.0a1 Fennec/10.0a1
Phone/OS: Samsung Galaxy S 4G running Android 2.3.4 (Gingerbread)
If you guys can't reproduce this and need a screenshot, let me know.
 I saw this in the nightly for 20111008 too, and I checked this file: https://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2011-10-08-03-09-46-mozilla-central-android/fennec-10.0a1.multi.android-arm.txt
 I made a typo in the original description. s/hadn't/had/
Frank, a screenshot would be helpful
OK, I still see this in the nightly, but not in the build I made with the fix. Looking into it.
The nightly does have the fix. I opened the APK and found browser.xul.
I made a new local build using a fresh pull from mozilla-central. This build has no other patches - it's straight m-c, and it does not show the bad offset:
If I understand you correctly, I see the same things as you do:
1. The nightly has the fix, but I see the bug.
2. fennec-10.a1-nofixedsize.apk also has the fix, but I don't see the bug.
Screenshots of the nightly:
1. On completion of startup:
2. After panning the content area to the left to fix the offset:
(In reply to Frank Yan [:fryn] from comment #7)
> If I understand you correctly, I see the same things as you do:
> 1. The nightly has the fix, but I see the bug.
> 2. fennec-10.a1-nofixedsize.apk also has the fix, but I don't see the bug.
Correct. Thanks for verifying.
The first thing that comes to mind is Nightly is a multi-locale build, while my build is not. I have no idea right now what affect multi-locale would have, but it's a difference. I'm going to look for a single-locale build on our FTP, to see if presence of locales has something to do with it or not.
Another thing would be for someone else to make a local build and see if the bug is present or not.
Matt - can you see this bug in a personal build and check?
Single locale (Nightly) build from here also _has_ the bug:
So it seems locales are not the issue.
I haven't had time to test a local build yet, but another possibility is that something in the profile is triggering the bug. (You could test this by wiping your Nightly profile and starting with a clean one.)
Clearing the profile did not fix the problem. I am building a "nightly" branded build locally, to see if that is related.
I can't make a build that has this problem locally. But, it seems that Try builds also have this problem. I can submit some patches to Try and see if something affects this issue.
I also wonder what is so different about my builds that cause this not to happen.
*** Bug 689928 has been marked as a duplicate of this bug. ***
I can reproduce this in my local build from mozilla-central tip.
According to testing in the duplicate bug, this is a regression from bug 678480.
Like mfinkle, I can't reproduce this using *his* local build from comment 6. His build has a few different options from mine and the official builds, including --enable-functiontimer which might affect startup timing.
Created attachment 569155 [details] [diff] [review]
This is a terribly hacky band-aid patch, but (A) we really need something simple we can land in Aurora for update 9, and (B) I can't justify spending too many more hours on this to come up with a proper fix (because we are not planning on shipping the XUL UI on Android in the long term).
The main downside of this approach (aside from general hackiness) is that it's possible that on some platforms, if you open the sidebar and then rotate the device, the sidebar will not stay open the first time you do this after launching Fennec. I think this slight risk is well worth fixing this bug.
Comment on attachment 569155 [details] [diff] [review]
This is actually cleaner than I thought, given XUL's resize-happy nature. This should keep other platforms from breaking, except for the noted issue where a sidebar might not remain visible after a rotation - which isn't too bad anyway.
Comment on attachment 569155 [details] [diff] [review]
Requesting approval for Aurora 9. This fixes a minor but visible (and annoying) regression in update 9, which happens on every single Firefox startup in the phone UI on Android. The bug causes one sidebar to be exposed by a few pixels on startup, which makes startup seem a bit janky and unpolished, and makes it harder to open the opposite sidebar if you try to do it right after launch.
The fix is mobile-only and is highly targeted at the symptom of this bug. I believe it is very safe and should have no side effect, but see comment 16 and comment 17 for a discussion of risk to non-Android platforms.
Build ID: Mozilla/5.0 (Android; Linux armv7l; rv:9.0a2) Gecko/20111026 Firefox/9.0a2 Fennec/9.0a2
Build ID: Mozilla/5.0 (Android; Linux armv7l; rv:10.0a1) Gecko/20111026 Firefox/10.0a1 Fennec/10.0a1
Device: HTC Desire Z
OS: Android 2.3
Verified on both Aurora and Nightly with warm and cold start up, content area is correctly displayed upon startup.