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

Status: RESOLVED WORKSFORME

(SeaMonkey :: Search, defect)

Description

[Gervase Markham [:gerv]]

[ 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/.

Comment 1

[Gervase Markham [:gerv]]

Even if you turn off all relevant current prefs, Mozilla still does URI guessing 
and/or search :-(

Gerv

Comment 2

[Jesse Ruderman]

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...

Comment 3

[Stephen D Cope]

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.

Comment 4

[timeless]

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.

Comment 5

[Stephen D Cope]

timeless: bug 73974 is the correct one. Thank you.

Comment 6

[Ben Bucksch (:BenB)]

Should prepending of "http://" also be disabled or only the more fancy "fixup"?

Comment 7

[Gervase Markham [:gerv]]

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

Comment 8

[Claudius Gayle]

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

Comment 9

[Gervase Markham [:gerv]]

Dude, this is a meta-bug.

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

Gerv

Comment 10

[Claudius Gayle]

Adding meta keyword.  Reassigning to gerv who is using this for tracking purposes.  
~Samir

Comment 11

[Jonas Jørgensen]

Adding bug 115539 - Stop adding "www." and ".com" to domain names automatically.

Comment 12

[benc]

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).

Comment 13

[Gervase Markham [:gerv]]

Not mine.

Gerv

Comment 14

[benc]

Unless you are the component owner and sending something to limbo, isn't the
default owner the right person for this?

Comment 15

[Gervase Markham [:gerv]]

Well, it's a tracking bug... but sure, assign it to sgehani if that's a better
option.

Gerv

Comment 16

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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 20

[Robert Kaiser]

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 21

[Robert Kaiser]

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 22

[Ashley Bischoff (blog at handcoding.com)]

This meta bug still has open dependencies. Re-marking NEW.

Comment 23

[Robert Kaiser]

What comment #0 says is implemented. This works for me.