1289101 - Menu button is too close to the tabs button

Status: RESOLVED DUPLICATE of bug 1236156

(Firefox for Android Graveyard :: General, enhancement)

Description

[Luc]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

Since a few months, the menu button is always visible even on devices with a dedicated menu button in hardware. I've seen the other bug about it which mentions why: some devices falsely report to have this button, but that could be easily resolved in various ways, all of which have their pros and cons of course (ask the user, a setting, an about:config setting, white/blacklist devices, and probably more). My personal favorite is an about:config setting since that doesn't have to be supported but still resolves the issue completely for everyone who cares enough to look for it at all.

Anyway, ever since the useless button has been added (and eaten up much of the address bar), I've been hitting it instead of the tabs button a lot. At first from reflex, since the tabs button was very nicely at the edge of the screen I hardly had to look to hit it. Now I've removed that from my muscle memory, but I still hit the menu button a lot since the tabs button is quite a small square. And I don't know about others, but I use tabs a lot more than the menu.


Actual results:

When hitting it incorrectly, another issue arises, especially when I use my phone one-handed: I need to move all the way to the other side of the device to close it (be it via empty space on the left, the menu button, or the back button). This often doesn't work with the way I'm holding the device when using it one-handed and requires me to reposition the whole device in my hand, only to move it back immediately after closing the menu. (Or to get out my other hand, but if I'm using it one-handed there's usually a reason for it, like holding onto the bus I'm standing in.)

At first my reflex was to hit the tabs button immediately after misclicking, since the menu takes a second to pop up I'd hit the tabs button before the menu is there yet, but that only results in bookmarking the current page, adding to the mess I need to clean up from a button that shouldn't even have been there in the first place.


Expected results:

The menu button should be able to be removed. It has been mentioned elsewhere that "maintaining multiple branches like this in code is expensive", but if support documentation doesn't need updating (i.e. if it was an unsupported about:config setting), you can't fool me into thinking that hiding a button according to a hidden (opt-in) setting is more than a few lines of code.

Alternatively, the menu button could be moved, like swapped with the tabs button (or moved to the other side of the address bar). When swapped with tabs, the mis-hitting issue disappears altogether for the tabs button since you can err a lot off the screen to the right. (It'll be as easy to open as the notifications area, which can be slided open from the top of the device instead of needing to hit that area exactly.) This will make the menu button slightly harder to hit, but it's an improvement for everyone who: 1) has a hardware button; or 2) opens the menu less frequently than they open tabs (I think this is nearly everyone).

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

This is still a request for the menu button to be hidden.

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Hi Luc.

It looks like you did a lot of research before writing this post – thanks for being thorough! :)

(In reply to Luc from comment #0)
> It has been mentioned
> elsewhere that "maintaining multiple branches like this in code is
> expensive", but if support documentation doesn't need updating (i.e. if it
> was an unsupported about:config setting), you can't fool me into thinking
> that hiding a button according to a hidden (opt-in) setting is more than a
> few lines of code.

While the code that directly hides the menu button may just a few lines of code (it's literally "hide this view"), there are many other lines of code that go into supporting these lines, for example, the toolbar layout code. It's time-intensive to change the toolbar layout code because we have many considerations, for example:
 * Is it correct in display mode? Editing mode?
 * Does it look correctly while animating?
 * Does it look correct in landscape?
 * Does it correctly support lightweight themes?
 * Is it performant enough?
 * Does it look correct on tablet?

Each time the code is changed, these questions need to be answered and it takes a fair amount of time to open the app and test this by hand. Some need to be checked more than once (e.g. is lightweight themes on phones correct? Is it correct on tablets? What about landscape phones & tablets?). We can write automated tests, but tests often need to be updated when layouts are updated.

Additionally, if there's a regression, it needs to be investigated, fixed, and these questions have to be answered all over again.

So adding & maintaining a hideable menu button is actually a non-trivial amount of work and we've decided that it's more important to develop new features than it is to maintain this configuration (which, fwiw, is deprecated by Google and they no longer support hardware menu buttons, despite a few manufacturers continuing to do so, e.g. Samsung).

> Alternatively, the menu button could be moved, like swapped with the tabs
> button (or moved to the other side of the address bar).

Unfortunately, in most cases, any amount configurability faces the costs we see above.

I hope that helps explain our position – thanks for your feedback!

Comment 3

[Luc]

Thanks for the comment Michael! As a (student) developer myself I understand there's always more than meets the eye; however, things like performance and animation correctness could be ignored with unsupported about:config hacks, which is what I mainly proposed. There's enough people using Firefox that use it because it's open source, and they often know how to get to those settings (or know someone who knows) if they care enough to look for it.

What I don't agree with though is that this is marked duplicate. Much of what I said overlaps with the other bug (which this has been marked duplicate of), but the title and one of the mentioned issues is a separate thing: the two buttons are annoyingly close, and the one you use the most is the harder one to hit.

Should I open another bug with *only* that issue and the one proposed solution (i.e. flipping the two buttons around) or should this be reopened?