If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Add interactions and animations to navigation controls

VERIFIED FIXED in fennec1.0m7

Status

Fennec Graveyard
General
P2
normal
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: mfinkle, Assigned: mfinkle)

Tracking

Trunk
fennec1.0m7
x86
Windows 2000
Bug Flags:
wanted-fennec1.0 +

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

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.

Updated

9 years ago
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?
Created attachment 332559 [details] [diff] [review]
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)
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+

Updated

9 years ago
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.
Created attachment 332887 [details] [diff] [review]
v2 - basically same as first patch but adds resize support and fixes some scroll UX problems
Attachment #332559 - Attachment is obsolete: true
Attachment #332887 - Flags: review?(gavin.sharp)
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
Last Resolved: 9 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.