Closed Bug 354526 Opened 18 years ago Closed 11 years ago

Web search doesn't respect tab settings (when search bar is not visible)

Categories

(Firefox :: Search, defect)

2.0 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ville.pohjanheimo, Unassigned)

Details

Clicking Tools -> Web search when the search bar is not in the toolbar(s) opens the selected search in the current window and tab.

E.g. selecting "New pages should be opened in: a new window" in the tab panel of preferences doesn't have any effect on this behaviour.

What should happen: When the search bar is hidden, clicking Tools -> Web search should open the search page either in a new tab or a new window depending on the selected setting in the tab panel of preferences.

Tested on: Mozilla/5.0 (X11; U; Linux i686; fi; rv:1.8.1) Gecko/2006092604 BonEcho/2.0
Is this related to bug 351253 ?

Somebody who's qualified can do that evalution.
Whiteboard: [mentor=Gijs][lang=js]
Tools -> Web search no longer seems to be an option presented to the user. Does that invalidate this bug?
Cmd/Ctrl+K still works.
I think I get it, but just so I understand the requirements:

IF prefs require links to open in new windows (browser.link.open_newwindow => 2)
AND the Navigation Toolbar is hidden
AND the user presses Cmd/Ctrl+K
THEN the default search page should appear in a new window.

Is that an accurate description of the desired behavior?
Hi,

I am interested in working on this bug. So please can you assign this bug to me. 


Thanks in advance,

Regards.
(In reply to michael.harte from comment #2)
> Tools -> Web search no longer seems to be an option presented to the user.
> Does that invalidate this bug?

Well, we could try and always open in new windows/new tabs based on the preference, as you suggested in comment #4, but after some discussion we decided that's unlikely to help anyone. There isn't a preference right now that captures what should happen here (current tab, new tab, new window), there's no more menu item where extra keypresses during a click control the behaviour, and so there isn't really a good way to fix this without either breaking existing behaviour or leaving this wanting in terms of configurability - short of introducing an entirely new pref, which seems overkill. So, this is probably WONTFIX.

(In reply to Anup from comment #5)
> Hi,
> 
> I am interested in working on this bug. So please can you assign this bug to
> me. 
> 
> 
> Thanks in advance,
> 
> Regards.

Hi Anup. I'm afraid that now that you pinged me about this bug, I had a discussion about it with some other folks, and we decided that this isn't really worth fixing anymore. Maybe you can find a new bug you'd like to work on in bugsahoy? ( http://www.joshmatthews.net/bugsahoy/ )
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Whiteboard: [mentor=Gijs][lang=js]
You need to log in before you can comment on or make changes to this bug.