Closed
Bug 571919
Opened 16 years ago
Closed 9 years ago
After synchronic ajax request input control lose it focus
Categories
(Core :: DOM: Events, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: veaceslavbotnaru, Unassigned)
Details
Attachments
(1 file)
|
452 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
I checked all other browsers (IE, Crome, Safari) and the bug is reproducible only in FF.
Reproducible: Always
Steps to Reproduce:
1. Focus on input control type text
2. On keypres rise sync ajax request
3. Input control lose it focus
Actual Results:
input lose focus
Expected Results:
focus should remain on the same input control like in other browsers
focus should remain on the same control
|
||
Comment 1•15 years ago
|
||
Thanks for filing the bug! A small HTML testcase would be very helpful here. I think you could upload an HTML file that AJAXily requests its own location.href on keypress.
|
|
||
Updated•15 years ago
|
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → events
|
||
Comment 2•15 years ago
|
||
Testcase is definitely needed, since just starting sync XHR
doesn't move focus.
Try for example http://mozilla.pettay.fi/keypress_and_sync_xhr.html
|
|
||
Comment 3•15 years ago
|
||
Below is an example of a timer event taking focus. Try typing something long like the alphabet and notice that when typing during the timeout event the keys are lost.
<html>
<head>
<script>
function xhr() {
var x = new XMLHttpRequest();
x.open("GET", "cgi-bin/slowresponse.pl", false);
x.send();
var t=setTimeout("xhr()", 2000)
}
</script>
</head>
<body>
<script>
var t=setTimeout("xhr()", 2000)
</script>
<input type="text" />
</body>
</html>
slowresponse.pl:
#!/usr/bin/perl
print "Content-type: text/html\n\n";
sleep(1);
|
|
||
Comment 4•15 years ago
|
||
Here's a test case that uses its own URL for testing. This issue reproduces for me in nightlies.
|
|
||
Comment 5•15 years ago
|
||
Confirming. Apologies that it took me so long.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
||
Comment 6•15 years ago
|
||
Can reproduce on Linux.
|
|
||
Comment 7•15 years ago
|
||
Er, can't reproduce on Linux.
|
|
||
Comment 8•15 years ago
|
||
To be clear, I reproduced this on Mac. Comment #1 would seem to suggest that we have a similar problem on Windows.
OS: All → Mac OS X
|
|
||
Comment 9•15 years ago
|
||
I reproduced this on Ubuntu Natty 64-bit with Firefox 4.0.1 (4.0.1+build1+nobinonly-0ubuntu0.11.04.1) maintained by the Ubuntu Mozilla Team <ubuntu-mozillateam@lists.ubuntu.com>.
|
||
Comment 10•9 years ago
|
||
I can't reproduce this (neither with code based on the patch in comment 4 or the example in comment 3), on today's nightly on Linux, OSX 10.12, Windows 10, Windows 7, or Android (in E10S or non-E10S windows, as available). So given that's it has been six years, I'm closing as WORKSFORME.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•