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

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
18 years ago
9 years ago

People

(Reporter: gerv, Unassigned)

Tracking

(Depends on: 1 bug, {meta})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

[ 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/.
Blocks: 68427
Even if you turn off all relevant current prefs, Mozilla still does URI guessing 
and/or search :-(

Gerv

Updated

18 years ago
Hardware: PC → All

Comment 2

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

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

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

18 years ago
timeless: bug 73974 is the correct one. Thank you.

Comment 6

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

Comment 8

17 years ago
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
Last Resolved: 17 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

Comment 10

17 years ago
Adding meta keyword.  Reassigning to gerv who is using this for tracking purposes.  
~Samir
Assignee: matt → gerv
Status: REOPENED → NEW
Keywords: meta

Comment 11

17 years ago
Adding bug 115539 - Stop adding "www." and ".com" to domain names automatically.
Depends on: 115539

Comment 12

17 years ago
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).

Updated

17 years ago
Depends on: 133371
Not mine.

Gerv
Assignee: gerv → nobody

Comment 14

17 years ago
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
(Assignee)

Updated

10 years ago
Product: Core → SeaMonkey
Assignee: samir_bugzilla → nobody
QA Contact: claudius → search

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
Status: NEW → UNCONFIRMED

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

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 20

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 21

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
This meta bug still has open dependencies. Re-marking NEW.
Status: UNCONFIRMED → NEW

Comment 23

9 years ago
What comment #0 says is implemented. This works for me.
Status: NEW → RESOLVED
Last Resolved: 17 years ago9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.