36422 - radio buttons are not visibly checked/unchecked

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[stephen]

I tried to take the slashdot poll. If it matters, I'm running under GNOME and
the enlightenment window manager.

Comment 1

[R.K.Aa.]

Which build ID are you using? I tested this on 2000-041908 M16 linux, and it
works fine.

Comment 2

[Gwyn Judd]

[e-mail] you should read
http://www.mozilla.org/quality/bug-writing-guidelines.html the bug reporting
guidelines. You need to be more detailed (what happened? what did you do? what
did you expect to happen?). Also what buildid is this (the little number in the
bottom right hand corner)? Have you tried a nightly build? Oh and it WORKSFORME
on linuxppc 2000041919.

Comment 3

[Gwyn Judd]

cc'ing me

Comment 4

[stephen]

I've tried to send clarifications here and they don't show up.
For the third time now:

I'm runing RH 6.0 on a Dell Inspiron 3500.  I downloaded the M15 linux build
that you're pointing folks to on your home page.  If you're not interested in
but reports against that build, delete this bug report now.  I searched bugzilla
for similar bug reports, and did not see one that matched the behavior I had
which was (again): I entered http://slashdot.org/index.pl in the location field
at the top.  Once the page came up, I put the mouse on one of the slashdot poll
radio buttons and clicked.  I received no visual feedback.  No visible change
occurred.  I expected the radio button I had clicked to darken or be otherwise
shaded.  My left mouse button was functioning properly in all other windows, and
was following links within M15 without problem.  It is conceivable that, because
I was also running an instance of Netscape 4.7 at the time in addition to the
GNOME desktop + Enlightenment, that I had run out of colors, and that M15
couldn't get the shade of gray that it wanted to color the button with and
perhaps thus did nothing.   When not also running Netscape 4.7, I don't have the
problem; I'm unable to run further tests right now, but I'll update if I can get
something more reproducible.

Comment 5

[Gwyn Judd]

Hey noone said we weren't interested, sorry if you took what I said as a flame
it's just that the report you gave us wasn't terribly helpful. The added
information is excellent and I thank you profusely for taking the time to help
the progress. Nevertheless I still don't see the behaviour you are getting :). 

Comment 6

[Asa Dotzler [:asa]]

Over to XPToolkit Widgets for a look.  Thanks for the addded information 
[e-mail]

Comment 7

[stephen]

Build 2000041811.  I can now reliably reproduce the bug.

1. Start Mozilla.
2. Make sure Sidebar is visible.
3. Enter http://slashdot.org in location bar at top, hit return.  Slashdot page
comes up, including Slashdot poll.
4. Use the scrollbar to scroll down to the slashdot poll.  If you don't use the
scrollbar to get to the poll before doing the next step, the scrollbar, while
moving itself, does not change the appearance of the page, i.e., you can't move
around the slashdot page.  I hadn't noticed this before, since the first thing I
usually do on slashdot is scroll through the headlines.  I think I remember
seeing this bug already reported.
5. In View, Uncheck Sidebar.  Sidebar slides away.  There ceases to be visual
feedback of mouseovers on Slashdot poll radio buttons, and clicking the radio
buttons produces no visible change.  Here's a transcript of the session
messages. The Gdk-CRITICAL message toward the bottom occured when I clicked on
the radio button:

Script started on Fri Apr 28 10:43:43 2000
[stephen@linuxlaptop package]$ ./mozilla^M
.//run-mozilla.sh ./mozilla-bin^M
MOZILLA_FIVE_HOME=/home/stephen/package^M
  LD_LIBRARY_PATH=/home/stephen/package^M
       SHLIB_PATH=/home/stephen/package^M
          LIBPATH=/home/stephen/package^M
      MOZ_PROGRAM=./mozilla-bin^M
      MOZ_TOOLKIT=^M
        moz_debug=0^M
     moz_debugger=^M
