Open Bug 193025 Opened 22 years ago Updated 4 years ago

Pref "layout.word_select.stop_at_punctuation" can't be set in user's user.js.

Categories

(Core :: DOM: Selection, defect, P5)

Product:
Core
Component:
DOM: Selection
Platform:
x86
All
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: jasonb, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030212

This preference, set to false, stopped working sometime around 1/14.  It used to
be that when this preference was set to false, double-clicking in the URL bar
would select everything.  Now that's no longer the case.  This pref used to be a
workaround to bug 188567 but now it's not available.

I should have reported this on 1/14 when I noticed what was happening - instead
I resorted to setting the pref for a single click highlighting everything in the
URL bar.  But I've since found that to be more annoying, and would like to go
back to the double-click everything behaviour by using this pref (at least until
bug 188567 can be resolved).

I don't know if the pref was actually removed for some reason, but not finding
any reference to it, it looks like regression to me.  The pref should be fixed.

Reproducible: Always

Steps to Reproduce:
Sorry for the component, which is almost certainly incorrect.  I would have put
this under Preferences:Backend but the Bug Helper text seemed to indicate it
shouldn't go there.  Since the pref is "layout.word..." I picked general layout.
 I'm sure somebody can move it to the appropriate place.
Keywords: regression
How's about "selection"?  ;)
Assignee: other → mjudge
Component: Layout → Selection
QA Contact: ian → pmac
1/14 is approximately the time when a patch for bug 98546 was checked in (1/9 -
see bug 98546 comment 95).

You can use a triple-click to select the whole line.
> You can use a triple-click to select the whole line.

Yes, I know.  That's not the point. <grin>  I'd like to be able to use
double-click with this preference as a work-around.  (See bug 188567 comment 3.) 

However, double/triple/single clicking in the URL bar is all off-topic.  The
preference itself is broken and should be fixed.  (At least, I think that to be
the case without really reading through and understanding all of bug 98546.)

CC:ing Aaron to get his input here - it may be that this bug is invalid if it's
really doing what it's supposed to be doing...
> > You can use a triple-click to select the whole line.
> However, double/triple/single clicking in the URL bar is all off-topic.

I know, I was only offering it as a workaround.

> The preference itself is broken and should be fixed.

It seems so, certainly. On the other hand, I was planning to file an RFE to
special-case the URL bar so that stop_at_punctuation is always true there.
Perhaps someone had the same idea and already implemented it... Is the pref also
broken in normal text (outside the URL bar)?

(Now that I think of it, I don't remember ever seeing stop_at_punct behaviour on
Linux, including 1.3b. Could this bug be Windows-specific?)
> I was planning to file an RFE to special-case the URL bar so that 
> stop_at_punctuation is always true there.

For God's sake, don't do that!  For many of us, stop_at_punctutation is totally
useless for the URL bar, so I don't think I'm the only one here who would like
the option to turn it off.  Triple clicking is tremendously annoying, and though
I've been a long time Mozilla fan (since about M12), it's such an annoyance to
have to break the deeply ingrained habit of double clicking the URL bar, I'd
really rather just switch to IE with a 3rd party pop-up blocker, you know?

I admit I'm fairly ignorant of the underlying code, but would it be possible to
give stop_at_punctuation 3 options?  Always, never, and browser only (exclude
URL bar)?  I can understand why some people love the whole stopping at
punctuation feature, I'm just asking that you meet us halfway, allow those of us
who just can't deal with it a way to switch it off.
> Is the pref also broken in normal text (outside the URL bar)?

AFAIK, double-click in normal text always selected just a word, and this pref
was always URL bar specific - but I could be wrong.

> I don't remember ever seeing stop_at_punct behaviour on Linux

According to bug 188567 comment 12, "word_select.stop_at_punctuation [is] set to
false by default on Unix."
Kyle:

> > I was planning to file an RFE to special-case the URL bar so that 
> > stop_at_punctuation is always true there.
> For God's sake, don't do that!

:-) Don't worry, I've changed my mind. I don't think it would ever be
implemented, anyway. I guess I'll just manually turn on stop_at_punctuation on
Linux. I just feel it a pity that users who don't know of that pref can't find
it in the UI. But that's a completely different problem, sorry.

