Closed Bug 736811 Opened 12 years ago Closed 10 years ago

Mouse occasionally changes to drag cursor and the mouse buttons stop functioning

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

14 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: linux.user.since.2002, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

Sincerely hope this is a duplicate of a bug with a pending patch.
Tried searching for likely phrases and didn't find a likely match...

Particularly annoying usability issue:

Moving the mouse around -- with no buttons depressed -- the mouse cursor occasionally will change into a drag cursor.  Sometimes (not always), the current tab will move to a new window and the cursor remains a drag cursor even afterward.  Attempts to abort the false "drag" (ESC, trying to actually drag and drop something, changing vts, etc) do not work.  <alt>+<tab>, and perhaps other window manager keyboard shortcuts, does not work.  Interestingly, the keyboard still works in Firefox, although browsing with an effectively disabled mouse is a real challenge.

Usually end up resorting to changing to a virtual terminal and killing firefox:

(firefox:7870): Gtk-CRITICAL **: IA__gtk_clipboard_get_for_display: assertion `!display->closed' failed

$ grep -c 'IA__gtk_clipboard_get_for_display' ~/.xsession-errors
6

So, I've hit this 6 times since ~/.xsession-errors has been reset, not counting another several times when running from the console where the GTK error was originally observed...

Even the frequency of occurrence is inconsistent:
Sometimes it's good for a while, other times I hit this in quick succession.
This is rather frustrating...

Definitely hit on nightly v14.
Can't recall if also encountered on v10.

Speculation:
It's like it got stuck waiting to pick up a "drag item" that doesn't exist?
You have reported this as a Windows XP bug, but comment 0 indicates this is a Linux issue. Has it happened to you with Windows XP as well?

Anyway, this happens to me too when running trunk on Linux, like once a day or so. Annoying indeed. Unfortunately I've not found out how to reproduce it. Sometimes I've been able to regain control over my computer by pressing Ctrl+T Ctrl+Q, but I've also used the virtual terminal to kill Firefox.
Correcting OS -- should be Linux.

Have not observed on Windows XP (yet); however, do not run nightly there...
OS: Windows XP → Linux
Haven't seen this for awhile, but it recurred a few days ago...
Happened again.  This time, while the cursor changed before moving near the tab bar, a tab was torn off and moved to a new window...
I can replicate with SeaMonkey 2.10b2:
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:13.0)
Gecko/20120522 Firefox/13.0 SeaMonkey/2.10
The cursor changes to a Drag & Drop cursor, I can move the cursor around (including outside of SeaMonkey. However clicking any mouse button, or rotating scroll wheel makes no difference at all. Keyboard, including function keys, works fine.

The only way that I can regain control of the cursor is open a new terminal (Ctrl-Alt-t) or drop to a vt (Ctrl-Alt-F1 thru 6) and use 'killall seamonkey'. Once the application has been killed, the mouse returns to a normal cursor & I again have complete control.

I can replicate by opening a -mail -browser & immediately going to the mail window, selecting 'Inbox' on any one of my email accounts (POP3 or IMAP) and moving the cursor to a message to select. At that point the cursor immediately changes to a D&D.

I can ssh into the machine when it is in this state, but cannot find anything in the dmesg or Xorg.0 logs that changes when I replicate this.

I cannot replicate if I fall back to SeaMonkey 2.9.1 (same machine, same profile). However, I do notice the the cursor _briefly_ changes to a D&D cursor when I drag it from 'Inbox' to message title. I'll try to get a screenshot & attach.
And I've just replicated with SeaMonkey 2.10 final. 

Please tag this bug as 1) confirmed, and 2) critical as the issue causes data loss due to having to kill seamonkey in order to regain control of the mouse.
I can confirm it also in SeaMonkey 2.10 final and 2.10a2, using Mageia 1 (Gnome 2.32.1, Linux kernel 2.6.38). Never experienced before 2.10 launch.

I've closed and reopened SeaMonkey about 8 times with Mail as the initial only component, and the issue has reproduced every time, both using SM 2.10 and SM 2.12a2. In the Error Console I haven't noticed any message that sounded related to drag and drop problems.

However, after that I've reopened one more time SeaMonkey, everything has worked right in Mail and Browser and it still works OK.

Still, I concur with NoOp in this bug should no longer be in UNCONFIRMED state, since it clearly is not an individual case. I have been able to close SM every time in an ordered way, although it may also be because I had another non-SM window (a Gnome terminal), as it is true that mouse was basically unresponsive to click events, even outside of SM windows. So, I'm not sure of raising importance to critical, but it is probably above "normal".
Thanks Ricardo. I did discover (using both GNOME and KDE) that I do have some limited use of the keyboard; I am able to use alt-F etc to get to the SeaMonkey menus to shut it down.

Note: I also tested on two other linux machines this evening - both installed new, with only one POP3 user email account, and 1 news server (news.mozilla.org). I also use GNOME & from Hartmut's comment suggesting that it might be a GNOME problem I tested both of those using KDE and GNOME - same results. 

Attached are two screenshots of the process.
Replicated using icewm window manager, so the issue is soley SeaMonkey & not a desktop window manager issue. At least not using GNOME (2 and 3.4x), KDE, and icewm.
It is also worth mentioning that the problem, when happens, is usually on the very first minutes of running and in Mail window only. I haven't been able to reproduce the problem in the browser windows, nor in the mail & news window if I've been running SeaMonkey for a while (let's say 10 minutes).

Also, it seems as if crossing the boundaries between the different panels (folder list, message list or message preview) was triggering the problem.

BTW, what exactly is needed to change the bug status from UNCONFIRMED to NEW? Maybe a fixed set of steps to reproduce the problem?
I've not stumbled upon this bug in Firefox Nightly for a while, but it annoyed me daily before. I do hope it's gone forever!

(In reply to Ricardo Palomares from comment #12)
> BTW, what exactly is needed to change the bug status from UNCONFIRMED to
> NEW? Maybe a fixed set of steps to reproduce the problem?

https://developer.mozilla.org/en/Confirming_unconfirmed_bugs

Ideally one would like a minimal testcase that makes the bug appear each and every time when running the latest Nightly with a new, clean profile and performing the stated steps to reproduce.
I can reproduce regardless of how long I wait before selecting a message folder: I've tested for 10 min, 15 min, and 20 min (I have spare machines & VM's to test. 

Like Ricardo, I also found that the issue isn't caused by moving the cursor from the blank message pane to the message Subject header. The problem occurs when moving the cursor out of the blank message window *for any reason.  

However, I have discovered that if I first select Go|<account>|Inbox (or newsgroup), the cursor works normal from that point on. 

I guess the key is finding what code/action causes the cursor to jump to the blank message window when an Inbox/subfolder/newsgroup is selected.
Did a little more testing (linux 32bit & 64bit) and found that I can only replicate the issue if the view layout is in Wide View. I use this layout on all of my systems, which is most likely why I can replicate on all. 

When I switch to View|Layout|Classic View (or Vertical) the problem goes away. If I switch back to Wide View, the problem doesn't reliably appear the first time that I start SeaMonkey again, but does after the next restart & from then on.

@Ricardo: can you please test in Classic View as well?
I've just replicated in Thunderbird:
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120601 Thunderbird/13.0

To replicate (same in SeaMonkey)

1. Open Thunderbird.
2. View|Layout|Wide View
3. Before closing, switch to the view with no message pane (see: https://bug736811.bugzilla.mozilla.org/attachment.cgi?id=631240). You can do this by clicking on any account top folder (account name above Inbox, account name news server (same as in shown in 631240).
4. Close Thunderbird
5. Open Thunderbird. The view should be the same/similar as 631240; no blank message window & the right pane shows: 
Thunderbird Mail (or SeaMonkey Mail if testing w/SeaMonkey)
Accounts
Advanced Features
6. Click on an account 'Inbox' or news server newsgroup (mozilla.support.thunderbird).
7. Retest by setting View|Layout|Classic View. The issue should go away.

The cursor will automatically go to the blank message view window & as soon as you move the cursor out of the box (for any reason) the cursor will change to a drag & drop & you lose control of the cursor until Thunderbird/SeaMonkey is killed or exited (via Alt-F|Q.

Note 1: drop back to Thunderbird 12.1 & the problem disappears (same as when dropping back to SeaMonkey 12.x).
Note 2: no distro versions of SeaMonkey or Thunderbird are used in these tests. All versions are bz2's downloaded from Mozilla). All tests are run from a user home folder - example: ~/thunderbird ~/seamonkey.
Added note: Exactly like SeaMonkey, in Thunderbird 13, if I first select the menu Go|<account>|Inbox (or newsgroup), the cursor works normal from that point on.
(In reply to NoOp from comment #15)
> Did a little more testing (linux 32bit & 64bit) and found that I can only
> replicate the issue if the view layout is in Wide View. I use this layout on
> all of my systems, which is most likely why I can replicate on all. 
> 
> When I switch to View|Layout|Classic View (or Vertical) the problem goes
> away. If I switch back to Wide View, the problem doesn't reliably appear the
> first time that I start SeaMonkey again, but does after the next restart &
> from then on.
> 
> @Ricardo: can you please test in Classic View as well?


If I switch to Classic View and restart SeaMonkey in that view, I can't reproduce it. However, if I switch to Classic View from Wide View and try to cross boundaries without prior restarting SM, then I get stuck in the d&d pointer, already in Classic View.

I've also come to get the d&d pointer without moving the mouse itself, by following these steps:

- Open SM 2.10.1 or 2.12.a1, Mail window in wide view.
- Move the mouse pointer to the message preview pane, in a position close (but not touching) to the upper boundary.
- Choose an account (in my case, a blog & news feed account) and a folder using the keyboard ([F6] key and cursor keys).
- Select the first unread message pressing [n].
- Upon doing this, the message header should appear and the pointer should be on its area.
- The mouse should change to the d&d pointer.

There is a difference between the two versions, though: in SM 2.12a1 I can recover the normal pointer moving it to the menu bar and opening, for instance, the Help menu.
I can confirm the bug for SM 2.10 and SM trunk on Linux x86_64. I have determined the regression range with the help of my private archive to

hafi@i5_64 ~ $ fenster 1202070001-1202080020
2012-02-06 15:01:00 PDT
2012-02-07 15:20:00 PDT

Translation: Last good 2012-02-06 15:01:00 PDT
             First bad 2012-02-07 15:20:00 PDT

Additions to the above steps to reproduce:

2b. Uncheck under Preferences->Mail & Newsgroups
    [ ] When mail launches, show the Start Page in the message area
6b. Select a newsgroup in the folder pane. It is essential, that the position
    of the newsgroup in the folder pane is well below the separator on top
    of the message pane. Referred to attachment 631242 [details]
6c. The cursor is still on the old position, but this position lies now in the
    message pane. Move the cursor upwards with the mouse. When the cursor
    touches the separator, it changes to a Drag&Drop cursor. Also, the mouse
    buttons stop functioning.

This D&D cursor is adamant. It survives even switching to another workspace. SM has to be killed. This can be done with ^q.

I was tempted to set the importance of the bug to major, but there is a change of the behavior on trunk in this range:

hafi@i5_64 ~ $ fenster 1205040706-1205050814
2012-05-03 22:06:00 PDT
2012-05-04 23:14:00 PDT

SMs after the last date don't lose the functionality of the mouse buttons. To get rid of the D&D cursor it suffices to click with the left mouse button.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mouse occasionally changes to drag cursor without clicking any buttons → Mouse occasionally changes to drag cursor and the mouse buttons stop functioning
(In reply to Hartmut Figge from comment #19)
> I can confirm the bug for SM 2.10 and SM trunk on Linux x86_64. I have
> determined the regression range with the help of my private archive to
> 
> hafi@i5_64 ~ $ fenster 1202070001-1202080020
> 2012-02-06 15:01:00 PDT
> 2012-02-07 15:20:00 PDT
> 
> Translation: Last good 2012-02-06 15:01:00 PDT
>              First bad 2012-02-07 15:20:00 PDT

To be clear, self-built or our officially built?
Self-build with some private patches. The builds are automatically stored in folders with the name of the build-date, CET/CEST unfortunately, so have i have to convert them to PDT.
(In reply to Hartmut Figge from comment #21)
> Self-build with some private patches. The builds are automatically stored in
> folders with the name of the build-date, CET/CEST unfortunately, so have i
> have to convert them to PDT.

Given that, so I can correlate those dates to specific changesets can you test the nightlies from 2012-02-05->2012-02-08 at 
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2012/02/

And give me specific links to the nightlies you tested, along with GOOD/BAD ;-)
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #24)

In regard to the remaining problem with the D&D cursor on SM trunk with Linux/x86_64 after 2012-05-04 23:14:00 PDT:

> http://hg.mozilla.org/mozilla-central/rev/e4ea03a30a09

Backout does not help.

> http://hg.mozilla.org/mozilla-central/rev/34e3dad7a39d

Backout is possible but the compilation fails...

> http://hg.mozilla.org/mozilla-central/rev/31d649d2db25

...but the compilation succeeds when backing out this one simultaneously. No change to the problem with the D&D cursor, unfortunately.

Backing out all three chagesets together does not help either.
I missed that this belongs to bug 500081, too (and is in the time range):

http://hg.mozilla.org/mozilla-central/rev/050334f9128c
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #26)
> I missed that this belongs to bug 500081, too (and is in the time range):
> 
> http://hg.mozilla.org/mozilla-central/rev/050334f9128c

Backing out this one will be difficult.

patching file widget/gtk2/nsWindow.cpp
Hunk #1 FAILED at 295.
Hunk #2 FAILED at 1426.
Hunk #3 FAILED at 1904.
Hunk #4 FAILED at 1936.
Hunk #5 FAILED at 2762.
Hunk #6 succeeded at 4019 (offset -497 lines).
Hunk #7 succeeded at 4408 with fuzz 2 (offset -497 lines).
Hunk #8 FAILED at 4933.
6 out of 8 hunks FAILED

Because of the changes in the behavior since 2012-05-04 23:14:00 PDT this may even be hopefull. :)
It's not just the mouse dragging the cursor. I don't have a mouse. Just a mouse pad with right & left click... Sometimes, (especially when I get a lot of service interrupts){when you all are getting close to nailing criminal behavior} I CAN'T COMPLETE REPORTS WHICH POINT TO THE CREEPS. I point to something that I need to fill in and my cursor flies all by itself to the launch bar and opens whatever it runs into. Usually Libre apps and I have to wait for it to open and then close it before I can continue what I was trying to do.
Sorry I let the battery rundown...I had it unplugged in my home office. I had a chance to talk to a worker, who I want to join me. I'm starting a business.I'm going "Old School." I HAVE to.I have carbon paper for my contracts. I'm hand addressing promotional letters. I have the green sheets of accountants records. I thank God that this is just a nascent business. It's just me and a few good people,as unemployed as I am, who are willing to wait until I get some work. My record keeping is in REAL file cabinets and I'm still re-arranging these to flow for me. 
I could do so much more with a secure computer. Thank you for all the work that you do.
Help me Obi Wans, you're my only hope.
alicia...
I wanted to use Thunderbird, after Yahoo sold out. I attempted to set up accounts in Thunderbird, Seamonkey and mail.com. None completed and then I had no access. This was before you took this on. SO there are probably hanging pieces in the Netherworld. ALSO, in this message, If I leave the cursor on places I have typed, the cursor will move my typing to where it is. Just now, when I took it outside of this box, my typing stops showing on the screen.
alicia...
(In reply to Alicia Simonsson from comment #30)
> alicia...

With all due respect these 3 comments did not further the investigation/solution of this bug, and yours sounds like an entirely different issue, worthy of its own bug. If you have any further questions about my comment here (or how to file a new bug) you can e-mail me directly. (I am incapable of helping you solve it though).

Please do not comment here unless you are either fixing this bug, or helping to diagnose its cause/problem. Thank You.
(In reply to Hartmut Figge from comment #27)

[http://hg.mozilla.org/mozilla-central/rev/050334f9128c]
> Backing out this one will be difficult.

There is an obvious workaround for this. Hm, what is the recommended way for getting the Source of SM up to and including a given changeset from mozilla-central?

The dubious source i have tested includes 2b61af9d18ee which contains the hidden changeset 050334f9128c. The problem exists in the build and is gone after backing out 050334f9128c, so i strongly assume that 050334f9128c is the culprit for this bug.
(In reply to Hartmut Figge from comment #32)

> The dubious source i have tested includes 2b61af9d18ee which contains the
> hidden changeset 050334f9128c. The problem exists in the build and is gone
> after backing out 050334f9128c, so i strongly assume that 050334f9128c is
> the culprit for this bug.

Roc, Karl any advice in testing this further on our users end, in a way to gather enough data to find if this is a regression from your code there. Or any obvious ideas?  [Note its reproduceable much easier for these people with SeaMonkey/Thunderbird and not reliably reproduceable in Firefox]
Blocks: 500081
(In reply to NoOp from comment #16)
> 6b. Select a newsgroup in the folder pane. It is essential, that the position
>     of the newsgroup in the folder pane is well below the separator on top
>     of the message pane. Referred to attachment 631242 [details]
> 6c. The cursor is still on the old position, but this position lies now in
> the
>     message pane. Move the cursor upwards with the mouse. When the cursor
>     touches the separator, it changes to a Drag&Drop cursor. Also, the mouse
>     buttons stop functioning.

This is the key.

These are symptoms of bug 648477.  On button-down a drag gesture begins.  If
the panes change before the button up is received, the pane (or more
precisely, its ESM) doesn't get the button up event and so doesn't know that
the button up has happened.  When the cursor moves back into the pane (or
perhaps another pane with the same ESM), the ESM assumes that a drag gesture
has been continued and requests that a drag start.

A workaround might be to rearrange the panes after the button-up has been
received.  Perhaps using click instead of button-down might work.

What has changed since bug 500081 landed is that the widget code is no longer
ends the drag on the next mouse motion event.
(Details in bug 750061 comment 9.)

In Mozilla 13, bug 750061 still exists which causes a grab on the
mouse buttons.  A workaround, without closing or killing the app, is to use the
keyboard to open the menu and then Esc to close the menu.

In Mozilla 14, bug 750061 is fixed, but bug 648477 still exists.
The drag begins but is not ended on mouse motion.  A click or Esc is necessary
to end the drag.
Component: Untriaged → Event Handling
Depends on: 648477
Product: Firefox → Core
QA Contact: untriaged → events
(In reply to Karl Tomlinson (:karlt) from comment #34)
> (In reply to NoOp from comment #16)
> > 6b. Select a newsgroup in the folder pane. It is essential, that the position
> >     of the newsgroup in the folder pane is well below the separator on top
> >     of the message pane. Referred to attachment 631242 [details]
> > 6c. The cursor is still on the old position, but this position lies now in
> > the
> >     message pane. Move the cursor upwards with the mouse. When the cursor
> >     touches the separator, it changes to a Drag&Drop cursor. Also, the mouse
> >     buttons stop functioning.
> 
> This is the key.

Using FF 13.0 with NewsFox, Ubuntu 10.04, and it's happening with different positioning.  The feed list is the left side, article list right-top, and article right-bottom, with the top/bottom division below the lowest group in the feed list.  Cursor changes on some sort of click/wiggle behavior on the article's main link in the article pane.  Note that the link is not quite a mouse-pointer's width away from the pane boundary, but my hands don't shake *that* bad when clicking.

Still trying to nail it down...when I try, I can't reproduce it.  When I'm not trying, it happens pretty quick!
Upgraded to Seamonkey 2.10 on Slackware64 current today and it happened twice.

I have never seen this bug before today.

The cursor turns into a icon picture of a square document and then the only way out
is to either kill X (Ctl-Alt-Backspace) or kill Seamonkey from an alternate non-X terminal.
Ctrl-q should work. However you probably can still access the SeaMonkey menus using a combination of Alt-F and arrow keys to get around. At least that way you may be able to salvalge some work before closing.
I can confirm this is present on:

Pentadactyl hg6776 (created 2012/06/17 00:00:05) running on: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1

It seems to happen when a tab is grabbed and then a left click is made somewhere else on the screen quickly after (i.e. before the thumbnail of the tab disappears). I've been trying to come up with a workaround that uses xf86ungrab and a seamonkey/pentadactyl script. Will report back if I come up with anything else.
Additional info:

I can make it happen pretty reliably if I open Firefox with a single tab, grab said tab, drag it down, let the box disappear, grab said tab again (there will be no image or grab cursor present at this point), and then if I click somewhere on the screen, or open another tab, then the cursor switches to a grabbed state and I have to kill Firefox.

The situation seems to go away if I make a fresh profile. With all plugins and add-ons disabled (but no fresh profile) it is still present, so I believe that rules out an add-on or plugin being the cause.
I can confirm Wesley's finding with Firefox:
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0
and
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0.1

I cannot replicate in:
Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/16.0 Firefox/16.0a1

Wesley, can you try with Firefox nightly 16.0a1 and see if you can replicate with that version? http://nightly.mozilla.org/
NoOp: I cannot reproduce this on 16.0a1
@Wesley: Thanks. Now perhaps someone with Firefox can narrow down the change that fixes (?) it in 16.0a1.
Following up with SeaMonkey, I tested with:

Beta
<http://ftp-zlb.vips.scl3.mozilla.com/pub/mozilla.org//seamonkey/releases/2.11b2/linux-i686/en-US/seamonkey-2.11b2.tar.bz2>
Aurora
<http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-aurora/seamonkey-2.12a2.en-US.linux-i686.tar.bz2>
Nightly
<http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/seamonkey-2.13a1.en-US.linux-i686.tar.bz2>

With SeaMonkey 2.11b2 (Beta), I can "almost" replicate. Meaning that the cursor will turn into a D&D when moved from the blank msg window to the 'Subject' window, but if I click on an email subject (need to click twice), the cursor returns to normal. Works.

With SeaMonkey 2.12a2 (Aurora), I can "almost" replicate. Meaning that the cursor will turn into a D&D when moved from the blank msg window to the 'Subject' window, but if I click on an email subject (need to click twice), the cursor returns to normal. Works.

With SeaMonkey 2.13a1 (Nightly) is the same as 2.11b2, and 2.12a2. Works.

I'll run 2.11b2 on an regular profile for a day or so to see if the problem reappears. Can anyone else please verify my findings?
And posting now from a working:
Build identifier: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120612 Firefox/14.0 SeaMonkey/2.11

Note: I also backed down to SeaMonkey 2.11a2 and I can replicate. So the difference is somewhere between 2.11a2 and 2.11b2.
2.11b2 works in 64bit as well:
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120612 Firefox/14.0 SeaMonkey/2.11
To clarify: my testing with SeaMonkey in Comments 43, 44, and 45 were performed in the same manner as those in Comment #16.
Confirmed, this is happening in Thunderbird 13.0.1, Linux x86_64. Openbox 3.5 as the window manager here.

Can be reproduced as NoOp #16 pointed out (Wide View, click an account entry in the list, then a message folder, move mouse from the bottom pane into the list pane --> boom, permanent drag, but no drop possible)
I am not seeing this bug anymore with Linux Seamonkey 2.11 on Slackware current.
Hello,

I have just found your old bug report and want to ask you if this was happening to you in an actual Firefox Version?
I try to reproduce it on my site, but I was not able to do it.
maybe it was solved within another bug-report.

thanks for your help
Flags: needinfo?(linux.user.since.2002)
no feedback from reporter -> close the bug report

please reopen this bug report if you have new information to reproduce.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(linux.user.since.2002)
Resolution: --- → INVALID
WFM based on comment 49.
Resolution: INVALID → WORKSFORME
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: