444248 - Add interactions and animations to navigation controls

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P2)

Description

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

The URL Toolbar and the Side controls each have special interactions and animations as described here:
http://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI

These are not functional yet.

Comment 1

[Madhava Enros [:madhava]]

It would be great to have the titlebar scroll off the top of the page and the control strip be "pannable" for m6 -- would that be possible?

Comment 2

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

Attachment: v1 - add nav toolbar scrolling/floating behaviors

This patch adds the interactions needed for the nav url toolbar:
* toolbar will scroll off the top of screen as content is panned up
* toolbar will scroll into screen as content is panned down
* if toolbar is hidden, the toolbar will float over content when activated (when sidebar or tabs lists are shown) and will hide itself after deactivation.
* if toolbar is partially hidden, the toolbar will "scroll" into view when activated and remain after deactivation (like iPhone)

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 332559 [details] [diff] [review]
v1 - add nav toolbar scrolling/floating behaviors

>diff --git a/chrome/content/browser-ui.js b/chrome/content/browser-ui.js

>+  _scrollToolbar : function(aEvent) {
>+    if (Browser.content.dragData.dragging && Browser.content.scrollY == 0) {

I hates Browser.content - is there a bug on using a better name for that already? I know we discussed it. Also, perhaps we should add readonly properties for the dragData members if they're going to be needed outside of deckbrowser.

>+  _showToolbar : function() {

>+    else if (toolbar.top < 0) {
>+      // Partially showing, so force it to scroll
>+      toolbar.top = 0;
>+      browser.top = toolbar.boxObject.height;

"so show it completely"?

>+  _hideToolbar : function() {

>+    // If we are floating the toolbar, then hide it again

Should this method also handle a partially showing toolbar?

>diff --git a/chrome/content/browser.xul b/chrome/content/browser.xul

>   <stack id="browser-container" flex="1" style="overflow: hidden;">
>-    <vbox id="browser">
>+    <vbox id="browser" style="-moz-stack-sizing: ignore; width: 800px; height: 480px" top="60">

nit: missing trailing ";". I don't really like this hardcoding of width/height but I suppose we can revisit later.

Comment 4

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

(In reply to comment #3)
> >+  _scrollToolbar : function(aEvent) {
> >+    if (Browser.content.dragData.dragging && Browser.content.scrollY == 0) {
> 
> I hates Browser.content - is there a bug on using a better name for that
> already? I know we discussed it. Also, perhaps we should add readonly
> properties for the dragData members if they're going to be needed outside of
> deckbrowser.

bug 449517 for Browser. The next patch is worse, it sets values in deckbrowser.dragData

> 
> >+  _showToolbar : function() {
> 
> >+    else if (toolbar.top < 0) {
> >+      // Partially showing, so force it to scroll
> 
> "so show it completely"?

done

> 
> >+  _hideToolbar : function() {
> 
> >+    // If we are floating the toolbar, then hide it again
> 
> Should this method also handle a partially showing toolbar?

I skipped that for now. Mobile Safari doesn't have a use case for it. If we need it, it can be added later.

> >+    <vbox id="browser" style="-moz-stack-sizing: ignore; width: 800px; height: 480px" top="60">
> 
> nit: missing trailing ";". I don't really like this hardcoding of width/height
> but I suppose we can revisit later.

Fixed ";" and I agree about the hardcoded values. The next patch adds onresize support so the "browser" vbox is always sized correctly.

The next patch also moves the core dragging code into BrowserUI instead of trying to piggy back on the code in deckbrowser.

Comment 5

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

Attachment: v2 - basically same as first patch but adds resize support and fixes some scroll UX problems

Comment 6

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

changeset:   102:8b697d86d50d
tag:         tip
user:        Mark Finkle <[e-mail]>
date:        Tue Aug 19 15:19:47 2008 -0400
summary:     b=444248, r=gavin. Add interactions and animations to nav controls

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

verified functionality from comment #2 in beta3