If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Firebird is ignoring the browser.urlbar.clickSelectsAll setting

RESOLVED FIXED in Firefox1.0beta

Status

()

Firefox
Toolbars and Customization
P2
minor
RESOLVED FIXED
14 years ago
11 years ago

People

(Reporter: Wayne Davison, Assigned: mconnor)

Tracking

unspecified
Firefox1.0beta
Points:
---
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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 1

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

Comment 2

14 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

14 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

14 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.

Comment 5

14 years ago
Confirming bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

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

Updated

14 years ago
Keywords: regression

Comment 7

14 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 8

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

Comment 9

14 years ago
Also ignores layout.word_select.stop_at_punctuation.  Different bug?

Comment 10

14 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

14 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

14 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

14 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

14 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

14 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

14 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

14 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

14 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

14 years ago
Assignee: hyatt → bugs
(Assignee)

Comment 19

14 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

14 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

14 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)
Severity: normal → minor
Keywords: regression
Target Milestone: --- → Firefox1.0beta
(Assignee)

Updated

14 years ago
Priority: -- → P2

Updated

14 years ago
Flags: blocking1.0?
-ing will take patch
Flags: blocking1.0? → blocking1.0-
(Assignee)

Updated

14 years ago
Status: NEW → ASSIGNED

Comment 23

14 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

14 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

14 years ago
Created attachment 149350 [details] [diff] [review]
the fix
(Assignee)

Comment 26

14 years ago
fixed, branch and trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

11 years ago
QA Contact: bugzilla → toolbars
You need to log in before you can comment on or make changes to this bug.