Search terms preceded by question mark in URL bar should trigger default search for terms

RESOLVED WORKSFORME

Status

--
enhancement
RESOLVED WORKSFORME
17 years ago
7 years ago

People

(Reporter: blahedo, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Reproducibility: Always

To reproduce: 
1) Click in URL bar
2) Type "?ballroom dance" (no quotes, of course)
3) Hit enter

What should happen: moz uses default search engine (google in my case) to search
for "ballroom dance"

What does happen: nothing

Let me start by saying this seems related (at least philosophically) to bug
65911, but is not the same; here, nothing at all happens.  In NS4, typing
"ballroom dance" or "cnn" (no question mark) used NS's Internet Keywords
feature, while typing "?ballroom dance" or "?cnn" (with question mark) used your
default search engine.

Now, in mozilla (20010813), it *does* include a "Search Google for "ballroom
dance"" bar under the URL bar, and if you hit Tab then enter, the search is done
as you'd wish.  However, my initial interpretation of this bar was that it was a
'tool tip'-ish thing that told me what I'd do if I hit Enter; I discovered the
Tab trick by accident.

I've tested this on mozilla builds 0.9 (20010505), 0.9.2 (20010628), 0.9.3
(20010801), and today's nightly (20010813), both with and without Internet
Keywords being on, with slightly varying results (bare "cnn" handling fixed both
with and without Internet Keywords):

0.9, 0.9.2: IK off: "?ballroom dance" and "?cnn" do nothing; "ballroom dance"
and "cnn" give a "could not be retrieved" message.  IK on: ?bd, bd pull up NS
search page; ?cnn pulls up www.cnn.com; cnn can't be retrieved.

0.9.3, 20010813: IK off: ?bd, ?cnn do nothing; cnn pulls up www.cnn.com; bd
can't be retrieved.  IK on: ?bd, bd pull up NS search page; ?cnn, cnn pull up
www.cnn.com.

Comment 1

17 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All

Comment 2

17 years ago
over to real owner
Assignee: alecf → blakeross

Comment 3

17 years ago
--> samir
Assignee: blakeross → sgehani
Component: URL Bar → Search

Comment 4

17 years ago
The design has changed in the new codebase (mozilla/netscape6).  This is a
feature request.
Severity: normal → enhancement
Keywords: helpwanted
Priority: -- → P3
Summary: Search terms preceded by question mark in URL bar do nothing → [RFE] Search terms preceded by question mark in URL bar do nothing
Target Milestone: --- → Future
(Reporter)

Comment 5

17 years ago
Feature request?  It works in netscape 4, and silently fails in mozilla.  That 
sounds like a parity bug to me.

Comment 6

17 years ago
Todd, comments?  
Keywords: 4xp

Comment 7

17 years ago
IMO, this is a low priority request.  Based on search traffic data, very few
users of 4.x ever discover or use this functionality.  The vast majority click
on the big search button in the main toolbar.

Searching from the URL bar in 6.x browsers is very discoverable already with the
search button next to the field and the autocomplete widget.  These types of
things are imminently more discoverable than the question mark before the term
in the URL field.  There is no reason to encourage users to place a question
mark before the term that they enter in the search field as far as I can see.

Let me say that I'm not opposed to 4.x parity here as long as it does not get in
the way of the search experience we have designed.  However I don't think this
is worth investing cycles in at this point.

Comment 8

17 years ago
Unless of course there are other folks from the mozilla community willing to
contribute their cycles to invest in implementing this feature.  I'd be happy to
review any such work and check it in.  

Thanks for the inciteful comments, Todd.

Comment 9

17 years ago
I hope you mean insightful.  Versus incite, as in inciting a riot.

Comment 10

16 years ago
*** Bug 125147 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
*** Bug 123748 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Summary: [RFE] Search terms preceded by question mark in URL bar do nothing → Search terms preceded by question mark in URL bar should trigger default search for terms
(Assignee)

Updated

10 years ago
Product: Core → SeaMonkey
Assignee: samir_bugzilla → nobody
Priority: P3 → --
QA Contact: claudius → search
Target Milestone: Future → ---

Comment 12

10 years ago
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

Comment 13

10 years ago
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

Comment 14

10 years ago
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

Comment 15

10 years ago
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

Comment 16

10 years ago
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

Comment 17

10 years ago
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

Comment 18

10 years ago
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

Comment 19

9 years ago
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
Last Resolved: 9 years ago
Resolution: --- → EXPIRED

Comment 20

7 years ago
WFM.
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.