Profile Manager : Profile Wizard and Manager activites : Begin^M
Profile Manager : Command Line Options : Begin^M
Profile Manager : Command Line Options : End^M
ProfileManager : GetProfileDir^M
ProfileManager : GetProfileDir^M
Profile Manager : Profile Wizard and Manager activites : End^M
WEBSHELL+ = 1^M
 I am inside the initialize^M
 Hey : You are in QFA Startup ^M
(QFA)Talkback loaded Ok.^M
WEBSHELL+ = 2^M
assuming d&d is off for Navigator^M
nsCollationUnix::Initialize mLocale = C^M
nsCollationUnix::Initialize mCharset = ISO-8859-1^M
nsCollationUnix::Initialize mLocale = C^M
nsCollationUnix::Initialize mCharset = ISO-8859-1^M
WEBSHELL+ = 3^M
****Gfx Scrollbar Special case hit!!*****^M
Setting content window^M
Loading page specified via openDialog^M
****Gfx Scrollbar Special case hit!!*****^M
in SetSecurityButton^M
Document http://www.mozilla.org/projects/seamonkey/release-notes/ loaded
successfully^M
Document: Done (2.09 secs)^M
WEBSHELL+ = 4^M
WEBSHELL+ = 5^M
Document http://slashdot.org/ loaded successfully^M
Document: Done (2.466 secs)^M
WEBSHELL- = 4^M
^M
Gdk-CRITICAL **: file gdkwindow.c: line 1702 (gdk_window_get_parent): assertion
`window != NULL' failed.^M
WEBSHELL- = 3^M
WEBSHELL- = 2^M
WEBSHELL- = 1^M
Hey : You are in QFA Shutdown ^M
~nsProfile ^M
WEBSHELL- = 0^M
[stephen@linuxlaptop package]$ exit^M
exit^M

Script done on Fri Apr 28 10:48:54 2000

Comment 8

[Gwyn Judd]

Hey nice work stephen :) I get this too now buildid 2000041919 on linuxppc.
Anyone check this on Windows?

Comment 9

[Peter Trudelle]

confirmed, using 42809 verification build on Linux, changing component to HTML
Form Controls, reassigning

Comment 10

[Peter Trudelle]

has anyone filed a bug against the scrolling failing to update? That sounds like
View Manager...

Comment 11

[rods (gone)]

reassigning

Comment 12

[Gwyn Judd]

It seems to me like they are all part of the same bug because they all seem
related to the turning off of the sidebar. Other things I noticed, if I turn off
the sidebar when I am on my homepage, the vertical scrollbar turns white and
there is no way to scroll down. If I then click inside the browser window I get
these messages:

Gdk-CRITICAL **: file gdkgc.c: line 288 (gdk_gc_unref): assertion `gc != NULL'
failed.

Gdk-CRITICAL **: file gdkgc.c: line 288 (gdk_gc_unref): assertion `gc != NULL'
failed.

Gdk-CRITICAL **: file gdkwindow.c: line 1707 (gdk_window_get_parent): assertion
`window != NULL' failed.

Interestingly if I turn the sidebar on and off within a session nothing seems to
go wrong, it is only when mozilla starts up with the sidebar on and you
subsequently turn it off that bad things happen.

Comment 13

[Gwyn Judd]

hmmm I just checked with build 2000030708 and I do not get the bug so it may
have been introduced recently.

Comment 14

[Gwyn Judd]

hmmm this is weird. Now I only get the strange scrollbar behaviour once I have
unchecked the sidebar. ie. I don't get it unless I get the other behaviour, so I
think they are probably part of the same bug.

Comment 15

[Gwyn Judd]

[e-mail] do you want to try a nightly build? I no longer get the
behaviour on 2000042708

Comment 16

[stephen]

The bug no longer occurs for me in 2000042709, nor in 2000050111.

Comment 17

[Gwyn Judd]

Okay marking as fixed (hopefully, I just got my perms :) )

Comment 18

[Vladimir Ermakov]

Verifying on:
 Windows 98 build 2000-09-19-05-M18
 RedHat Linux 6.2 build 2000-09-08-M18