User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.3) Gecko/20030325 Build Identifier: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.3) Gecko/20030325 I have a two-button "mouse" on my laptop, which simulates a third button by clicking both buttons "at once". Occasionally I'll fail to click both at the exact same time, with various effects. This evening, I found one which was completely reproducible, and had effects varying from incomplete drag-n-drop, to a hung browser, to a crash. To reproduce, I click the left mouse button on a link, then click the right one very quickly thereafter (less than .1 seconds on my 600 MHz laptop), and start moving the mouse right after that. I reproduced it on my housemate's laptop, which is running the same build of Mozilla but is much faster (2.2 GHz); it took a little more patience to reproduce, but both he and I can reproduce it. This originally happened on a link in an eBay page, but we subsequently reproduced it on one of the links on Google's home page. When it successfully reproduces, the "floating page" part of the drag-n-drop icon will be hovering somewhere near the link (which will be highlighted), and the cursor will change to the corner-with-crosshairs drag-n-drop cursor. No amount of clicking seems to cause it to exit this state. (Apparently pressing "esc" will cause it to give up, but that key is physically broken on my laptop.) If I switch virtual screens, it figures out that it's in a bad state, and reverts back to normal after a few seconds. Occasionally, rather than wedging like this, it will just crash. I grabbed it while it was in the process of doing so, with the following commands: $ truss -t'' -S segv,bus -p `pgrep mozilla-bin` <reproduce the problem> $ gcore `pgrep mozilla-bin` I've saved the resulting core file at http://foo.net/~blakej/mozcore.gz. A quick glance at the core file shows the following suspicious entries at the top of the stack trace: dd6e7003 gtk_drag_remove_icon+0x13 (0) dd6e6255 gtk_drag_set_icon_window+0x35 (0, 0x8dfe378, -2, -2, 1) dd6e63c4 gtk_drag_set_icon_pixmap+0xc4 (0, 0x814af00, 0x8e81c70, 0x8e81c30, -2, -2) Notably, gtk_drag_remove_icon (and gtk_drag_set_icon_window, and gtk_drag_set_icon_pixmap) are all called with a NULL first argument. I don't have the source available, but looking at the disassembly for this function, it looks like it's really not expecting that argument to be NULL. Reproducible: Always Steps to Reproduce: See "Details". Actual Results: See "Details". Expected Results: Not crash, and not get into a state where the cursor can't be cleared by a single click or two. See "Details" for a link to a core file generated at the moment of the SEGV.
I was able to reproduce the wedge on Solaris/SPARC. Possibly a dup of bug #147838 ?
Could be, but note that this one occasionally caused my browser to crash.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.