790299 - Add an about:config pref to define new tab behaviour (open new tabs in the foreground OR background)

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, enhancement)

Description

[u450589]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0
Build ID: 20120911030553

Steps to reproduce:

Firefox Mobile should allow to jump to the new window when choose to open a link in a new window.


Actual results:

In the desktop version there are the options browser.tabs.loadInBackground and browser.tab.loadDivertedInBackground 


Expected results:

In the Android version these options do not seem to be active. Another possibility would be to choose to open the new window and jump straight to it when doing a long tap on a link by adding a new option to the contextual menu, or tapping on the notification nessage to activate the window in the foreground.

Comment 1

[Cristian Nicolae (:xti)]

The intended behavior is to move the open new tabs to background and set them inactive. Closing bug as wontfix.

Comment 2

[u450589]

>The intended behavior is to move the open new tabs to background and set them >inactive. Closing bug as wontfix.

I am asking to have the ability to choose to open the new tab in the foreground and set as active (as in Firefox for Win: Options -> Tabs -> "When I open a link in a new tab, switch to it immediately")

Comment 3

[Aaron Train [:aaronmt]]

Marking as enhancment because there was likely a UX decision to make it the way it is; but having those configurable preferences not function is misleading.

Comment 4

[Dave Royal]

I too would like this option. Or a context menu item 'open in new tab and switch to it'. It is rare that I don't immediately want to see a new tab I've opened from a link. Having to scroll up, view all tabs, and tap one is really irritating.

Comment 5

[David McDivitt]

I use Firefox exclusively on my PC and upon getting an android phone use it on that, too. There is one problem. I open links in a new tab because I don't want the underlying page to stay as it is. Firefox does not switch to the new tab immediately. This is a SEVERE NUISANCE. If I open a new tab, why won't it automatically go there? In comments above it's said this was a user interface decision. So, making the application more difficult to use is a good decision?

When I go to a link I must do a long tap to bring up the context menu. Then I choose new tab. Then I have to play with the page in focus, jerking it up and down trying to make the tab choice appear. Sometimes it's hard to make this appear. Then I touch the tab choice, bring up the page showing available tabs, scroll to the one I want and finally touch it.

So this is a good user interface decision? It is very very hard to get to a new tab.

I installed a new tab add on, but it doesn't work. That's the only add on I can find.

Comment 6

[David McDivitt]

also bug https://bugzilla.mozilla.org/show_bug.cgi?id=970064

Comment 7

[Dave Royal]

This addon does it
https://addons.mozilla.org/en-US/android/addon/tabsinforeground/

Comment 8

[David McDivitt]

YES!!! That does work. Thanks! The new tab think is such a nuisance. I will post the link in the other bug report.

Comment 10

[Lucas Rocha (:lucasr)]

Ian, just wondering: what if we used a super toast notification (instead of the ordinary one) with a button that allows you to switch to the tab? We'd keep the current behaviour (which I personally prefer) but still offer a shortcut to switch.

Comment 11

[u450589]

