691541 - content area is incorrectly offset a few pixels to the right upon startup

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Frank Yan (:fryn)]

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

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

dupe of bug689928

Comment 2

[Frank Yan (:fryn)]

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 [1], and I'm on Android 2.3. It occurs on every cold start (i.e. Firefox had been quit or killed by OS [2]), 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.

[1] 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

[2] I made a typo in the original description. s/hadn't/had/

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Frank, a screenshot would be helpful

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

OK, I still see this in the nightly, but not in the build I made with the fix. Looking into it.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

The nightly does have the fix. I opened the APK and found browser.xul.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

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:

http://people.mozilla.com/~mfinkle/fennec/fennec-10.a1-nofixedsize.apk

Comment 7

[Frank Yan (:fryn)]

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:
   https://people.mozilla.com/~fyan/screenshots/before.png
2. After panning the content area to the left to fix the offset:
   https://people.mozilla.com/~fyan/screenshots/after.png

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

(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?

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Single locale (Nightly) build from here also _has_ the bug:
http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-android/en-US/fennec-10.0a1.en-US.android-arm.apk

So it seems locales are not the issue.

Comment 10

[Matt Brubeck (:mbrubeck)]

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.)

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Clearing the profile did not fix the problem. I am building a "nightly" branded build locally, to see if that is related.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 14

[Matt Brubeck (:mbrubeck)]

I can reproduce this in my local build from mozilla-central tip.

Comment 15

[Matt Brubeck (:mbrubeck)]

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.

Comment 16

[Matt Brubeck (:mbrubeck)]

Attachment: patch

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 17

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 569155 [details] [diff] [review]
patch

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.

Well done!

Comment 18

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/10b170661003

Comment 19

[Matt Brubeck (:mbrubeck)]

Comment on attachment 569155 [details] [diff] [review]
patch

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.

Comment 20

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/10b170661003

Comment 21

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/575e780f1e75

Comment 22

[Camelia Urian]

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.