605484 - urlbar does not unfloat completely when dismissed

Status: RESOLVED DUPLICATE of bug 605138

(Firefox for Android Graveyard :: General, defect)

Description

[Matt Brubeck (:mbrubeck)]

Attachment: screenshot

1. Open a long remote page, e.g. http://news.ycombinator.com
2. Scroll to the bottom of the page so the top bar is not visible
3. Make the top bar appear by opening a sidebar (or pressing the Search key, or the Menu key).
4. Close the sidebar (or press Back to dismiss the site menu or awesomescreen).

Expected results: top bar disappears again
Actual results: top bar is still partially visible

This is 100% reproducible on both of my Android devices (G2 and N1) in the latest nightly build and my local builds from the last several days.  On one Android device, it became reproducible only after wiping the profile and doing a clean install of Fennec.  It is not reproducible in any desktop Linux build that I've tried.

Comment 1

[Aakash Desai [:aakashd]]

I can confirm on build:
Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101020 Namoroka/4.0b8pre Fennec/4.0b2pre

Comment 2

[Matt Brubeck (:mbrubeck)]

I strongly suspect this happens because a selection event in the #urlbar-edit textbox causes it to scroll into view:
http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsContentEventHandler.cpp#985

Vivien says that the selection event may be generated when changing the urlbar's position:fixed style causes the inner editor to be re-created.

Comment 3

[Matt Brubeck (:mbrubeck)]

Based on bisecting with nightly builds, this regressed between the 2010-10-12-04 nightly, and the 2010-10-13-16 nightly (both mozilla-central-android-r7):
http://hg.mozilla.org/mobile-browser/pushloghtml?startdate=2010-10-12+04%3A00&enddate=2010-10-13+16%3A30
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-10-12+04%3A00&enddate=2010-10-13+16%3A30

Nothing obvious in there, but bug 600846 (which changed the .textbox-input-box binding) and bug 602431 (which changed shadow layer processing) looked worth checking out.  Reverting all the mobile-browser changes did not fix the problem however, so it seems it must be one of the m-c changes.

Comment 4

[Matt Brubeck (:mbrubeck)]

Based on bisecting mozilla-central, this appears to be a regression from bug 597331: http://hg.mozilla.org/mozilla-central/rev/178f26e21cfc

Comment 5

[Matt Brubeck (:mbrubeck)]

Possible duplicate of bug 605138.

Comment 6

[Matt Brubeck (:mbrubeck)]

Looks like this was fixed by bug 605138.  Yay!