Closed Bug 68407 Opened 20 years ago Closed 11 years ago

W3C CUAP: Allow the user to override all URI-guessing mechanisms

Categories

(SeaMonkey :: Search, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: gerv, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: meta)

[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

1.6 Allow the user to override any mechanism for guessing URIs or keywords.

     Many user agents compensate for incomplete URIs by applying a series
     of transformations with the hope of creating a URI that works. For
     example, many user agents transform the string www.w3.org into the URI
     http://www.w3.org/. The user should be able to control whether, for
     example, typing a keyword should invoke a Web search or whether the
     user agent should prepend http://www. and append .org/.
Even if you turn off all relevant current prefs, Mozilla still does URI guessing 
and/or search :-(

Gerv
Hardware: PC → All
See also bug 34943, "automatic www. and .com shouldn't happen on links".  It's 
not clear if that's what they're talking about...
URL guessing in 0.8.1 breaks use of URL Expander.

'URL Expander' is a custom Internet Search tool. Entering 'whois fodge.net'
*SHOULD* cause Mozilla to navigate to:

http://kimihia.org.nz/projects/urlexpander/demo/urlexpander?uri=whois+fodge.net

With 0.8.1 it attempts to guess the URL as "http://whois%20fodge.net/", instead
of following the Internet Search preferences.
stephen: this is the wrong bug (bug 73974 might be closer to what you want), 
but why doesn't your thing just use mozilla bookmark keywords?  if it does then 
please file a new bug or comment in the appropriate regression bug if you can 
find it.
timeless: bug 73974 is the correct one. Thank you.
Should prepending of "http://" also be disabled or only the more fancy "fixup"?
Hmm. It's a web browser, after all. Ideally, if no protocol is given, http:// 
should be assumed but the string in the UI should not be rewritten. Whether 
that's possible or not, I don't know. If not, I'd be in favour of rewriting 
rather than barfing (as we would have to) even if that, in the strictest sense, 
means we don't do what the W3C want to the letter.

Gerv
since unchecking the 'internet keywords' pref disables searches and keywords
that seems to only leave the www.com completion as a concern. That seems to be
addressed in bug 34943.
makring WFM
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Dude, this is a meta-bug.

Added 37867 as a dependency which should be resolved WONTFIX :-)

Gerv
Status: RESOLVED → REOPENED
Depends on: 34943, 37867
Resolution: WORKSFORME → ---
No longer depends on: 37867
Adding meta keyword.  Reassigning to gerv who is using this for tracking purposes.  
~Samir
Assignee: matt → gerv
Status: REOPENED → NEW
Keywords: meta
Adding bug 115539 - Stop adding "www." and ".com" to domain names automatically.
Depends on: 115539
re #6 and #7:

if a hostname starts w/ ftp, ftp:// is usually assumed to be the scheme type.

I've never seen or filed a bug on this, but that seems to be another type of
behavior that should be documented (and perf'd).
Depends on: 133371
Not mine.

Gerv
Assignee: gerv → nobody
Unless you are the component owner and sending something to limbo, isn't the
default owner the right person for this?
Assignee: nobody → sgehani
Well, it's a tracking bug... but sure, assign it to sgehani if that's a better
option.

Gerv
Product: Core → SeaMonkey
Assignee: samir_bugzilla → nobody
QA Contact: claudius → search
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 meta bug still has open dependencies. Re-marking NEW.
Status: UNCONFIRMED → NEW
What comment #0 says is implemented. This works for me.
Status: NEW → RESOLVED
Closed: 19 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.