(In reply to Lucas Rocha (:lucasr) from comment #10)
> Ian, just wondering: what if we used a super toast notification (instead of
> the ordinary one) with a button that allows you to switch to the tab? We'd
> keep the current behaviour (which I personally prefer) but still offer a
> shortcut to switch.

Lucas, why not enabling the option as I asked in comment #2? Also comment #3 seems go to the right direction (for me....)

Regards

Comment 12

[Ian Barlow (:ibarlow)]

This is a conversation we've had before: see https://bugzilla.mozilla.org/show_bug.cgi?id=949619#c4. This is the rationale I provided there:

"The current behaviour is modeled after the way in which most of our users use "Open link in new tab", as a sort of short-term "save for later" queue, the added benefit of which being that the new tab can load in the background while the user is on the current page."

---

I would be open to trying Lucas's approach of using a SuperToast to give users the option to switch to that tab right away. 

Or people could just use the add-on. Which, from what I can see here, would probably make David and d.orvini happier anyway as it would fulfill their interaction needs more completely. 

The reality is, we design our products for the way in which the majority of our users interact with them. This is one of those great times where we can do that, and also provide an easy path for others to customize Firefox to work just how they want, with an add-on.

Comment 13

[u450589]

Perhaps I misunderstood the comment #3.

Sorry to have you bothered.

(In reply to Ian Barlow (:ibarlow) from comment #12)
> This is a conversation we've had before: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=949619#c4. This is the
> rationale I provided there:
> 
> "The current behaviour is modeled after the way in which most of our users
> use "Open link in new tab", as a sort of short-term "save for later" queue,
> the added benefit of which being that the new tab can load in the background
> while the user is on the current page."
> 
> ---
> 
> I would be open to trying Lucas's approach of using a SuperToast to give
> users the option to switch to that tab right away. 
> 
> Or people could just use the add-on. Which, from what I can see here, would
> probably make David and d.orvini happier anyway as it would fulfill their
> interaction needs more completely. 
> 
> The reality is, we design our products for the way in which the majority of
> our users interact with them. This is one of those great times where we can
> do that, and also provide an easy path for others to customize Firefox to
> work just how they want, with an add-on.

Comment 14

[Ian Barlow (:ibarlow)]

Oh wait. I think I misunderstood the initial ask in this bug -- as I re-read the earlier comments again, it sounds like you want to turn on the about:config prefs that allow this tab opening behaviour to be changed?

That seems fine to me. 

I thought you wanted to see it in the primary Firefox Settings UI, which is why I pushed back, as I felt that would be too prominent a placement for something we have seen very little demand for, to date.

Comment 15

[u450589]

(In reply to Ian Barlow (:ibarlow) from comment #14)
> Oh wait. I think I misunderstood the initial ask in this bug -- as I re-read
> the earlier comments again, it sounds like you want to turn on the
> about:config prefs that allow this tab opening behaviour to be changed?

Yes, that is exactly what i meant

> 
> That seems fine to me. 
> 

Thank you. As old Firefox user (from Phoenix but even before that) I'd like to have the same behavior between the two versions.

> I thought you wanted to see it in the primary Firefox Settings UI, which is
> why I pushed back, as I felt that would be too prominent a placement for
> something we have seen very little demand for, to date.

Sorry for that, my English is not at the best..

Regards

Danilo

Comment 16

[David McDivitt]

I want to say I've learned to go with the flow regarding software. I understand companies do analysis and make software to match the greatest use. For instance Microsoft and Word or Visual Studio. However, I fail to see how merely loading a new tab in background represents the most common use by users. You can't even get to the new tab, whether in the background or not. If one opens a tab, surely one wants to view it! Of course, if the app does not load the new tab in foreground, common usage would be to open new tabs in background. If the app did open new tabs in foreground, surely people would do that more and such would indicate user preference. Myself, I can't envision any reason to open a tab and leave it in the background and not view it. A very slow connection, maybe, but I never have a slow connection. The thing I hate most is a moral overtone regarding software and how people should use it.

Not only does the app fail to go to the new tab when opened, it is difficult to get to the new tab. As mentioned, it's necessary to flick the page up and down, tap the tab control, view the list of available tabs, then finally go to it. Give me a break. That hardly represents ease of use.

The add on is a great aid. But this should be configurable so people can choose how they want the app to behave.

Comment 17

[Dave Royal]

"Myself, I can't envision any reason to open a tab and leave it in the background and not view it. A very slow connection, maybe...." Me neither. And FWIW it's because I usually do have a slow connection that I usually open a new tab - to avoid the back button and a page reload. Which just shows that every user has their own reasons & priorities.

(The three-finger-swipe addon is good for swapping tabs, BTW.)

Comment 18

[David McDivitt]

Thanks for that. I had similar on iPhone with safari browser that used two fingers. Would be nice if the add on could use two fingers instead. But it does work nice. Firefox is supposed to have two finger swipes but doesn't work.

Comment 19

[:Margaret Leibovic]

In the meantime, you can use an add-on I wrote for this:
https://addons.mozilla.org/en-US/firefox/addon/switch-to-new-tab/

If we're going to only have an about:config pref with no plans to expose this to regular users, I think an add-on might actually be a better solution.

Comment 20

[Dave Royal]

(In reply to :Margaret Leibovic from comment #19)
> In the meantime, you can use an add-on I wrote for this:
> https://addons.mozilla.org/en-US/firefox/addon/switch-to-new-tab/
> 

Is that addon in any way different to the one I posted in comment 7? (Genuine question - it's not clear from the addon page.)

And why do you think an addon would be better? If we do get an unexposed pref for this presumably someone could write an addon that merely exposes it - presumably it would be smaller? But personally I don't see a need to toggle this setting. An easy way (eg a swipe) to switch beteeen the old and new tabs is the important thing for me.

Comment 21

[:Margaret Leibovic]

(In reply to Dave Royal from comment #20)
> (In reply to :Margaret Leibovic from comment #19)
> > In the meantime, you can use an add-on I wrote for this:
> > https://addons.mozilla.org/en-US/firefox/addon/switch-to-new-tab/
> > 
> 
> Is that addon in any way different to the one I posted in comment 7?
> (Genuine question - it's not clear from the addon page.)

Sorry I didn't read all of the comments. The add-on you posted in comment 7 looks like a better version of my add-on :) I just made mine as a proof of concept for bug 970064.

> And why do you think an addon would be better? If we do get an unexposed
> pref for this presumably someone could write an addon that merely exposes it
> - presumably it would be smaller? But personally I don't see a need to
> toggle this setting. An easy way (eg a swipe) to switch beteeen the old and
> new tabs is the important thing for me.

Adding a hidden about:config pref isn't free - it creates another code path that we need to maintain, and a difficult one at that, since very few users will be testing that code path.

Is there some reason that the add-on doesn't satisfy your use case?

Comment 22

[David McDivitt]

I like the add on. It suits my needs as well as the three finger swipe. but it was very hard to find the addon. I looked and looked for something, found one that didn't work, then saw the post about another here. It is not true people would not make use of the functionality if present. If the functionality has not been present to actually compare with, isn't that merely an assumption? I make software for a living and I would never provide something with missing pieces, or visualize functionality to help round things out then not include that. Why by chance do you think the functionality exists in the desktop version without need of an addon?

Comment 23

[Dave Royal]

(In reply to :Margaret Leibovic from comment #21)
> Is there some reason that the add-on doesn't satisfy your use case?
No - the addon meets my requirement perfectly.

But it's interesting that the initial reaction to this bug was WONTFIX; it's clearly not something that (some) devs see as useful, yet we have 1500 users who've gone to the trouble of finding that addon. I understand that devs don't want a myriad of options, but the customisation of Firefox is its strength. Some of us know this option exists in the desktop version and want it to work here too. So in /this/ case - preserving compatibility with the desktop version - I think it should be included as a hidden pref.

And addons tend to rot - the maintainers lose interest or die - so where it's an important function for many users it should be in the product if possible. 

I'm not getting at you devs BTW. You're doing a great job. I've used Mozilla since Netscape 3 and Fennec since the Nokia 810.

Comment 24

[:Margaret Leibovic]

(In reply to Dave Royal from comment #23)
> (In reply to :Margaret Leibovic from comment #21)
> > Is there some reason that the add-on doesn't satisfy your use case?
> No - the addon meets my requirement perfectly.

Well that's good to hear :)

> But it's interesting that the initial reaction to this bug was WONTFIX; it's
> clearly not something that (some) devs see as useful, yet we have 1500 users
> who've gone to the trouble of finding that addon. I understand that devs
> don't want a myriad of options, but the customisation of Firefox is its
> strength. Some of us know this option exists in the desktop version and want
> it to work here too. So in /this/ case - preserving compatibility with the
> desktop version - I think it should be included as a hidden pref.

1500 users are a very small portion of our user base. We don't have any hard and fast rules, but I think that if fewer than 1% of our users need a feature, it's good material for an add-on. A big part of what makes Firefox so customizable is its add-on ecosystem.

> And addons tend to rot - the maintainers lose interest or die - so where
> it's an important function for many users it should be in the product if
> possible. 

I feel like this is a separate problem, and putting add-on functionality into the browser doesn't solve the root problem here. If an add-on is important to users I would hope its author would try to maintain it! Or at the very least make it open to contributions.

> I'm not getting at you devs BTW. You're doing a great job. I've used Mozilla
> since Netscape 3 and Fennec since the Nokia 810.

Thanks :) And we appreciate you taking time to comment on bugs. I know it sucks when we push back on feature requests, but at the end of the day, we need to think about the bigger picture, and can't include every feature in the browser.

I think the final decision here belongs to our UX team.

Comment 25

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.