User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030904 Firebird/0.6.1+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030904 Firebird/0.6.1+ Recent firebird builds select the URL in the urlbar when the user clicks in it (on the mouse-up event, actually), regardless of the setting of the browser.urlbar.clickSelectsAll flag (which is "false" by default on Linux). Reproducible: Always Steps to Reproduce: 1. Click in the urlbar when browser.urlbar.clickSelectsAll is false and the focus was not in the urlbar. Actual Results: The URL is highlighted. Expected Results: The caret should be placed at the position of the click with no highlighting. (Meta bug 62496 should note this bug's existence.)

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

Is this the result of a recent change? I'm asking because two people reported it against 09/04 builds and I don't see any earlier reports.

Just checked the 0.6.1 release and it doesn't show this behaviour. i.e it does the right thing.

I went back through the nightly releases, and the highlighting on mouse-up first started in the Linux builds in the 8-13 nightly.

Confirming bug.

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

Could this have been caused by the fix for bug 199507? It happened at about the right time, and removes a call to DispatchFocus(NS_GOTFOCUS, isMozWindowTakingFocus);

The fix I did was OS/2 only. This is a Linux issue.

Also ignores layout.word_select.stop_at_punctuation. Different bug?

I think this may be bug 193025, raised against Mozilla Browser product. Certain preferences in prefs.js (set either manually or using about:config) are ignored, but if they are changed directly in all.js then they take effect. Recommend this be closed as a duplicate. Is that appropriate when the other bug is against Mozilla Browser?

I don't see how this bug has anything to do with bug 193025. The browser.urlbar.clickSelectsAll setting even defaults to false on linux, but there does not seem to be any way to turn the single-click selection off, not even by editing all.js.

Yes, you're right. clickSelectsAll is hardcoded to true in browser.js (in browser.jar), and the preferences are never looked at. Sorry for the bug-spam.

Ahh! Blessed relief! I used a binary editor to edit browser.jar and changed var gClickSelectsAll from true to false, and the urlbar is now behaving properly again. So, it looks like the fix might be as simple as making firebird pay attention to the user's preference.

At the risk of more bug-spam, I would like to clarify the workaround that Wayne has used. There is no need to use a binary editor. browser.jar is a simple zipped file containing a number of folders and files, and can be unzipped using common software such as WinACE. browser.js can then be edited with a simple text editor and the files recompressed. Actually the files are simply packaged in the released code, not compressed (this is why Wayne could find the code with a binary editor), this is for runtime speed, but compressing does no harm.

The only place where this pref appears to be read is at: http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/navigator.js#649 Is this just not getting called by Firebird, or is that code broken?

This also happens for Mac OS X, HW/OS -> All/All Firebird also ignores the browser.urlbar.clickAtEndSelects setting.

Something's changed here. With Linux Firebird 0.7+ (I think about two weeks old) clicking the URL bar did select the text there. I prefered this (easier to type in keywords). With Firefox 0.8, clicking does NOT select the URL bar. (this seems to be the opposite of what people were reporting). I set browser.urlbar.clickSelectsAll to true in user.js, and still nothing. (about:config shows it set to true). Also, I don't see the browser.urlbar.clickAtEndSelects pref Torben mentioned in about:config. Since the behavior's changed in the last two weeks, someone want to verify windows is still functioning properly?

The only thing that changed is the default in the browser.jar file for some builds (e.g. Linux is affected, while Windows is not). The browser.urlbar.clickSelectsAll setting still does nothing, though. You have several easy ways to deal with this at the moment (not counting "suffer and grumble"): manually change the chrome/browser.jar file to change the value of gClickSelectsAll to "true", change your habits to type Ctrl-L when you want to type a new URL, or even type Ctrl-U after you click in the urlbar (which deletes everything under Linux, but (sadly) not under Windows). When you're going to be typing anyway, I find that using Ctrl-L is much more convenient than using the mouse, so I even change the chrome/browser.jar file under Windows to have gClickSelectsAll default to false. Also note that you can start a new search by typing Ctrl-L followed by Tab, which will select that whole field for easy replacement.

at this point, we are supporting the platform detaults, but not ever touching the pref. On one level this is acceptable, but it doesn't give users or large deployments the ability to set up Firefox to be truly platform-agnostic, so that it behaves exactly the same regardless of platform. What we want to do instead is use the preprocessor in firebird.js to set the prefs appropriately per-platform, and use that pref as needed taking, I need to ping ben/pch as to the preferred impl for this

FWIW, after a conversation about this on IRC, I understand that the default for Mac OS X is the wrong behaviour for the OS standard (although I think it matches the default for Mozilla, which is wrong...)

removing regression keyword (near as I can tell, we never supported the pref). Targeting for 1.0beta, if we're using the PP to determine which method to use, we might as well just stick the pref in firebird.js and be done with it (or use Mozilla's defaults, OS X issue notwithstanding)

-ing will take patch

There may be more general problem with firefox prefs. Someone asked me yesterday about word select, and while testing layout.word_select.stop_at_punctuation I discovered that it, like the other prefs mentioned here, works if changed in all.js in the install directory, but is ignored in the user's user.js or prefs.js (though it's read: putting it in user.js causes it to show up in prefs.js). I suspect the problems we've all seen with browser.urlbar.clickSelectsAll being ignored is a symptom of the same problem.

no, its because we don't check the pref and use hardcoded values of gClickSelectsAll in browser.js, I have a partial patch for this somewhere, I just have been working on bigger things. It will be fixed for 1.0beta, but there's bigger fish to fry for 0.9

fixed, branch and trunk