Closed
Bug 218315
Opened 21 years ago
Closed 21 years ago
Firebird is ignoring the browser.urlbar.clickSelectsAll setting
Categories
(Firefox :: Toolbars and Customization, defect, P2)
Firefox
Toolbars and Customization
Tracking
()
RESOLVED
FIXED
Firefox1.0beta
People
(Reporter: bugzilla, Assigned: mconnor)
References
Details
Attachments
(1 file)
1.56 KB,
patch
|
Details | Diff | Splinter Review |
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.)
Comment 2•21 years ago
|
||
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.
Comment 3•21 years ago
|
||
Just checked the 0.6.1 release and it doesn't show this behaviour. i.e it does the right thing.
Reporter | ||
Comment 4•21 years ago
|
||
I went back through the nightly releases, and the highlighting on mouse-up first started in the Linux builds in the 8-13 nightly.
Updated•21 years ago
|
Keywords: regression
Comment 7•21 years ago
|
||
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);
Comment 10•21 years ago
|
||
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?
Reporter | ||
Comment 11•21 years ago
|
||
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.
Comment 12•21 years ago
|
||
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.
Reporter | ||
Comment 13•21 years ago
|
||
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.
Comment 14•21 years ago
|
||
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.
Comment 15•21 years ago
|
||
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?
Comment 16•21 years ago
|
||
This also happens for Mac OS X, HW/OS -> All/All Firebird also ignores the browser.urlbar.clickAtEndSelects setting.
OS: Linux → All
Hardware: PC → All
Comment 17•21 years ago
|
||
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?
Reporter | ||
Comment 18•21 years ago
|
||
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.
Updated•21 years ago
|
Assignee: hyatt → bugs
Assignee | ||
Comment 19•21 years ago
|
||
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
Assignee: bugs → mconnor
Comment 20•21 years ago
|
||
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...)
Assignee | ||
Comment 21•21 years ago
|
||
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)
Assignee | ||
Updated•21 years ago
|
Priority: -- → P2
Updated•21 years ago
|
Flags: blocking1.0?
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Comment 23•21 years ago
|
||
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.
Assignee | ||
Comment 24•21 years ago
|
||
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
Assignee | ||
Comment 25•21 years ago
|
||
Assignee | ||
Comment 26•21 years ago
|
||
fixed, branch and trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
QA Contact: bugzilla → toolbars
You need to log in
before you can comment on or make changes to this bug.
Description
•