Sometimes (unable to work out on what circumstances) the address bar does not respond to keypresses, even though the cursor is flashing in the bar. Also Sometimes when editing text in a text box (mostly search boxes) presing Backspace will go back one page even though the cursor is in the box. When using Flash forms Backspace always works as back one page. Ian.
the flash thing is a separate and known bug...
Assignee: asa → alecf
Component: Browser-General → URL Bar
QA Contact: doronr → claudius
I've had this problem, it seems to be a kind of focus issue, reassigning to focus guru
Assignee: alecf → saari
We're looking for good test cases for any/all focus bugs. Most of these are "it happens in a particular phase of the moon". So if you see this, at least tell me what you were doing at the time.
About once a day it happens that a modal dialog pops up, but the main window still has the title bar active and each key-press and mouse click (no matter if in the main-window or the "inactive" modal dialog) results in a akustic "Ding" (Just as cklicking on a not-allowed window. Is this related to this bug too, or is this something completely different. Unfortunaly every time I try to reproduce the problem it won't show up again.... W2K. I had this problem since ~4 weeks
Confirmed on Windows 2000 2001043007 Been seeing this happen randomly in builds since around 25 April 2001. Had about 5 windows open, occured in window browsing www.mtnsms.com (although thats probably irrelevant since its happended haphazardly previously) 1. It affects only one of the open browser windows, the others respond fine. 2. Form elements also do not respond within the "frozen" window 3. Selecting other urls in the dropdown bar loads them as expected. 4. Back and Forward buttons navigate fine and pages are loaded 5. Links on the page work and are loaded
Status: UNCONFIRMED → NEW
Ever confirmed: true
P2, but we're probably going to need a reproducible case to fix this...
Priority: -- → P2
Ian: Does bug 30841 describe the problem you had ? (double-right clicking disables keyabord) If so, we can mark a duplicate.
No, it's not after double right clicking. I got it again soon after you suggested it may be a duplicate, and I had not double right clicked (don't think I had right clicked at all). But double left clicking seems to clear the problem...
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Ooh! I just came up with a repeatable way to reproduce this bug... ot at least as symptom of something that resembles this bug. Load any page. Pages that take longer to load are easyer to reproduce this on. click a link. Wait for the second page to load. Now hit the "back" button and as fast as you can, before the browser has time to finish going back, double-click in the address bar. (if you miss it, hit the "forward" button and try again) (The expected behavior when doing that is for the full url to be highlighted, but instead only the part of the url to the left of the cursor is visible.) Now try to use the arrow keys, or the home and end keys to move the cursor. No response. typing letters and numbers still works, and delete still works, but anything that moves the cursor is ignored. Can you reproduce this? Does this resemble the loss of keyboardage you where originally reporting about, Ian?
That sounds more like another bug we have right now on win32. Try deactivating and reactivating your window before you do this, and tell me if it still happens.
Status: NEW → ASSIGNED
Ah, yes, you are right. After I do that, switching to another window and then switching back unlocks my arrow keys. Whats the bug # for that one?
related to 84560 ?
Okay, so I'm looking for ways to reproduce this still. I've checked in some focus patches now that should help with some of these problems.
I've not seen this problem since I upgraded to 0.9 Ian
Pushing to 0.9.3. bryner is checking in more work that we did tonight on another case where this can happen, so hopefully it will be better at the very least, but I'm leaving open because I'm not convinced that it is 100% taken care of.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Allright, I think this is vastly better than before. However, I've learned to not say it is fixed... if you've seen this, or better yet if you have a reproduceable test case, chime in.
*** Bug 88434 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Marking as Fixed, reopen only with specific test cases
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.