Sometimes, keyboard/mouse events get sent to the wrong window

NEW
Unassigned

Status

()

Core
Event Handling
14 years ago
9 years ago

People

(Reporter: Biesinger, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [security])

Attachments

(1 attachment)

[linux, suse 9.1, kde with kde's window manager (KWin?)]

So, this happened twice to me over the last few days... _sometimes_, not sure
when, mouse and keyboard events get sent to the wrong window. For example, a
cursor blinks in a text input field, and the window looks active, but typing
just beeps - because typeaheadfind in a second window was triggered and a link
not found.

Or, hovering over buttons in one window shows no visible reaction, and clicking
the X to close the window closed _another_ window (this caused me to loose a
large bugzilla comment :( )


unfortunately this is hard to reproduce...

Comment 1

14 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040616

Testing Bug 249548 I crashed a trunk build so hardly that talkback didn´t come
up, DocWatson was frozen after doing the job, and I had to manually reset the
computer and reboot.
After reboot, I started Mozilla 1.7, and Mozilla 1.7 startpage came up, as I had
used my current profile, not the one reserved for 1.7. I bookmarked it as
suggested by dragging the icon to my preferred location, the last folder in the
personal toolbar.
I loaded a groupmark ( Buglist, tinderbox, checkins ), and bug 249548 from the
buglist.
I opened a new tab to load a https: site for testing.
Site loaded fine, I did reload, o.k. 
Tried to cut&paste, as the reporter told that happened on paste, but had some
dificulties.
I could reproduce: Select all didn´t select the stuff in the location bar, but
the whole selectable text in the first tab. Reproduced this to be sure, then
minimized browser, maximized, and couldn´t reproduce anymore.
As I´ve seen this behaviour for a long time, maybe over a year, I wanted to tell
you about my seeings.


Behaviour now, while writing this comment in the last tab, the 7th:
When I click on the preceding tab, a https: login waiting for input, 
the location bar gets selected. when clicking on the first tab, Mozilla 1.7
start page, and going back to the 6th, the previously selected loacation bar is
unselected. Going further to the 7th, the last tab, and back, the location bar
gets selected again, after about a tenth of a second, I´m on a slow celeron.
reproducible, even after minimizing and restoring the only window:
going from the first (Mozilla Start) to the 6th (https: login) tab, all is well,
going from any other tab (2 ..5, 7) to the sixth highlights the location bar.
Going from the sixth to the first, all is well, going from any other tab to the
first highlights the location bar.
maybe related (if buggy) prefs in user.js:
user_pref("browser.urlbar.clickSelectsAll", true);
user_pref("editor.singleLine.pasteNewlines", 3); 

I don´t know how to start that behaviour, but when it is seen, it is
reproducable, until the browser gets minimized and restored, or sometimes, if a
new tab gets loaded.

Comment 2

14 years ago
Created attachment 167539 [details]
testcase - steal input focus

testcase - works in Mozilla 1.7.3, doesn't work in Firefox 1.0. They probably
fix the problem of element in non-active page stealing focus.

Reporter (Christian), have you experienced this problem in recent
Firefox/Mozilla builds?

Updated

14 years ago
Whiteboard: [security]
in my case there were no malicious pages involved, I'm pretty sure... also, it
wouldn't explain the mouse events...

that said, I'm now using a different window manager... I do not see the problem
anymore, though.
Assignee: events → nobody
QA Contact: ian → events
You need to log in before you can comment on or make changes to this bug.