Closed
Bug 1476415
Opened 6 years ago
Closed 6 years ago
browser.search.search: open new tab next to active tab
Categories
(WebExtensions :: General, defect, P3)
WebExtensions
General
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: kernp25, Assigned: mkaply)
References
Details
This code:
> browser.search.search("Google", "test")
will open a new tab at the end. But i think it should open
the new tab next to the active tab (like with built-in search context menu [1]).
[1] https://searchfox.org/mozilla-central/rev/6f86cc3479f80ace97f62634e2c82a483d1ede40/browser/base/content/browser.js#4024
Comment 1•6 years ago
|
||
(In reply to kernp25 from comment #0)
> This code:
> > browser.search.search("Google", "test")
> will open a new tab at the end. But i think it should open
> the new tab next to the active tab (like with built-in search context menu
> [1]).
>
> [1]
> https://searchfox.org/mozilla-central/rev/
> 6f86cc3479f80ace97f62634e2c82a483d1ede40/browser/base/content/browser.js#4024
Ideally, the new tab would follow the preference set in browser.search.openintab.
Assignee | ||
Comment 2•6 years ago
|
||
> Ideally, the new tab would follow the preference set in browser.search.openintab.
All these things are supposed to be found before I check in :).
I'll take a look
Flags: needinfo?(mozilla)
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → mozilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 3•6 years ago
|
||
I'm not convinced of this one.
The search can be executed in many different places in the UI (popup, sidebar, context menu).
It's up to the extension that implements the search to make sure the tab shows up in the correct place. They can do that by getting the active tab and putting it next to that tab if it's a context menu search.
As far as browser.search.openintab goes, I'm still thinking about that one. That preference was really designed for the search bar, and that's the only place it is used I think.
And that preference is exposed via WebExtension APIs so an extension could query it and do the right thing.
Comment 4•6 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #3)
> I'm not convinced of this one.
>
> The search can be executed in many different places in the UI (popup,
> sidebar, context menu).
>
> It's up to the extension that implements the search to make sure the tab
> shows up in the correct place. They can do that by getting the active tab
> and putting it next to that tab if it's a context menu search.
>
> As far as browser.search.openintab goes, I'm still thinking about that one.
> That preference was really designed for the search bar, and that's the only
> place it is used I think.
>
> And that preference is exposed via WebExtension APIs so an extension could
> query it and do the right thing.
Good points, Mike. Given the number of different user actions that can invoke this API, only the extension knows where the appropriate location would be. And it can use the browserSetting() API to query several prefs to decide what to do.
Assignee | ||
Comment 5•6 years ago
|
||
I'm going to mark this WONTFIX. It's up to the extension developer to use the API correctly.
I've provided the ability to pass the tabID.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Comment 6•6 years ago
|
||
Depends on bug 1477248 for extension developer to be able to do so manually.
(In reply to Ian Moody [:Kwan] (UTC+0) from comment #6)
> Depends on bug 1477248 for extension developer to be able to do so manually.
But this is WONTFIXED?
Assignee | ||
Comment 8•6 years ago
|
||
I'm going to add support for openerTabId
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Updated•6 years ago
|
Priority: -- → P3
Comment 9•6 years ago
|
||
Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958
Component: Untriaged → General
Reporter | ||
Comment 10•6 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #8)
> I'm going to add support for openerTabId
It should just open the new tab created by browser.search.search api next to the active (selected) tab.
I think, that would be enough for most users.
To fix this bug, just add the relatedToCurrent flag to the options [1].
[1] https://searchfox.org/mozilla-central/rev/a0333927deabfe980094a14d0549b589f34cbe49/browser/components/extensions/parent/ext-search.js#71-74
Flags: needinfo?(mozilla)
Assignee | ||
Comment 11•6 years ago
|
||
In the context menu use case, I agree, but in other use cases, I'm not sure this applies.
If you click a button in UI that opens a search, should it be related to the current tab?
Flags: needinfo?(mozilla)
Reporter | ||
Comment 12•6 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #11)
> In the context menu use case, I agree, but in other use cases, I'm not sure
> this applies.
>
> If you click a button in UI that opens a search, should it be related to the
> current tab?
Why not? Because otherwise you need to navigate between a lot of tabs (if you have a lot of tabs open).
But now, that the bug[1] has been fixed, i think, this bug is no longer needed.
browser.contextMenus.onClicked.addListener(async (info, tab) => {
let newTab = await browser.tabs.create({
url: "about:blank",
index: tab.index + 1
});
browser.search.search({
query: "test",
tabId: newTab.id
});
});
Works perfectly :)
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1477248
Assignee | ||
Comment 13•6 years ago
|
||
I'm glad we could make you happy :)
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•