Closed Bug 781677 Opened 12 years ago Closed 12 years ago

Align interaction for floating address/tab bar

Categories

(Firefox for Metro Graveyard :: General, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jwilde, Unassigned)

References

Details

Yuan and I discussed the current issues with both the floating and inline implementations of tab/URL bars. Metro Firefox is moving to a hybrid of the two concepts: - The URL bar will be injected at the top of the content. To get rid of it, you can scroll the content upward. When you scroll the screen, the URL bar will smoothly scroll upwards as though it's a part of the content. - If the URL bar at the top of the content is visible and the tab bar is supposed to come in, it will push the content down. - If you drag up the content, hiding the tab bar and the URL bar, when you drag back down, only the URL bar will be shown, at a maximum. - If you're in the middle of a page the URL bar and tab bar will float over the content like they do currently with jimm's patch. - Tapping on the content area will only dismiss the URL bar and tab bar if and only if they are floating over the content. This plan, while somewhat more complicated to implement, brings advantages from various implementation strategies: - When you load a page, you'll immediately see whatever header the page has and whatever logo is there. - The content won't shift if you tap on it. - The content won't constantly shift around when you bring in the ContextUI.
Most of this sounds great. I'm curious about one design point though - > - The URL bar will be injected at the top of the content. To get rid of it, > you can scroll the content upward. When you scroll the screen, the URL bar > will smoothly scroll upwards as though it's a part of the content. > - If the URL bar at the top of the content is visible and the tab bar is > supposed to come in, it will push the content down. I'd like to see this in action before passing judgement but my initial impression is that this will be confusing to the user. I don't think browser ui should ever shift content. We had things set up like this initially and the experience was somewhat jarring. Shifting mouse targets around forces the user to chase after content or miss target mouse clicks. For example - say you hover the mouse near a link at the top of a page and you're trying to decide whether to open the link in a new tab or in the existing tab. A right-click at the current mouse position will bring up the tab bar which shifts the link away from the mouse.
One other issue I think we are overlooking here. When users interact with the browser using a precise pointing device (mouse) we want interactive scroll bars on page content. If the url/tab bar fold up when you drag content up via touch, how will the url and tab bar react when the user grabs the conventional scrollbar and attempts to scroll downward? We need to understand how these two different interactions are going to work before we overhauling the interface code.
(In reply to Jim Mathies [:jimm] from comment #2) > We need to understand how these two different interactions are going to work > before we overhauling the interface code. Agreed.
Yuan and I talked about the mouse case and how scrollbars should work. Instead of going for a completely different system as described above, we're going to realign some of the behaviors of the existing floating UI to make it feel snappier and more deterministic. When you start loading a new page: - Tab tray contracts, leaving only the URL bar. - The URL bar stays there while the page is loading; it does not disappear on a time delay. - When the page is loaded and there's the end-of-loading animation described in bug bug 772304, the URL bar snaps up, revealing the content. If you try to scroll the page (or otherwise interact with the content) while the page is loading, the URL bar and appbar contract, leaving only the content. When you start typing in the URL bar, the tab bar should contract to make room for the autocomplete overlay. When there are no matches in the autocomplete overlay, the "Internet Searches" section stays there, but the rest of the history results are hidden. It should not go back to the new tab screen. The new tab screen is only shown when you open a new tab. When it gets shown while opening a new tab, it compresses the tab bar after the tab opening animation has been completed and focuses the URL bar. However, if you open multiple new tabs somehow, and then open the tab strip and try to switch between them, it should switch like a normal web page: - If you single tap: switch, but not compress the tab bar - If you double tap: switch and compress the tab bar. Ideally, we'd also maintain the scrolling and autocomplete state of the new tab screen and autocomplete across multiple new tabs, but that's rapidly getting into the area of edge-cases that aren't super bad if you hit.
Summary: Support hybrid scrolling/floating address/tab bar → Align interaction for floating address/tab bar
Important point brought up by Frank in regards to the double tap gesture: since the gesture code has to wait while trying to detect double taps, there's the potential that this is going to make tab switching feel less responsive.
Product: Firefox → Firefox for Metro
Version: unspecified → Trunk
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.