> For many of us, stop_at_punctutation is totally useless for the URL
> bar, so I don't think I'm the only one here who would like the option
> to turn it off.

I've noticed. :-) It just shows how people are different. I, contrary to your
POV, don't see the usefulness of having stop_at_punctuation off in the URL bar,
because in that case, there is always exactly _one_ word, so what's the point of
"select word", or "move by word", or "delete word"?
Jason:

> > Is the pref also broken in normal text (outside the URL bar)?
> AFAIK, double-click in normal text always selected just a word, and
> this pref was always URL bar specific - but I could be wrong.

I don't think so. The pref defines _what_ is considered a word, and I believe
that applies to everywhere where you can do word-operations (double-click,
ctrl+left/right, ctrl+shift+left/right, ctrl+delete/backspace...). Or, at least,
it should.

> > I don't remember ever seeing stop_at_punct behaviour on Linux
> According to bug 188567 comment 12, "word_select.stop_at_punctuation
> [is] set to false by default on Unix."

True (unfortunately, I'd say). But this bug is precisely about the pref's false
setting not working, so if this bug was also valid on Linux, I would have seen
word-selection in the URL bar, which I don't think I have. I'll try not to
forget to test tomorrow, when I'll get to a Linux box.
Indeed, Mozilla 1.3b on Linux selects the whole line when I double-click in the
URL bar. But, it should be noted that this setting is the default on Linux. So,
either this bug is Windows-specific, or it's actually a bug with setting the
pref in the user's prefs.js.
It's Windows specific then.  Despite the pref set to false, only a single "word"
is selected under XP.
Wrong. I just tried on Linux - the default there is false, but changing it to
true in the user profile's prefs.js file has no effect. Changing the default in
<moz inst dir>/defaults/pref/unix.js does work.

So, the bug is not caused by that pref not working at all; rather, it can't be
set in the profile.

Setting OS=All, clarifying summary (old summary: Broken pref:
"layout.word_select.stop_at_punctuation".). CCing the owner of "Preferences:
Backend", as that might actually be the right component for this.
OS: Windows XP → All
Summary: Broken pref: "layout.word_select.stop_at_punctuation". → Pref "layout.word_select.stop_at_punctuation" can't be set in user's prefs.js
Question, then:  What is the Win32 equivalent of unix.js?  (Where can I make a
change in my install to confirm that I can get Win32 to use "false"?)
> but changing it to
true in the user profile's prefs.js file has no effect.

An instance of mozilla wasn't running when you changed prefs.js, was it?
That would be C:\Program Files\mozilla.org\Mozilla\defaults\pref\all.js, if I
remember well (and if you installed to the default location).

There is an all.js file with defaults, and then a win.js (I think) file with
overrides that are Windows-specific. The default of
layout.word_select.stop_at_punctuation is set to true in all.js, and overriden
to false in unix.js but not in win.js.
ccarlen:
> An instance of mozilla wasn't running when you changed prefs.js, was it?

No, it wasn't. It's not going to be _that_ easy to solve. ;-)
Yes, Windows 2000 appears to be the same as Linux (comment 12); changing the
default in all.js works properly, but trying to override it in prefs.js does not
work.
Confirming reports that changing the pref in all.js works under Win32.  Prefs.js
is being ignored for (at least) this one preference.
See:
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextTransformer.cpp#119
This is the one and only time that pref is read, and a pref-changed callback is
not installed. Is it possible that nsTextTransformer::Initialize() is called
only once, before a profile is available? Also, the return value from
GetBoolPref is not checked, so if the pref was read when it was not initialized,
it would have a bogus value, but we'd never try to read it again.
sWordSelectPrefInited should be set to true only on successfully reading the pref. 
Changing this pref worked for me the last time I tested it.  People for whom
it's not working: do you have multiple profiles?  Are you going through the
profile manager to pick a profile?  Does it work if you run mozilla -P
profilename so you don't go through the profile manager?  If so, Conrad's
suggestion is probably the easiest fix, though a better fix (since lots of prefs
have this problem) would be not to read user.js and prefs.js until after we've
picked a profile.
> do you have multiple profiles?  Are you going through the
> profile manager to pick a profile?

No, and no.

> lots of prefs have this problem

