Closed Bug 444248 Opened 12 years ago Closed 12 years ago

Add interactions and animations to navigation controls

Categories

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

x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED
fennec1.0m7

People

(Reporter: mfinkle, Assigned: mfinkle)

References

()

Details

Attachments

(1 file, 1 obsolete file)

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.
Flags: wanted-fennec1.0+
Priority: -- → P2
Target Milestone: --- → Fennec A1
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?
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)
Assignee: nobody → mark.finkle
Status: NEW → ASSIGNED
Attachment #332559 - Flags: review?(gavin.sharp)
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.
Attachment #332559 - Flags: review?(gavin.sharp) → review+
Target Milestone: Fennec A1 → Fennec M7
(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.
Attachment #332887 - Flags: review?(gavin.sharp) → review+
changeset:   102:8b697d86d50d
tag:         tip
user:        Mark Finkle <mfinkle@mozilla.com>
date:        Tue Aug 19 15:19:47 2008 -0400
summary:     b=444248, r=gavin. Add interactions and animations to nav controls
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
verified functionality from comment #2 in beta3
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.