From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020721 BuildID: 2002072104 If you type a URL into the URL bar, then open it in a new tab with Ctrl+T, the URL bar (correctly) loses focus, but the caret is left blinking in the URL bar, making it appear that the URL bar still has focus. Reproducible: Always Steps to Reproduce: 1. Type a URL into the URL bar. 2. Press Ctrl+T. 3. Notice how the caret is still blinking in the URL bar. 4. Try to type something. Actual Results: Text doesn't appear when you type in Step 4, even though it "looks like" it should do. Expected Results: The caret should not blink in the URL bar after Ctrl+T. (The behaviour where the URL bar loses focus is correct, it's just not reflected properly in the UI.) Workaround: To give the URL bar focus, click anywhere in the page, then click back in the URL bar. It now works correctly. ---- This bug is highly annoying, since anyone who uses tabbed browsing regularly will almost certainly have hit this bug. I am currently reproducing this bug in Windows XP, but I have also seen it occur in Linux.
I was able to reproduce this bug with my mozilla 1.1b build 2002072204,but step 2 should be "press Ctrl+Enter" because Ctrl+T just opens a new tab and Cltr+Enter opens the current typed url in a new tab.If you press Cltr+T the caret blinks and you can indeed type.But with Ctrl+Enter I get the same bug.
Yes, you're right. I meant to say 'Ctrl+Enter', not 'Ctrl+T'. Sorry.
I corrected the summary (Ctrl+T --> Ctrl+Enter) This bug possibly depends on bug 147077 or is a duplicate of it.
Summary: Caret still blinks in URL bar after Ctrl+T despite loss of focus → Caret still blinks in URL bar after Ctrl+Enter despite loss of focus
Since this behaviour is currently very counter-intuitive (I expect the cursor to be in the URL bar if the caret is there), any chance of a fix soon? For me, it is probably the most annoying bug I know of.
I noticed this bug occurs in other circumstances related to tabs as well, but couldn't find another reliable way to reproduce. Will try to find one...
Is this not a duplicate of bug 138963?
This does seem to be a dupe of bug 138963, although since this bug has a more meaningful summary (which explains the reasons for the situation, rather than a symptom), how about marking bug 138963 a dupe of this bug?
Under Mozilla 1.3, build id: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) The bug still persists. Also, if ctrl-l is keyed in at this point, no action is taken by the browser. The expected situation, ctrl-l, then type a url, places all typing in the current window, activating the type ahead feature. As opposed to the address bar.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.