That may be, but this is still a case of regression.  There was a period of time
(around 1/14) before which it worked just fine.
Bug 195904 is another case where someone reports that recently prefs have
stopped working and multiple profiles aren't involved.  I wonder if they're related?
The question of multiple profiles and it working before is beside the point. As
I pointed out, the code which reads the pref is bogus because it *is* dependent
on the order of things at startup. If it ever worked before, it was dumb luck.
This pref reading code is what needs to be fixed.
Blocks: 190615
Jasonb, why does this block bug 190615? I think these are completely independent
bugs.
From bug 190615 comment 4:

"Adding ability to edit this in preferences window could accompany this change"

Currently, that functionality is impossible due to this bug - so this bug blocks
that change which the reporter wants to have included as part of a solution to
bug 190615.
Er - may block it.  The reporter actually says later that he doesn't think it's
necessary, but suggests it anyway.  (The dependency can always be removed if
it's not part of the fix.)
Mike, you have CVS blame for this...
Blocks: 188567
QA Contact: pmac → sairuh
Conrad, are you suggesting just doing this?  I can't see it hurting at all.

  if ( prefBranch ) {
    PRBool temp = PR_FALSE;
- prefBranch->GetBoolPref("layout.word_select.stop_at_punctuation", &temp);
- sWordSelectStopAtPunctuation = temp;
- }
- sWordSelectPrefInited = PR_TRUE;
+ if
NS_SUCCEEDED(prefBranch->GetBoolPref("layout.word_select.stop_at_punctuation",
&temp)) {
+   sWordSelectStopAtPunctation = temp;
+   sWordSelectPrefInited = PR_TRUE;
+ }
Sorry, I didn't format that very well.  Apologies for the spam.

     if ( prefBranch ) {
       PRBool temp = PR_FALSE;
-      prefBranch->GetBoolPref("layout.word_select.stop_at_punctuation", &temp);
-      sWordSelectStopAtPunctuation = temp;
-    }
-    sWordSelectPrefInited = PR_TRUE;
+      if
NS_SUCCEEDED(prefBranch->GetBoolPref("layout.word_select.stop_at_punctuation",
&temp)) {
+        sWordSelectStopAtPunctation = temp;
+        sWordSelectPrefInited = PR_TRUE;
+      }
+    }

