Open
Bug 249583
Opened 20 years ago
Updated 2 years ago
Sometimes, keyboard/mouse events get sent to the wrong window
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
NEW
People
(Reporter: Biesinger, Unassigned)
Details
(Whiteboard: [security])
Attachments
(1 file)
326 bytes,
text/html
|
Details |
[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•20 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•20 years ago
|
||
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•20 years ago
|
Whiteboard: [security]
Reporter | ||
Comment 3•20 years ago
|
||
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.
Updated•15 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Assignee | ||
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•