137867 - hang after shift/ctrl while dragging listbox scrollbar

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX, defect, P2)

Description

[Andrew Schultz]

Mozilla hangs (not very often) when ctrl-selecting items in a select listbox.  I
have seen this with build 20020327 (Alpha-Linux) through 20020415 (PC-linux). 
I'm filing under Events because the stacktrace (coming up shortly) only shows a
lot of gtk/gdk action and some Mozilla event code.

To reproduce:
1) go to Bugzilla query page
2) select an OS
3) select another OS via ctrl-click
4) repeat #3

eventually it hangs, although it sometimes takes a while.

Comment 1

[Andrew Schultz]

Attachment: stacktrace

stacktrace during hang.

by executing "finish" commands in gdb, it can get all the way back to
#16 g_main_run()

Comment 2

[R.K.Aa.]

i think form controls is better for this - reassigning

Comment 3

[Andrew Schultz]

better steps to reproduce:

Hit Ctrl and (quickly) left-click-drag on the listbox scrollbar.
HANG (~40% reproducibility)

I can also reproduce this back as far as I have builds (20020114)

Comment 4

[Sitsofe Wheeler]

I've got another (very similar) way to reproduce this. On the program listbox
click (and hold) on the scrolltab, press (and hold) shift and move up and down.
Mozilla will hang using up 100% of the cpu. 1.0RC-1 Linux.

Comment 5

[Vadim Berezniker]

I'll add some bit more clear directions:
Start dragging the slider in the Browser listbox. 
While dragging move the cursor a bit to the left over the actual listbox.
Press Shift and there's your hang.

Comment 6

[Andrew Schultz]

it seems that just about any combo of ctrl/shift and dragging the listbox
scrollbar is bad.  Sitsofe and Vadim's testcases hang Mozilla for me (also using
ctrl in place of shift), and I do not even seem to need to move my mouse over
the listbox elements (#3 in Vadim's steps-to-reproduce).

Comment 7

[rods (gone)]

-->

Comment 8

[John Keiser (jkeiser)]

I am suspicious of that stacktrace, is it real?  That hang has little to 
nothing to do with form controls.  CC'ing joki for input.

Comment 9

[Andrew Schultz]

yes, the stacktrace is for real, although it does appear strange -- the hang
appears to be Mozilla (gtk) repeatedly responding to non-existent events.  But
the only trigger seems to be on the listbox scrollbar.  Other scrollbars,
including textbox and dropdown list, work fine.

Comment 10

[Andrew Schultz]

I've figure out a bit more of what's going on:

1. http://lxr.mozilla.org/mozilla/source/widget/src/gtk/nsGtkEventHandler.cpp#810
gtk_handle_event passes the ctrl keystroke to the listbox via gtk_main_do_event

that ends up in gtk_mozbox_key_press_event 
2. http://lxr.mozilla.org/mozilla/source/widget/src/gtksuperwin/gtkmozbox.c#155
it first tries to give it to the listbox, but gtk_widget_event returns FALSE.
so it passes it back to the parent (gtk_put_event) which does step 1 again.

Mozilla is playing event-hot-potato with itself!

also, hitting other keys while dragging the listbox scrollbar generates events
that are "handled" by the listbox (gtk_widget_event returns TRUE).  hitting any
keys while doing other things (pulldown select) does not event make it into
gtk_mozbox_key_press_event.

Comment 11

[John Keiser (jkeiser)]

That sounds like bad behavior on the part of the GTK system to me--if the
listbox doesn't handle the event you shouldn't pass the event back to the
listbox again :)

Comment 12

[Kevin McCluskey (gone)]

-> John

Comment 13

[Ben Bucksch (:BenB)]

What I'm seeing is that in the product listbox, selecting Browser, then
SHIFT-selecting Mailnews (i.e. search in Browser and Mailnews only), I get an
infinite loop (100% CPU for a few minutes until I kill Mozilla) about every
second time.

Comment 14

[Andrew Schultz]

> SHIFT-selecting Mailnews (i.e. search in Browser and Mailnews only)

ctrl-select will get you browser/mailnews only...

are you sure you're not hitting shift (or control) *while* you're scrolling?  I
originally thought that control-selecting elements was the trigger (see comment
0), but eventually discovered I was hitting control early while I was still
scrolling.

Comment 15

[Ben Bucksch (:BenB)]

Yes, you're probably right. Sorry for not checking more carefully earlier. I so
intuitively overlap the actions that I don't notice... And, yes, I meant CTRL.

Comment 16

[Andrew Schultz]

*** Bug 162547 has been marked as a duplicate of this bug. ***

Comment 17

[Joe Grossberg]

*** Bug 162547 has been marked as a duplicate of this bug. ***

Comment 18

[Kevin McCluskey (gone)]

Bulk moving P1-P5 un-milestoned bugs to future. 

Comment 19

[Andrew Schultz]

this works in a gtk2 build (still happens with linux trunk build 20021120/gtk1)

Comment 20

[Carine Held]

Using Vladimir's Method, I was able to reproduce the bug on the 12/26/03 Linux
build. Minimised test case attached.

Comment 21

[Carine Held]

Attachment: Minimised Test Case

Comment 22

[Tom Parker]

Can't reproduce this on a 20050510 gtk2 Linux build.

Comment 23

[Wayne Mery (:wsmwk)]

(In reply to comment #19)
> this works in a gtk2 build (still happens with linux trunk build 20021120/gtk1)

Andrew ^^ closeable? 

Comment 24

[Andrew Schultz]

yes, gtk1 is dead.  resolving WFM on gtk2