I'm quite surprised to see anybody suggesting this pattern be used, because it's exactly why I had to stop using Firefox for Android. It makes no sense to need to scroll up and lose your place in a page to access the menu. Whichever designer suggested those two actions be bound together doesn't have any business designing.
Scrolling has long been established as a transient action. It makes total sense to submerge the menu until such time as it's needed. This pattern is prevalent in plenty of mobile apps. Google Chrome on iOS is a shining example. Safari, as well.
You can make a reasonable assumption that users scrolling down are reading content, and thusly have no need for the menu bar. What I'm seeing from your perspective is that you're failing to recognize that "losing your place" in order to reveal the menu is a complete change of task. By bringing back the menu, or even using it if it were in place statically, your task and intent has shifted. If you've decided to abort your menu task and revert to reading content, it provides less cognitive friction to let the user scroll themselves back to their original place.
My question to you is - what logical sense does it make to stop reading an article midway through and begin interacting with the menu, unless your intent is to navigate away from the content itself? And if it makes sense to you to do this, why do you find yourself changing and aborting tasks so swiftly? Are there other interactions that you've failed to discover that might be beneficial (tap and hold to get a menu, for example)?
Again, I'll reiterate - scrolling is frictionless.
Secondly, even if I am changing tasks, that doesn't mean ruining the state I leave in it is an acceptable side effect. Your browser history isn't corrupted when you leave Firefox.
That's a stretch. Ruining? You can still scroll down. The affordances of these actions means, at most, you're going to have to touch the screen once more to "get back to where you were." If you're using an application that doesn't provide the menu after a short swipe, that's a fair enough issue to raise with the implementation of the pattern, not with the pattern itself. It doesn't surprise me that you encountered it on FF Mobile, because FF has a longstanding tradition of ripping things off from successful UIs and getting them wholly wrong in their implementations.
I can hardly believe the question needs to be asked, but it would be more appropriate to say "what logical sense does it make to bind scrolling to menu actions?" (The answer is none, which is why we didn't have this feature until now, and won't have it for long.)
That's your opinion. Unfortunately for you in this case, it's wrong. Try it on iOS Chrome / Android Chrome or Safari and see how it's done properly before making a sweeping judgment on the interaction pattern itself.
Comments
I'm quite surprised to see anybody suggesting this pattern be used, because it's exactly why I had to stop using Firefox for Android. It makes no sense to need to scroll up and lose your place in a page to access the menu. Whichever designer suggested those two actions be bound together doesn't have any business designing.
Scrolling has long been established as a transient action. It makes total sense to submerge the menu until such time as it's needed. This pattern is prevalent in plenty of mobile apps. Google Chrome on iOS is a shining example. Safari, as well.
You can make a reasonable assumption that users scrolling down are reading content, and thusly have no need for the menu bar. What I'm seeing from your perspective is that you're failing to recognize that "losing your place" in order to reveal the menu is a complete change of task. By bringing back the menu, or even using it if it were in place statically, your task and intent has shifted. If you've decided to abort your menu task and revert to reading content, it provides less cognitive friction to let the user scroll themselves back to their original place.
My question to you is - what logical sense does it make to stop reading an article midway through and begin interacting with the menu, unless your intent is to navigate away from the content itself? And if it makes sense to you to do this, why do you find yourself changing and aborting tasks so swiftly? Are there other interactions that you've failed to discover that might be beneficial (tap and hold to get a menu, for example)?
TL;DR - you're bitching about an edge case.
[deleted]
Again, I'll reiterate - scrolling is frictionless.
That's a stretch. Ruining? You can still scroll down. The affordances of these actions means, at most, you're going to have to touch the screen once more to "get back to where you were." If you're using an application that doesn't provide the menu after a short swipe, that's a fair enough issue to raise with the implementation of the pattern, not with the pattern itself. It doesn't surprise me that you encountered it on FF Mobile, because FF has a longstanding tradition of ripping things off from successful UIs and getting them wholly wrong in their implementations.
That's your opinion. Unfortunately for you in this case, it's wrong. Try it on iOS Chrome / Android Chrome or Safari and see how it's done properly before making a sweeping judgment on the interaction pattern itself.