113866 - Problems w/ gtk dropdowns and xvfb - multiple items selected

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

I use a modified xvfb X11 server that does not generally send up mouse motion
events, just clicks (this is an artifact of our input device and bandwidth
issues).

When I open a dropdown select widget, if I click on an entry it selects that
entry - but it leaves the old entry selected as well.  In the area showing which
entry was selected, it shows either the first one selected in the list, or the
original value (I'm not sure which; all the dropdowns I tried were defaulting to
the 1st entry selected).  If I instead (after opening it) use up and down arrows
to select entries in the dropdown, it properly removes selection from the old
items.  Perhaps some of the code is keying off some type of mouse position
message to remove selections?  Note also that mouse clicks are left-button only,
and cannot be held (it generates mouse-down mouse-up).

Bryner suggested I contact you (jkeiser).  Feel free to get anyone else in you
like.  I'm willing to work on this (and could even make minor mods to the Xvfb
server, though not major ones, and we can't turn on mouse-motion).  If it
matters (I doubt it), the window manager was RatPoison 1.0.0.

Comment 1

[John Keiser (jkeiser)]

Does the server send MouseDown and MouseUp?  If so, my suspicion is we are just
changing the selection on MouseDown and MouseMove, and ignoring on MouseUp since
*obviously* (heh) if you have it selected on MouseDown and you always modify on
MouseMove, you will always know where the proper spot is on MouseUp.  Try a full
click to open the dropdown, move down, and click on the option, what happens there?

If it's not sending MouseDown/MouseUp (just Click), then the problem is slightly
more insidious.  For various reasons we do not do much of anything with the
actual Click event, from what I can remember.

I have a magical fairy patch for bug 112241 that might fix the issue I describe
above (I at least modified MouseUp with regard to selection) ... but I'll make
sure when I get enough time to document and put the patch up.  Tonight has been
designated Mozilla Night so hopefully I will manage to get to it.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

We send ButtonPress immediate followed by ButtonRelease, with the same x, y, and
time.
			(set x, y, time)
			e.u.u.detail = 1;
 			e.u.u.type = ButtonPress;
			mieqEnqueue(&e);
			e.u.u.type = ButtonRelease;
			mieqEnqueue(&e);
			

Comment 3

[John Keiser (jkeiser)]

Hmm.  When does this happen?  If you press the mouse down, move it, and mouse
up, is the reported x,y that of the mouse down or mouse up?

And is this failing for you when you full-click on the select to open it, move
down, and click again on the option you want to select?  Or just when you mouse
down to open the select, move mouse (drag), and mouse up on the option you want?

I'm pretty sure we do the selection on either mouse up or mouse down (but not
both), it's kind of weird that it's not working ...

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

With this input device there's no way to hold-and-move, so down is always
followed instantly by up with the same time and position (as per that snippet).

We're opening with a click (down/up), then clicking on one of the entries
(down/up).

I'll attach a jpg showing what I see.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Attachment: image of the problem

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Please ignore the layout issues (font size and widget placement)

Comment 7

[John Keiser (jkeiser)]

Very very strange.  I will try to look at it tonight after posting my other
patch, but I'm not sure where to start ... if you're so inclined, one thing you
could do to help is dump a printf() in nsListControlFrame::MouseUp(),
MouseMove() and MouseDown() and find out if they are firing when you click.  If
you end up working on the problem (which may be the case as I don't have a
testcase handy) these are the methods you'll look at.  I'll provide any help I can.

Comment 8

[John Keiser (jkeiser)]

I am guessing this is the source of your problem:

http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsListControlFrame.cpp#2620

At a glance, I am thinking mChangesNotNotified did not get changed and thus it's
reset.  It should be impossible to have two selected at a given time, though :(

I am thinking my Magical Fairy Patch will fix it (I got rid of that silly
variable) but I have not yet tested thoroughly enough to make sure there are no
regressions--and there definitely could be some.  I will attach the current
patch shortly, if you're so inclined perhaps you could take a look and maybe try
it out.  It should be a lot saner to understand than the previous stuff too,
though I need to go back through it once more and make sure.  (This was a
late-nighter :)

Comment 9

[John Keiser (jkeiser)]

Attachment: Indiglo Patch

This needs some cleanup before commit, but most functionality that I've tested
is there and working.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Thanks for looking into this.  I haven't applied the patch yet, but I will
soon.  (the codebase I'm testing this in is a bit behind currently, at 0.9.5,
and the patches don't apply cleanly, so I'll have to wait a few days until I
roll forward to 0.9.6).  Glancing at the patch file it looks more sane, as you
said.

Comment 11

[John Keiser (jkeiser)]

rjesup: an updated version of that patch is sitting in bug 112241.  If you want
to test, you can test against that.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

Tested using current trunk build (from a day or two ago).  Appears to be fixed
by the checkin for bug 112241, as per jkeiser.  Closing as fixed.