Closed
Bug 246576
Opened 21 years ago
Closed 15 years ago
Caret invisible with onblur in input which focuses another input
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: martijn.martijn, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
410 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040611 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040611 Firefox/0.8.0+
See upcoming testcase.
In this testcase I have an <input type="text" onblur=".
In the onblur is code which focusses another text inputbox.
This causes the caret to become invisible, although you are to type.
Focussing another window/tab and then returnin makes the caret visible again.
Reproducible: Always
Steps to Reproduce:
1. Focus the first textbox
2. Focus the second textbox
3.
Actual Results:
No caret visible in the second textbox.
Expected Results:
The caret should be visible in the second textbox.
Reporter | ||
Comment 1•21 years ago
|
||
![]() |
||
Comment 3•21 years ago
|
||
*** Bug 275966 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 4•21 years ago
|
||
Aaron, Mats, any idea what's up here?
Updated•21 years ago
|
Summary: Caret invisible with onblur in input which focusses another input → Caret invisible with onblur in input which focuses another input
Comment 5•21 years ago
|
||
*** Bug 280734 has been marked as a duplicate of this bug. ***
Comment 6•20 years ago
|
||
Mozilla/5.0 (Windows; U; WinNT4.0; nl-NL; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
has the same bug.
Comment 7•20 years ago
|
||
I would guess this is fixed on trunk via bug 306320, which we decided not to take on branch because we didn't want to risk it.
Someone please test and see if this is a bug on trunk.
Reporter | ||
Comment 8•20 years ago
|
||
Er, Aaron, I think you meant a different bug there, but anyway, I can still see the bug with today's trunk build.
Comment 9•20 years ago
|
||
Argh, I meant bug 303620.
Comment 10•20 years ago
|
||
*** Bug 263873 has been marked as a duplicate of this bug. ***
Comment 11•20 years ago
|
||
*** Bug 322672 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 12•19 years ago
|
||
Not fixed by the patch for bug 287813.
Comment 13•18 years ago
|
||
The bug is still here (Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.10) Gecko/20070216 Firefox/1.5.0.10)
Comment 14•18 years ago
|
||
Still here and unforgotten...
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 ID:2007051502
Comment 15•17 years ago
|
||
FF 3.0b5 still has the same problem... :(
Comment 16•16 years ago
|
||
I'm not sure if this will help fixing the bug, but I've found this works as a workaround: call the focus in a timeout.
instead of:
function focusOther(){
document.getElementById("otherElement").focus();
}
use:
function focusOther(){
window.setTimeout(reallyFocus,1);
}
function reallyFocus()
{
document.getElementById("otherElement").focus();
}
Updated•16 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Comment 17•15 years ago
|
||
Works with 3.6
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•