I just set stop_at_punctuation=true using about:config in Linux, and although it
didn't have an immediate effect, it _did_ work after a restart of Mozilla,
without me having to edit the system-wide default prefs. So, it seems this bug
is half-fixed. :-) Using build 2004030208. Can anyone confirm this?
(In reply to comment #30)
> I just set stop_at_punctuation=true using about:config in Linux, and although it
> didn't have an immediate effect, it _did_ work after a restart of Mozilla,

Hmm, I tried again and it does take effect immediately. It's been fixed in bug
232321.

*** This bug has been marked as a duplicate of 232321 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Reopening.

Bug 232321 is Linux specific - this bug is All platforms.  Does bug 232321
really fix more than just Linux?  If so, it should have its OS changed and this
bug can be re-resolved FIXED again.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Plus - it shouldn't be marked as a duplicate but marked fixed by the other bug...
Under the 03/11-08 build with XP, setting this prefence to false still causes
the entire URL to be highlighted when double-clicking on it.  (Note that this is
the opposite of what happened when I originally filed this bug - first it would
behave as if set to false no matter what I did - now it's behaving as if it's
set to true no matter what I do.  I don't know when this change.  But the point
is that changing the preference still has no effect.) 
(In reply to comment #32)
> Bug 232321 is Linux specific - this bug is All platforms.  Does bug 232321
> really fix more than just Linux?  If so, it should have its OS changed and this
> bug can be re-resolved FIXED again.

Notice that this bug, when reported, had OS=Windows, and reported the opposite
symptom of bug 232321. The bugs _are_ duplicates, this one just happens to have
a better description because it has been refined over time. OTOH, bug 232321 has
a patch (which is not Linux-specific), so I think it's better to mark this one a
dupe and not vice versa.

(In reply to comment #34)
> Under the 03/11-08 build with XP, setting this prefence to false still causes
> the entire URL to be highlighted when double-clicking on it.

But that is the correct behaviour!

> now it's behaving as if it's set to true no matter what I do.  I don't
> know when this change.  But the point is that changing the preference
> still has no effect.)

True is the default on Windows, unless you have changed that on your
installation. You say above that setting to false makes double-click highlight
the whole URL, which is correct, i.e. the pref _has_ an effect. Please clarify
yourself.

I am still convinced that this is fixed and a dupe of bug 232321, but feel free
to prove me wrong. BTW, the fix for bug 232321 was checked in on 2004-02-19
according to a comment on the bug, so you could try nightly builds from the days
before and after that to test the difference.
> Please clarify yourself.

Forgive me if I was unclear.

What I'd meant to say is that when I opened this case, it didn't matter if I set
the preference to true or false - double-clicking would only select a word.

Now - it doesn't matter if I set it to true or false - double-clicking always
selects the entire URL.

The intent of this bug, while an offshoot of bug 188567, was filed for the
specific intent of not having the preference ignored when set in prefs.js or
user.js.  (What it does by default is something else.)

Currently, this preference is STILL being ignored when set in my user preference
settings.  (It's simply that its default behaviour has changed.)

This bug doesn't care about the symptoms of word selection - only with whether
or not a user can change the preference and have Mozilla honour that change. 
(Rather than having to set it in all.js.)
(In reply to comment #36)
> The intent of this bug, while an offshoot of bug 188567, was filed for the
> specific intent of not having the preference ignored when set in prefs.js or
> user.js.  (What it does by default is something else.)

Agreed.

> Currently, this preference is STILL being ignored when set in my user
> preference settings.  (It's simply that its default behaviour has changed.)

There, we disagree. As far as I can tell, the pref now works. And I'm not aware
of the default having changed. There is a difference, though: I'm testing in
Linux. (I'll try Windows after the weekend, I'm leaving now.)

How, exactly, do you set the pref? Does it work if you use about:config and
change it there? It should take effect immediately, without even needing to
restart Mozilla. (It does for me.)
Confirming again with 03/12-08 build under XP.  Changing the pref makes no
difference to the behaviour.
> How, exactly, do you set the pref?

Using either prefs.js (while Mozilla is not running) or user.js.
(In reply to comment #39)
> > How, exactly, do you set the pref?
> 
> Using either prefs.js (while Mozilla is not running) or user.js.

Did you try about:config? Does that work (without restarting Mozilla)?
> Did you try about:config? Does that work (without restarting Mozilla)?

I just tried it now - and, yes, it does work.  (As has all.js always worked.) 
But this preference should still work with user.js or prefs.js when Mozilla is
closed.  So - what's going on?
Neil added the listener for the pref - the lack of which was the original cause
of this bug. Looks to me like it should work. Neil, can you take a look?
(In reply to comment #41)
> > Did you try about:config? Does that work (without restarting Mozilla)?
> 
> I just tried it now - and, yes, it does work.  (As has all.js always worked.) 

Then the fix from bug 232321 clearly works.

> But this preference should still work with user.js or prefs.js when Mozilla is
> closed.  So - what's going on?

I'm baffled. Could it be that you're accidentally editing the wrong file? Are
you aware that user.js has priority over prefs.js? When you change the pref with
about:config and then quit and restart Mozilla, is the change remembered? When
you create a new profile, does the pref work in it? Could the pref be locked?
Are you using a custom build? I'm running out of ideas. :-( Perhaps there's a
way to log what's happening in the pref service...
> Then the fix from bug 232321 clearly works.

But not as a fix for this bug because prefs.js is still being ignored.

> Could it be that you're accidentally editing the wrong file?

No.

> Are you aware that user.js has priority over prefs.js?

Yes.  And even if I weren't, that wouldn't explain why user.js is being ignored
when I set it there.

> When you change the pref with about:config and then quit and restart
> Mozilla, is the change remembered?

Yes.

> When you create a new profile, does the pref work in it?

No.

> Could the pref be locked?

You're going to have to explain that one.  I'm not sure how to lock a pref - nor
do I think it would end up in that state in a new profile.

> Are you using a custom build?

No.
Is there anybody else who can test this in a Win32 (or even XP) environment?
Aha!

Okay, first off my apologies to Vaclav and to anybody else who's been following
this discussion recently.  It turns out I'm *partially* to blame for the
confusion here.

As I was going to sleep it occurred to me that the only thing that about:config
does is to change entries in prefs.js and modify the current, run-time,
settings.  So if it worked on a restart it *had* to be the case that me
modifying prefs.js myself should do the same thing.  So obviously I was messing
things up somehow.

I went back and re-tested everything again, and it turns out I must have done
something wrong before.  (I swear I'd first tested in prefs.js and then worked
with user.js after that.)

The bottom line is that changing this in prefs.js does change it - but user.js
is definitely still ignored.

Currently, I have the preference set to false in user.js and true in prefs.js -
and have also restarted Mozilla.  Although user.js should be overriding its
behaviour, it's selecting a single "word", stopping at the punctuation.

So, while prefs.js IS now fixed (I'll put what I thought to be accurate results
down to a post 60s blackout or something) - something still needs to be done
about user.js.

Modifying summary accordingly...and backing away from the keyboard.
Summary: Pref "layout.word_select.stop_at_punctuation" can't be set in user's prefs.js → Pref "layout.word_select.stop_at_punctuation" can't be set in user's user.js.
(In reply to comment #46)
> As I was going to sleep it occurred to me that the only thing that about:config
> does is to change entries in prefs.js and modify the current, run-time,
> settings.  So if it worked on a restart it *had* to be the case that me
> modifying prefs.js myself should do the same thing.  So obviously I was messing
> things up somehow.

That was my thought, too. :-) Thanks for clarifying this.

> The bottom line is that changing this in prefs.js does change it - but user.js
> is definitely still ignored.
> 
> Currently, I have the preference set to false in user.js and true in prefs.js -
> and have also restarted Mozilla.  Although user.js should be overriding its
> behaviour, it's selecting a single "word", stopping at the punctuation.

Can you test whether user.js works at all, i.e. whether the problem is specific
to the particular pref that we're discussing? By any chance, could the problem
be caused by bug 196840? I don't know if/how you can capture Mozilla's console
output in Windows... Try typing "mozilla > stdlog 2> errlog" in Moz's
installation directory and see whether you get any interesting messages in those
files after you quit Moz.
> Can you test whether user.js works at all,

I set user_pref("browser.tabs.warnOnClose", true); to false and closed a window
with multiple tabs - no warning.  I changed it back again and got a warning.  So
it seems that user.js is being processed - just not for this bug's particular
preference.

> Try typing "mozilla > stdlog 2> errlog"

I did that, it didn't generate anything...
Hmm. Mozilla is *also* ignoring the user_pref("editor.singleLine.pasteNewlines",
3); preference when set via user.js - although it works just fine when I set it
via about:config.  (I'm now using a 7/20-08 build under XP.)

Is there a class of preferences that are being ignored?  If so, this bug should
be expanded to include more than just the preference currently referenced.
Hmm... I'm seeing this working for Ctrl+Left but not Ctrl+Right...
Okay, here's another preference that's totally ignored in user.js but which
works just fine in prefs.js:

browser.throbber.url or user_pref("browser.throbber.url", "http://someurl.com/");

If you put this into user.js, the browser will completely ignore it.  Only when
in prefs.js does it work.
(In reply to comment #51)
> Okay, here's another preference that's totally ignored in user.js but which
> works just fine in prefs.js:
> 
> browser.throbber.url or user_pref("browser.throbber.url", "http://someurl.com/");
> 
> If you put this into user.js, the browser will completely ignore it.  Only when
> in prefs.js does it work.

Please file a new bug for this issue as it is not in congruence with this bug's description.

Thanks!
> Please file a new bug for this issue as it is not in congruence with this
> bug's description.

I have already done so (see bug 310132).  Did you read my comment? That was just an example of another preference that is being ignored.  If there's an underlying cause that fixes whatever it is that causes these preferences to be ignored (for this bug, specifically, the word layout preference) then all of these bugs could be fixed.
Jason, I noticed that bug 310132 now works for you. Is that true for this bug as well?
Unfortunately, no.  I just re-tested under the 7/9-09 build and it's still ignoring the setting in user.js.
Assignee: mjudge → nobody
QA Contact: bugzilla → selection

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.