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



Fennec Graveyard
6 years ago
6 years ago


(Reporter: fryn, Assigned: mbrubeck)


({regression, verified-aurora})

Firefox 9
Firefox 9
regression, verified-aurora


(Whiteboard: [pushed][qa!])


(1 attachment)



6 years ago
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
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 689928

Comment 2

6 years ago
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:

[2] I made a typo in the original description. s/hadn't/had/
Resolution: DUPLICATE → ---
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:

Comment 7

6 years ago
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.

Comment 10

6 years ago
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.


6 years ago
tracking-firefox9: --- → ?
Keywords: regression, regressionwindow-wanted
status-firefox10: --- → affected
status-firefox9: --- → affected
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.
Duplicate of this bug: 689928
tracking-fennec: --- → 9+
tracking-firefox9: ? → ---

Comment 14

6 years ago
I can reproduce this in my local build from mozilla-central tip.
Assignee: nobody → mbrubeck

Comment 15

6 years ago
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.
Blocks: 678480
Keywords: regressionwindow-wanted

Comment 16

6 years ago
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.
Attachment #569155 - Flags: review?(mark.finkle)


6 years ago
Whiteboard: [has patch]
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.

Well done!
Attachment #569155 - Flags: review?(mark.finkle) → review+

Comment 18

6 years ago
status-firefox10: affected → fixed
Whiteboard: [has patch] → [pushed]
Target Milestone: --- → Firefox 10

Comment 19

6 years ago
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.
Attachment #569155 - Flags: approval-mozilla-aurora?


6 years ago
Whiteboard: [pushed] → [pushed][QA+]
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED


6 years ago
Attachment #569155 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 21

6 years ago
status-firefox9: affected → fixed
Target Milestone: Firefox 10 → Firefox 9
Version: Trunk → Firefox 9

Comment 22

6 years ago
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.
Whiteboard: [pushed][QA+] → [pushed]
Keywords: verified-aurora
Whiteboard: [pushed] → [pushed][qa!]
You need to log in before you can comment on or make changes to this bug.