Closed Bug 77740 Opened 24 years ago Closed 20 years ago

Domain Guessing: support configurable list of sufixes

Categories

(SeaMonkey :: Location Bar, defect, P4)

All
Other
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 175238
mozilla1.2alpha

People

(Reporter: bobj, Unassigned)

References

()

Details

(Keywords: helpwanted, intl)

This is something we've talked about for a long time, but I don't think we ever logged a bug... Currently, if you type "acme" in the location bar, we will try to resolve it as "www.acme.com". But outside the US, it would be better to also try "www.acme.co.<ccTLD>" where <ccTLD> is one of the IANA defined Country Code Top Level Domains. See link. We wouldn't want to try all of them, so this should be configurable. The localized builds might localize the default setting. This support could be generalized, not just for ccTLDs (e.g., org, net, gov). We could have a pref which is an ordered list of TLDs. For Japan we might default to "co.jp,com". So if a user types "sony", we'd try "www.sony.co.jp" and if that failed, "www.sony.com". We might limit the list, because it could make it very slow to have to try multiple lookups. See the "www.*.com trick": http://lxr.mozilla.org/seamonkey/source/docshell/base/nsWebShell.cpp#1044 Not sure who or what component should get this. Temporarily marking Internationalization component.
So your proposing to externalize TLD part (to .property file for example). I think this is a l12y, adding tao to cc.
This is actually a dup of bug 37867. However I wanted to wait with implementing that until the new autocomplete has landed...
or sort of anyway... That bug is about adding some items in the autocomplete dropdown, It wasn't very popular to suggest any kind of autosearching (although it already exists) My plan for fixing the bug was like this: Make a pref that would contain a list of TLDs that the user often visited (configurable via pref-panel). The pref would be a list of TLDs that the user wanted, for example ".se .com .org .nu" if you live in sweden. However that same list could very well be used for the autosearch.
(sorry, didn't finish the plan) Then add the selected items at the bottom of the autocomplete list. So if the user typed "acme" in the url-bar, the following items would be added at the bottom of the list www.acme.se www.acme.com www.acme.org www.acme.nu
adding l12y keyword for tracking purposes. is this something we would like to land before the next milestone??? it sounds like a pretty kewl thing, and fits task-completion need (i.e. user convenience).
Keywords: intl
This is not an i18n nor l12y bug; more like a customizability issue and can be done via pref as suggested in the original bug. -> changing component to XPApp.
Component: Internationalization → XP Apps
Reassign bug to owner and QA contact of component.
Assignee: nhotta → pchen
QA Contact: andreasb → sairuh
->url bar
Component: XP Apps → URL Bar
QA Contact: sairuh
really this time...
Assignee: pchen → alecf
QA Contact: claudius
removing intl keyword, as this is no longer and intl bug.
Keywords: intl
Keywords: helpwanted
Target Milestone: --- → Future
> So your proposing to externalize TLD part (to .property file for example). No, I'm proposing that instead of hardcoding the .com trick, there is a list of TLDs read from a pref that is tried. The defaults would come from a localized file instead of a generic default location. I think the code would be trivial, but we need to consider performance and usability issues.
Adding intl keyword and roberts to cc: list.
Keywords: intl
It seems to me this TLDs could be stored as prefs (like accept-lang) and externalized into "chrome://navigator/locale/navigator.properties."
nav triage team: Marking p4 and mozilla0.9.5. Certainly nice to have and would be cool for international users.
Priority: -- → P4
Target Milestone: Future → mozilla0.9.5
Correcting a misnomer that I started :-} This is not just about TLDs which mean Top Level Domains. Outside of the US we may need to go one level deeper (e.g., co.jp, or.jp). Updating the summary from 'try to resolve hosts with non .com TLDs' to 'try to resolve hosts with non-".com" domains'
Summary: try to resolve hosts with non .com TLDs → try to resolve hosts with non-".com" domains
Keywords: nsbeta1+
Really good idea, I was going to submit something else and was right to search first. My idea was that holding a key while pressing enter could autocomplete different TDLs (e.g. CTRL+ENTER: www.*.com, SHIFT+ENTER: www.*.qc.ca, ect. I think both ideas should be implemented. If I want to go to a .org and .com is tried first, it's highly likely the site will exist but not be what I'm looking for. That's when the keys become useful. Or simply for faster access since it only tries the one you want. One thing to think about: if I type bugzilla.mozilla I want it to autocomplete to bugzilla.mozilla.org, not www.bugzilla.mozilla.org. Simply checking for dots should do it.
Removing myself, and adding Todd and Sol.
over to urlbar owner
Assignee: alecf → blakeross
Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work. If anyone disagrees with the new target, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla1.2
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
Status: NEW → ASSIGNED
I'd like to see a way to _disable_ this .com-trick. When I want to go to domain.com, I'd like to go to domain.com and not www.domain.com which may be different hosts to begin with. Feels really stupid to type the correct domain name and arrive at an error message like "www.domain.com could not be found", and having no way to correct it.
Summary: try to resolve hosts with non-".com" domains → url auto-complete: option to try to resolve hosts with non-".com" domains
-> defaults. This is likely a dupe.
Assignee: hewitt → location-bar
Status: ASSIGNED → NEW
QA Contact: claudius
Summary: url auto-complete: option to try to resolve hosts with non-".com" domains → Domain Guessing: support configurable list of sufixes
Whiteboard: dupeme
Duping to newer bug (with a patch) on SeaMonkey. FYI the Firefox bug is bug 221161. *** This bug has been marked as a duplicate of 175238 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Whiteboard: dupeme
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.