1324283 - Custom search could avoid the "Tab queue" preference

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Kaartic Sivaraam]

Currently when the user who has enabled "Tab queue" feature searches using "Firefox custom search" and taps a link on the search results the link he tabs is sent to the queue. 

It would be better if the browser was opened instead of sending it to the queue because a user would generally want to view a result immediately. Probably, a user will consider "Firefox custom search" as a part of Firefox and could be surprised by this behaviour.

Steps to reproduce:
0. Enable "Tab queue" feature
1. Search for something using "Firefox custom search"
2. Tap a link in the result

Expected behaviour:
Firefox browser comes to the foreground and loads the link

Actual behaviour:
Link is sent to "Tab queue" and the user needs to open Firefox to view page

Comment 1

[Sebastian Kaspari (:sebastian; :pocmo)]

@antlam: What's your opinion on that? Should be trivial to change.

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

To confirm, does using "Firefox custom search" == our Firefox search widget? 

I don't think we can confidently generalize that users who have tab queue enabled will make the exact same assumption as above. Even if we can, I forsee that it could create some edge cases down the road which could get messy.

Either way, the user problem that I see here right now is more about wanting a better way to control when a tab is "saved" versus opened normally. 

I think UX will need to think about this more as a part of our "V2" improvements before deciding :)

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Anthony Lam (:antlam) from comment #2)
> To confirm, does using "Firefox custom search" == our Firefox search widget? 

Yeah, kind of - the search screen that shows up when clicking the search icon in the widget.


(In reply to Anthony Lam (:antlam) from comment #2)
> I don't think we can confidently generalize that users who have tab queue
> enabled will make the exact same assumption as above. Even if we can, I
> forsee that it could create some edge cases down the road which could get
> messy.
> 
> Either way, the user problem that I see here right now is more about wanting
> a better way to control when a tab is "saved" versus opened normally. 
> 
> I think UX will need to think about this more as a part of our "V2"
> improvements before deciding :)

Okay, this sounds like a WONTFIX for this bug.

@Kaartic: When using tab queue you can usually double tap links in an app and then it will open immediately. This could be a workaround for you here.

Comment 4

[Kaartic Sivaraam]

(In reply to Sebastian Kaspari (:sebastian) from comment #3)
> 
> @Kaartic: When using tab queue you can usually double tap links in an app
> and then it will open immediately. This could be a workaround for you here.

Thanks for the info. I didn't know that before. Why isn't this info not specified anywhere in the app ?

Comment 5

[Sebastian Kaspari (:sebastian; :pocmo)]

Good question. Where would you expect this to be featured? It's indeed hard to discover, so the question for us is whether we want to advertise it more or find a better solution to provide this functionality (deciding between opening now or later).

Comment 6

[Kaartic Sivaraam]

(In reply to Sebastian Kaspari (:sebastian) from comment #5)
> Good question. Where would you expect this to be featured? 

I think it would be better to display it in some way when the user turns on "Tab queue" feature for the first time or each time the tab queue feature is turned on. Not sure how.

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

Thanks! I filed bug 1328862 to investigate explaining the feature better.

Comment 8

[Kaartic Sivaraam]

(In reply to Sebastian Kaspari (:sebastian) from comment #7)
> Thanks! I filed bug 1328862 to investigate explaining the feature better.

You're welcome!