Closed Bug 37875 Opened 25 years ago Closed 15 years ago

Readd Search dialog

Categories

(SeaMonkey :: Search, enhancement)

Product:
SeaMonkey
Component:
Search
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: BenB, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: helpwanted, regression)

There was once a dialog, similar to the search panel (giving the ability to enter a word and listing the results), which opened after "Search|Search the web". Now, Netscape Search (the primary search engine?) loads in the browser window. Please restore the old functionality.
Adding to Netscape chrome meta bug.
Blocks: 14532
the Advanced Search Dialog...
Assignee: matt → rjc
.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
What do you you mean with (RESOLVED) LATER?
regression
Keywords: regression
LATER = "The problem described is a bug which will not be fixed in this version of the product."
blake, I know the official definition; let me rephrase. The Mozilla.org policy is, that regressions should be fixed ASAP or ideally not appear at all. <quote src="http://www.mozilla.org/hacking/rules.html"> The code should be better, not worse. </quote> The search feature is very cool and a great advantage of the new browser. Not everybody likes the sidebar. => No search dialog is a bummer. rjc, can you explain, why the code should not be enabled in Mozilla?
> rjc, can you explain, why the code should not be enabled in Mozilla? No reaction till now, REOPENing.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Later.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → LATER
Robert, please give a reason, why the dialog shouldn't be used.
*Still* no reaction. REOPENing. Please give a reason, why this has been removed or should not be reenabled.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → LATER
Keywords: helpwanted
Mr. Churchill, are you kidding me? Is your keyboard hosed? REOPENing and taking bug to end that.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
/
Assignee: rjc → mozilla
Status: REOPENED → NEW
Don, if I fix this bug, will the patches be accepted (assuming they are good)?
Status: NEW → ASSIGNED
jeez. The 'regression rules' do not apply as this was not a regression per se. This bug was 'latered' because it wasn't going to be fixed, just like the definition says. It really should be INVALID, cuz it's not a bug, it's the result of a planned out decision. The reason this came about is because the stand-alone search dialog was 'not yet ready for prime time'. Add to that we already duplicate the functionality in the sidebar search panel (I know you don't care) and there were bigger fish to fry. Everyone wants the dialog but there simply aren't time/ resources to do it hence -->LATER. If the goal is to ship a good browser soon, then trying to resurrect this doesn't fit well with that goal. This basically amouts to an RFE to return the Advanced Search Dialog and all its functionality. Let me be clear with this as well: The menu item does not point to the Search dialog because there is no dialog any more. More precisely, the dialog is there but you can't use it to search the Web anymore(just bookmarks and history). as for your last question, "Don, if I fix this bug, will the patches be accepted (assuming they are good)?" I think the answer is "if rjc says so". I hope I've answered your "why later" question w/o too much ranting. What's the Summary supposed to say? It should be fixed before this gets closed out.
> This bug was 'latered' because it wasn't going to be fixed, just like the > definition says. LATER is mostly obsoletely, now that this is an open source project. > the stand-alone search dialog was 'not yet ready for prime time'. What are the specific problems? > Add to that we already duplicate the functionality in the sidebar search panel We could use e.g. overlays. The search dialog in Mailnews doesn't duplicate the thread pane or filter dialog functionality either, but /uses/ it.
Target Milestone: --- → Future
pref("browser.search.powermode", 1)
Please enable it by default, and remove the Netscape search from "Search" -> "Search the WEB" ;) In case that search.powermode isn't enabled "Search" -> "Search the WEB" should link to the default Search Engine selected in the preferences. Adding mozilla1.0 keyword.
Now really adding Mozilla1.0 keyword and adding self to CC, sorry for the spam
Keywords: mozilla1.0
Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this bug is nsbeta1-.
Keywords: nsbeta1-
Sorry for the spam, I just wanted to follow knous's comment with a clarification. nsbeta1- keyword means that Netscape management has decided that it will not be able to contribute resources to fixing this for the next Netscape release. It does not mean that a fix for this would not be accepted. Normal r= and sr= checkin procedure still applies.
Assignee: mozilla → matt
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Changing personal priorities. Giving away most of my bugs :-( (reassigning to default owner). I will still track these bugs closely. If you need my input, feel free to ask me. New owner: Please do *not* close these bugs (as WONTFIX or whatever you may find) unless they are fixed. Rather, reassign to <nobody@mozilla.org>, if you don't want to work on them.
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
-> default owner
Assignee: matt → sgehani
What does pref("browser.search.powermode", 1) mean? Also, is this bug going to implement the fix recommended in comment #19?
Depends on: 172122
Blocks: 172122
No longer depends on: 172122
Is it still planned for a distant future or can I close the bug ? ;-)
It's a feature request, and I still this it would be nice. I never use the sidebar, because I find it inconvient, so this whole nice search feature of Mozilla is unavailable to me. The search dialog would allow me to use it. Although tabs make the whole search feature less advantagous.
OK, I change it as a Request for Enhancement.
Severity: normal → enhancement
Adding URL to a document from Karsten with some ideas for a new Search dialog. The files from the old broken dialog are no longer build and were removed from CVS via bug 250637.
URL: http://mozilla.tprac.de/powersearch.html
Product: Core → SeaMonkey
Assignee: samir_bugzilla → nobody
Priority: P3 → --
QA Contact: claudius → search
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago → 15 years ago
Resolution: --- → EXPIRED
Power search is long dead and not coming back => extension fodder.
Resolution: EXPIRED → WONTFIX
confirmed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.