Closed Bug 678480 Opened 13 years ago Closed 13 years ago

First-run animation is busted and tab sidebar is visible at startup

Categories

(Firefox for Android Graveyard :: General, defect)

Firefox 9
ARM
Android
defect
Not set
normal

Tracking

(firefox9 fixed, fennec9+)

VERIFIED FIXED
Firefox 9
Tracking Status
firefox9 --- fixed
fennec 9+ ---

People

(Reporter: aaronmt, Assigned: mfinkle)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Mozilla/5.0 (Android; Linux armv7l; rv:8.0a1) Gecko/20110812 Firefox/8.0a1 Fennec/8.0a1

20110812030744
http://hg.mozilla.org/mozilla-central/rev/f262c389193e

STR: New Profile, Launch Nightly
Assignee: nobody → wjohnston
Hmm... can't reproduce this with my locale builds, but I see it on nightly...
Something fixed this (something backed out?), now working on 08/13

Verified WFM
Mozilla/5.0 (Android; Linux armv7l; rv:8.0a1) Gecko/20110813 Firefox/8.0a1 Fennec/8.0a1
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Hm, this is back again.

Build: Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110819 Firefox/9.0a1 Fennec/9.0a1
Device: Samsung Galaxy SII,
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Blocks: 625229
Assignee: wjohnston → sriram
This is very likely a regression from bug 610834, which landed, was backed out, and re-landed at the times this bug appeared, disappeared, and reappeared.
Blocks: 610834
Status: REOPENED → ASSIGNED
I'm also seeing the tab bar exposed on startup on non-firstrun some of the time, which I believe is related to this bug.  On my HTC T-Mobile G2 (Android 2.3), I see this problem only when about:home is shown at startup.

Requesting tracking for Fx9.  If we can't fix this for Fx9, we should back out bug 610834.
tracking-fennec: --- → ?
Version: Trunk → Firefox 9
tracking-fennec: ? → 9+
Bug 686903 removed the fade in animation.
Summary: First-run animation is no more → First-run animation is busted and tab sidebar is visible at startup
I think we should consider leaving bug 610834 in since it fixes a more general issue. We have code at startup that is very specific to the way the previous "resize" events were sent. I'd rather fix (or remove) the busted UI code.

The affected code seems to be the "hideSidebar" code in the resize handler. The code thinks the sidebars have been hidden, but they really have not.
Attached patch patch (obsolete) — Splinter Review
This is a silly patch that forces XUL to layout and setup the scrollbox. Once the scrollbox is setup, the call to hideSidebar seems to work fine.

With this patch, the sidebar is not shown at startup and the animated transitions work in about:home. Tested on Nexus One.
Assignee: sriram → mark.finkle
Attachment #561756 - Flags: review?(wjohnston)
Comment on attachment 561756 [details] [diff] [review]
patch

Review of attachment 561756 [details] [diff] [review]:
-----------------------------------------------------------------

Probably should add a comment. I'm checking if getPosition({}, {}) works, but have to rebuild. Doesn't seem like a big deal to just use this though.
Attachment #561756 - Flags: review?(wjohnston) → review+
Attached patch patch 2Splinter Review
Last patch was still broken.

This patch uses the scroll position to verify something actually worked. It also updates the "x" property with the new scroll position so the next time we see the resize, we don't reset the scroll to zero.

I also tweaked the firstrun animation code in aboutHome. We use a timeout to start the animation so we don't conflict with the code to hide the sidebar. We also use the flipped logic in startDiscovery to check for the sidebars being opened. Sometimes "leftWidth" was 0.0555, so I just check to see if the sidebar is completely open instead. 

I tested:
* initially opening up to home page -> got animation, then sidebar was hidden
* subsequent opening -> sidebar hidden
* reset the ui discovery pref and opened about:home with the sidebar already visible -> no animation

I think that covers it
Attachment #561756 - Attachment is obsolete: true
Attachment #561923 - Flags: review?(wjohnston)
Comment on attachment 561923 [details] [diff] [review]
patch 2

Review of attachment 561923 [details] [diff] [review]:
-----------------------------------------------------------------

Everything about this feels kinda like a hack and makes me nervous. Can you add some comments explaining what's going on in various places?
Attachment #561923 - Flags: review?(wjohnston) → review+
Added comments and found I could remove the setTimeout hack. Retested and pushed to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cbc62f5e79e8
https://hg.mozilla.org/mozilla-central/rev/cbc62f5e79e8
Status: ASSIGNED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 9
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110925 Firefox/9.0a1 Fennec/9.0a1
Status: RESOLVED → VERIFIED
Depends on: 689928
Depends on: 691541
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: