Closed Bug 569094 Opened 12 years ago Closed 11 years ago

Url bar doesn't become hidden anymore after these particular steps

Categories

(Firefox for Android Graveyard :: General, defect)

Fennec 1.1
x86
Windows 7
defect
Not set
normal

Tracking

(fennec2.0+)

RESOLVED WORKSFORME
Tracking Status
fennec 2.0+ ---

People

(Reporter: martijn.martijn, Assigned: mfinkle)

Details

Attachments

(2 obsolete files)

I can reproduce this, using:
Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2.5pre)
Gecko/20100527 Namoroka/3.6.5pre Fennec/1.1b2pre

To reproduce:
- Open url that is quite slow loading, like http://planet.mozilla.org
- Open a new tab
- Go back to the previous tab
- Pan to the left to make the tab bar go away
- Pan upwards to scroll down

Expected result:
While scrolling down, the url bar should disappear (go upwards with the page scroll)

Actual result:
The url bar stays visible

There doesn't seem to be a blocking fennec1.1? flag somewhere?
(In reply to comment #0)
> There doesn't seem to be a blocking fennec1.1? flag somewhere?

Ah, never mind. Found it.
tracking-fennec: --- → ?
I can reproduce this in both trunk and 1.1 builds on Linux desktop.  To reproduce the bug, I have to go back to the original tab *before* it finishes loading.
Attached patch Patch (obsolete) — Splinter Review
This happen because the BrowserUI._shouldUnlockToolbar flag is reset when the new tab has finished loading (sigh).
Assignee: nobody → 21
Attachment #448576 - Flags: review?(mark.finkle)
Comment on attachment 448576 [details] [diff] [review]
Patch

Wouldn't this fail if I:
* open a slow loading page
* then switch to an already open page
* wait for the now background page to load
* _shouldUnlockToolbar is now stuck to "true" since when the slow loading page finished, it wasn't the selected tab

Or am I missing something?
It seems like we need to handle this in TabSelect too.

and the more places we need to handle _shouldUnlockToolbar, the more I don't like it!
regression from bug 564285
Comment on attachment 448576 [details] [diff] [review]
Patch

tab switching would break this approach
Attachment #448576 - Flags: review?(mark.finkle) → review-
Attached patch alt patch (obsolete) — Splinter Review
This patch uses a different approach:
* When floating the toolbar, also float the notifications, so the notifs appear locked to the bottom of the urlbar
* Backs out the patch used for bug 564285

I think this approach is safer and saner. It has a nice side effect that the notifications are very easy to see whenever the toolbar is floated, even if the page is panned very far down. Just slide in a sidebar to view the urlbar _and_ the notifications.

Should be fairly safe, but needs to be tested as much as possible. I think we need to get this into RC1 so we get good test coverage.
Assignee: 21 → mark.finkle
Attachment #448576 - Attachment is obsolete: true
Attachment #448686 - Flags: review?(21)
Comment on attachment 448686 [details] [diff] [review]
alt patch


> #toolbar-moveable-container[top="0"] {
>   position: fixed;
>   left: 0;
>   z-index: 1000;
> }
> 
>+#notifications[top]:not([top=""]) {
>+  position: fixed;
>+  left: 0;
>+  z-index: 1000;
>+}
>+

#toolbar-moveable-container[top="0"], 
#notifications[top]:not([top=""]) {
...
}


I like this approach (the only sad effect being the notification bar hiding the sidebars)
Comment on attachment 448686 [details] [diff] [review]
alt patch

we won't fix this for 1.1
Attachment #448686 - Attachment is obsolete: true
Attachment #448686 - Flags: review?(21)
tracking-fennec: ? → 2.0+
Testing this in Fennec 2.0b1pre. Seems to work as designed:
* The URLBar will not disappear while a page is still loading
* Switching tabs should update the URLBar to the correct "loading" or "viewing" state.

Loading planet.mozilla.org and then opening a new tab with google.com and then toggling between them seems to work correctly.

Marking worksforme
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Works for Me :
Mozilla/5.0 (Maemo;Linux armv71; rv:2.0b7pre)Gecko/20100922 Firefox/4.0b7pre Fennec/2.0b1pre

Mozilla/5.0 (Android; Linux armv71; rv2.0b7pre) Gecko/20100922 Firefox/4.0b7pre Fennec/2.0b1pre
You need to log in before you can comment on or make changes to this bug.