Accessing the URL bar can take more scrolling than expected

RESOLVED FIXED

Status

()

P1
normal
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: sheppy, Assigned: nalcock)

Tracking

unspecified
Other
iOS

Firefox Tracking Flags

(fxios-v6.0 fixed)

Details

(Whiteboard: [MobileAS])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

3 years ago
I've noticed on both iPhone 6 and iPad Air 2 that getting the URL bar to show up sometimes seems to take a very small scrolling up action but other times it is much longer (like 3-4 times farther). This is sort of confusing and annoying when it happens.

I haven't had much luck isolating any specific scenarios in which it happens, but it's around half the time for me.
Hey Eric,

I tried to emulate the behavior that Safari has where if you're dragging the page downwards (scrolling back up), the URL Bar doesn't animate in. When you 'fling' or have any acceleration, the URL bar will animate. One of the reasons I tried this was to prevent the URL bar from always animating back in when you're slowing dragging the page up or down. I found that with the animation happening on every movement the URL bar seemed really 'jumpy'. Do you have any suggestions as to how we can more easily show the URL bar without having to show it every time the page is scrolled? I also find it a bit cumbersome to get the URL bar back.
(Assignee)

Comment 2

2 years ago
Safari handles this by never fully obscuring the URL bar (it minimised to a maybe 20px or so navigation bar at the top, that can be tapped on to bring the full bar). Perhaps this would be a useful behaviour to implement?
(Reporter)

Comment 3

2 years ago
(In reply to Nathanael Alcock from comment #2)
> Safari handles this by never fully obscuring the URL bar (it minimised to a
> maybe 20px or so navigation bar at the top, that can be tapped on to bring
> the full bar). Perhaps this would be a useful behaviour to implement?

That would be one option. Really, any way to more quickly access the URL bar. Some kind of gesture or special tap would even be okay. But having the URL bar shrink down to a strip across the top, maybe even one that shows the page title in a small font, would be a decent way to go.
Related to this, and should probably be a separate bug: with a hardware keyboard attached, pressing Command-L to focus on the location bar currently does not show the URL bar.
(Reporter)

Comment 6

2 years ago
(In reply to Stefan Arentz [:st3fan] from comment #4)
> Related to this, and should probably be a separate bug: with a hardware
> keyboard attached, pressing Command-L to focus on the location bar currently
> does not show the URL bar.

I was about to ask if Cmd-K opened the search box, but then I remembered that we have a unified URL/search box on iOS. Maybe have Cmd-K focus the URL bar, too, then?

Along similar lines, what keyboard shortcut integrations do we already have? Cmd-F for in-page find? Etc.
(Assignee)

Comment 7

2 years ago
I've just realised that you can actually tap the top of the page, when the search bar is hidden, to show it. But I imagine most users don't even realise this exists — having the region that was already tappable be visible in some way would be much better.


(In reply to Eric Shepherd [:sheppy] from comment #6)
> (In reply to Stefan Arentz [:st3fan] from comment #4)
> > Related to this, and should probably be a separate bug: with a hardware
> > keyboard attached, pressing Command-L to focus on the location bar currently
> > does not show the URL bar.
> 
> I was about to ask if Cmd-K opened the search box, but then I remembered
> that we have a unified URL/search box on iOS. Maybe have Cmd-K focus the URL
> bar, too, then?
> 
> Along similar lines, what keyboard shortcut integrations do we already have?
> Cmd-F for in-page find? Etc.

We already have a number of keyboard shortcuts. You can see all of the ones currently here: https://github.com/mozilla/firefox-ios/blob/9953d6578396a35dcaa3fb48cee119f17169f5e6/Client/Frontend/Browser/BrowserViewController.swift#L1256-L1285
(Though there's an open PR to add even more.)
(Assignee)

Updated

2 years ago
Assignee: nobody → nalcock
(Assignee)

Comment 8

2 years ago
Created attachment 8771490 [details] [review]
Pull request

I've made the touch target that shows the URL bar actually visible now, which I think helps a lot. The UI could perhaps be improved further, but I think it's probably worth having even a basic bar like this over the current solution.
Attachment #8771490 - Flags: ui-review?(randersen)
Attachment #8771490 - Flags: review?(sleroux)
(Assignee)

Comment 9

2 years ago
Created attachment 8771491 [details]
Simulator Screen Shot 15 июля 2016 г., 11.27.50.png

An example for a Wikipedia page. The text simply uses the document's title (with a URL fallback).
(Reporter)

Comment 10

2 years ago
(In reply to Nathanael Alcock from comment #9)
> Created attachment 8771491 [details]
> Simulator Screen Shot 15 июля 2016 г., 11.27.50.png
> 
> An example for a Wikipedia page. The text simply uses the document's title
> (with a URL fallback).

That's a nice start indeed! Perhaps have the top-right corner let you open the tab panel like usual (on iPhone). 

About the only other thought that comes into my head, and it's a little possibly crazy thought, is it might be interesting to have a sort of minimized, dimmed version of the usual controls from the URL bar across that space. Maybe they don't even work (hence the "dimmed") but it would help people understand what that bar is there for.
Comment on attachment 8771490 [details] [review]
Pull request

Mostly minor nits and the subclass thing.

I'm not really a fan of the transition between URL Bar -> minified view though. It seems disjoint from the actual URL Bar and might be confused as a fixed header from the web page since that transition isn't there. I think Safari nailed the transition between the two states since it's clear to the user that the URL bar `becomes` minified but I don't really want to straight up copy from Safari.
Attachment #8771490 - Flags: feedback+
(Assignee)

Comment 12

2 years ago
Ah, yes, I can see what you mean. I'll give it a little more thought — something like the text from the URL bar sliding down, and becoming the minified view might work, though it could also look a bit strange. Maybe it'd most effectively to play around with a couple of different effects to see what works best.
Comment on attachment 8771490 [details] [review]
Pull request

LGTM! I dig it. Though sites with sticky headers seem to get cut off; see this example from Wired: http://c.tecgirl.com/gkRN
Attachment #8771490 - Flags: ui-review?(randersen) → ui-review+
(Assignee)

Comment 14

2 years ago
Created attachment 8784508 [details] [review]
Pull request

Due to the concerns both about floating headers, and the separation of the two URL bars, I've changed the approach slightly — there's now a transition between the two bars.
Attachment #8771490 - Attachment is obsolete: true
Attachment #8771491 - Attachment is obsolete: true
Attachment #8771490 - Flags: review?(sleroux)
Attachment #8784508 - Flags: ui-review?(randersen)
Attachment #8784508 - Flags: review?(sleroux)
(Assignee)

Comment 15

2 years ago
Created attachment 8784511 [details]
Simulator Screen Shot 24 авг. 2016 г., 13.01.00.png
(Assignee)

Updated

2 years ago
Priority: -- → P1
Whiteboard: [MobileAS]
Attachment #8784508 - Flags: feedback+
Comment on attachment 8784508 [details] [review]
Pull request

Looks great! Thanks for all the work on this feature.
Attachment #8784508 - Flags: review?(sleroux) → review+
Comment on attachment 8784508 [details] [review]
Pull request

Looks great!
Attachment #8784508 - Flags: ui-review?(randersen) → ui-review+
master https://github.com/mozilla/firefox-ios/commit/e741a3f19c4ca3a774dea1510d21c7ee5f8db57a
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-fxios-v6.0: --- → fixed
Resolution: --- → FIXED

Updated

2 years ago
Iteration: --- → 1.3
You need to log in before you can comment on or make changes to this bug.