72751 - [0.8.1 Branch] Clicking OK in Preferences dialog does nothing

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Ari Pollak]

When using Mozilla 0.8.1 build 2001031918, going into the preferences window,
doing anything, and then pressing OK, does not work, but Cancel does.

Comment 1

[Chris McAfee]

I've been debugging pref panel bugs all day with a current
(3/20) build, things seem to work fine for me.  Ok dismisses
the dialog, values get written out, etc.  Linux, rh62.

Can you provide more config info?  Try again?  We had some
gtk lossage over the weekend.

Comment 2

[Ari Pollak]

Using Debian GNU/Linux unstable, with gtk/glib 1.2.9. Using the the experimental
cache Moz build works fine, along with fixing a bunch of other bugs which are
present in 0.8.1 latest, like prefs not being saved between sessions.. Note that
I was only seeing this bug on 0.8.1, not the trunk.

Comment 3

[James Manning]

on today's (2001/03/24) nightly build, 0.8, and 0.8.1, I see the same
behavior.  RH 7.0 laptop

with the nightly build, i'm seeing debug output when i click ok, though:

JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code:
0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIPref.SavePrefFile]"  nsresult:
"0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame ::
chrome://communicator/content/pref/nsPrefWindow.js :: anonymous :: line 247" 
data: no]

Comment 4

[sairuh (rarely reading bugmail)]

simplest case: what if you do nothing after opening Preferences? is the OK
button still unresponsive?

Comment 5

[Ari Pollak]

Yup, OK still has no effect after doing nothing.

Comment 6

[James Manning]

same here... this is from just running 0.8.1, opening preferences and clicking
the ok button.

jmm@laptop:/usr/local/mozilla> ./run-mozilla.sh 
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.
     LIBRARY_PATH=.:./components
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
Warning prev sibling is not in our list!!!JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code:
0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIPref.SavePrefFile]"  nsresult:
"0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame ::
chrome://communicator/content/pref/nsPrefWindow.js :: anonymous :: line 247" 
data: no]

Comment 7

[jmm]

works great on latest nightly build (2001040605)

Comment 8

[Jeroen Ruigrok van der Werven]

Some additional information.

FreeBSD 4.2-STABLE as of a few days old [begin april 2001].
GTk+ 1.2.10, glib 1.2.10.
Mozilla 0.8.1 from the FreeBSD ports.

No .mozilla directory.  Gets created normally when I start mozilla as my user uid.
I then proceed to preferences, click ok.  Works perfectly.
I can click a few options and click ok.  Works ok.

As soon as I click Navigator > Bookmarks I get the following error logged in the
JavaScript console:

Error: rName has no properties
Source File: chrome://communicator/content/bookmarks/pref-bookmarks.xul
Line: 52

Repeatable on demand.

Sometimes after logging JavaScript errors this causes the OK button to stop
functioning.  I'll see if I can track it down.  But I do see the behaviour.

Hope this helps.

Comment 9

[jmm]

This is still fixed in nightly builds.  It's confirmed in 0.8 and 0.8.1 already,
so please re-check against a nightly build if you've posted here.  I would love
to see this marked resolved/fixed since in my experience it's now fixed :)

Comment 10

[Jeroen Ruigrok van der Werven]

OK, guess I am a little off with my dates. :)

I'll try the latest sources and see if I can get it to build, and I'll report my
findings back as well.

Thanks.

Comment 11

[Robert Hugh]

Latest nightly build seems to be more resistant to this bug, but it still occurs.

In Preferences > Navigator, toggling an option ("Home" used for my testing),
opening another category, then going to Internet Search, and changing search
engine (switching between bugzilla and google).  OK button stops working.

Seems to be many factors affecting occurance of the bug, including if "ending"
on a category in which something is changed, if a field being changed is
check-box/int, and similar.

Some JavaScript errors were also output during testing as well, which makes me
wonder if some of the intermittance is related to a bug occurring when changing
one of the fields.. i.e. changing history from 9 days to 8 wont create the
condition needed for OK to be pressed, due to a bug specific to changing the
history field (possibly affected by something else).

Errors noted are:

JavaScript error: 
chrome://communicator/content/bookmarks/pref-bookmarks.xul line 52: rName has no
properties

JavaScript error: 
chrome://communicator/content/pref/pref-history.xul line 55:
document.getElementById("shistMax") has no properties

Comment 12

[Blake Ross]

I fixed the history part of this.  The bookmarks part is being covered by bug 
75154.  Marking fixed for lack of a better resolution. 

Comment 13

[sairuh (rarely reading bugmail)]

okay, v.