User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031001 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031001 Firebird/0.7+ MF should provide an option to use '.de', '.uk', '.<insert country here>' in place of '.com' when the user hits Ctrl+Enter in the URL bar. Many of the websites visited in some countries do not end in '.com', but in that country's TLD. Related: bug 177498 Reproducible: Always Steps to Reproduce:

I tend to agree with you, but then I'm not the one who implemented this in the first place. I'm also pretty sure that I've seen a dev say somewhere that what you're asking for wouldn't be done but I can't seem to track it down. As it stands, this would require a bit of a code rewrite since the keybindings are not, as far as I know, contained in localization .dtds but rather in the content source itself. Creating a pref for this instead might be easier, but I doubt that will happen either. Pretty sure this is a WONTFIX unless someone contributes some code to fix this US-centric mess (I'm Canadian, btw, and I use .ca at least as much as .com and I never ever use .net). If you want, I can search the source code and tell you where to change it if you compile your own, but that's about all I can do. David - You seem to know more about this than I do - do you know if there are plans to do this?

Wouldn't this be the task of the localization folks?

No it's not, since, as I was alluding to in comment #1 and which I have since verified, the source code for this is not in the locale dirs but rather in the browser source code itself, so it is out of the purview of the localization teams. The code for this feature is presently located at or about line 1280 of mozilla/browser/base/content/browser.js. A CVS diff between revisions 1.130 and 1.137 gets most of the initial code insert, though it was subsequently moved elsewhere in the file. Besides that, there are no other English localizations (eg, no en_CA or en_GB), so there'd be no way to get a build with .ca or .co.uk url appending even if were a locale-based feature. What's needed are three of our infamous hidden prefs, something like browser.url.complete.type1, etc. Anyway, I'm going to confirm this one for dev review until someone tells me otherwise since I find no wontfix dupes on this.

For those who wish to customize their own endings, this patch serves as a template. If you're not building from CVS, you can apply the changes to chrome/browser.jar//content/browser/browser.js (that is, unzip your browser.jar). Ctrl+Enter now adds .ca #instead of .com Shift+Enter now adds .org #instead of .net (nb there is an incorrect comment in the original which is now "correct") Ctrl+Shift+Enter now adds .com #instead of .org This patch is a bit of personal bias, since imho .org should have been assigned to Shift+Enter as it is far more commonly used than .net.

actually, since its javascript, it could easily be adapted to be localized what do internationalized versions of IE do for Ctrl-Enter? always .com?

I think adding (hidden prefs.js) preferences for this sounds reasonable, considering IE is already using different endings for localized builds. There should be three prefs: for Ctrl+Enter, Shift+Enter and Ctrl+Shift+Enter.

There you go Mike - David has answered your question. I know you just hate adding prefs, but there's no other good way of doing this, since we're never going to create localizations for the rest of the Anglosphere, not to mention English-speaking users in non-Anglophone countries. So this bug should live or die based on adding three prefs for the three cases.

I know the problem about this. Japanese localized version of IE6 leads me http://www.cnn.co.jp when I enter "cnn" and press Ctl+Enter. We should not hardcoded. + intl

There has been some consideration about also changing this code so that it uses preferences related to the current domain guessing feature, so please make sure you coordinate any changes to this function.

*** Bug 248608 has been marked as a duplicate of this bug. ***

Firefox has prefs browser.fixup.alternate.prefix = "www" and browser.fixup.alternate.suffix = ".com" like Mozilla. We can use them for domain name completing. The bug #260808 describes problem, how to localize these prefs. The user requests, which we are often listening in our Czech Mozilla forum is for -> CTRL+ENTER -> complete like IE (for the Czech users it means czilla -> complete as www.czilla.cz). I thinks we can start by this - CTRL+ENTER and use the prefs: browser.fixup.alternate.prefix and browser.fixup.alternate.suffix = ".com" like in Mozilla.

this would be good but it late to be adding features for 1.0. couldn't even consider at this point without a well tested patch.

Hofmann> Here is a simple patch, which I hope will satisfy a lot of (not only Czech) users. I would be glad if you help me with the review.

Comment on attachment 162551 [details] [diff] [review] Patch according to my comment #11 Is there still possible to make this in the FF1.0?

this is still an enhancement, not a bug. making it customizable is a new feature.

Mike, from my point of view, this is internationalization problem and bug on the way to fully localized Firefox. Our Czech users are continously asking how to set it to local ".cz" suffix. I believe, that other local teams have similar problem. Mike, could you look on patch and say, if anything is wrong or missing?

Comment on attachment 162551 [details] [diff] [review] Patch according to my comment #11 looks good to me

We've got what we expect to be RC bits in hand (I think). We don't intend to take changes after RC except for regressions discovered in the RC. Shaver says this looks safe so maybe it can slip in if we do end up taking more changes after the RC. I don't think it's a blocker for our release, though.

Comment on attachment 162551 [details] [diff] [review] Patch according to my comment #11 sr=shaver, looks robust. I wouldn't respin RC1 for it, though, so it might not make it into 1.0.

Comment on attachment 162551 [details] [diff] [review] Patch according to my comment #11 We're respinning the RC. let's get this in quickly.

RC1 is out, but we can pick this in the next day or two.

chofmann: So I want to clarify to you before you check-in: These prefs they want to use have been in the tree for some time, they were used by "Domain Guessing". This means changing these prefs for localized builds will also change the strings used by domain guessing in localized builds. http://www.mozilla.org/docs/end-user/domain-guessing.html

> This means changing these prefs for localized builds will also change the > strings used by domain guessing in localized builds. Same behaviour of completion and domain guessing is also purpuse. For details see my comments in the dependent bug #260808 comment 8, 10. Example: People in the English world want by writing 'microsoft' be directed to the www.microsoft.com but people e.g. in the Czech Republic want www.microsoft.cz (Czech version). This patch means: when the user (or localization team) want to change domain guessing suffix, it also change CTRL+ENTER completion suffix (which is in 90% what they means).

Comment on attachment 162551 [details] [diff] [review] Patch according to my comment #11 need re-approval now that we're past 1.0 RC. setting back to request.

decided that this one missed the cut off, it is too late for this feature in 1.0. should go in early for 1.1.

Comment on attachment 162551 [details] [diff] [review] Patch according to my comment #11 mozilla/browser/base/content/browser.js 1.356

This is fixed on the Firefox trunk builds (where the first release with this fix will be Firefox 1.1 then AFAIK), marking so.

Per the bug's summary, this isn't fixed, as the only changes were to functionality for Ctrl+Enter. Reopening to accommodate work on other modifier combinations...please edit bug summary if this actually is resolved properly.

>this isn't fixed, as the only changes were to functionality for Ctrl+Enter For the localizers isn't probably necessary to change these wide-world used suffixes, but allow it for the experienced users is a good idea. -> reasiggning to Ben.

Patch needs to be relanded, when aviary branch has landed completely on trunk.

Patch relanded following aviary branch landing

For this feature in the trunk, please see bug 175238.

Why is this still open?

(In reply to comment #33) See comment 28.

Mass edit: Changing QA to default QA Contact

Mass edit: Setting correct QA for location bar/autocomplete. My bad. I forgot I had once been Autocomplete QA too. Hmm, why can't I just set the QA of bugs to the default QA of the component in a mass edit rather than having to do it manually...?

I think this feels like something better accomplished by an add-on and not the core product, but leaving that decision up to module owner.

(In reply to Shawn Wilsher :sdwilsh from comment #37) > I think this feels like something better accomplished by an add-on and not > the core product, but leaving that decision up to module owner. I concur!