Closed
Bug 355413
Opened 19 years ago
Closed 18 years ago
Bug with input boxes, javascript and caret position
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: martijn.martijn, Unassigned)
References
()
Details
(Keywords: regression, testcase)
Attachments
(1 file)
|
588 bytes,
text/html
|
Details |
This came from Hendrix:
http://groups.google.com/group/mozilla.feedback/browse_thread/thread/b2e15a2cac55408f/8c288c4589edf313#8c288c4589edf313
"
I'm doing this through here, since I have no idea how to submit a bug
properly into bugzilla.
So here is the thing:
A couple of months ago I made a website, which is now being tested, and
I get a lot of negative reactions about the login form, because the
caret isn't visible when you give the input boxes the focus.
The problem only occurs in Firefox, not in IE, not in Opera. And if I
remembered correctly (I don't have any other earlier versions installed
at the moment), the problem is only there since version 1.5, in 1.0 it
behaved correctly.
You can view the site over here:
http://dotnet22099.combell.net/RIS.Web/
I already made an minimal testcase of that, you can find it over here:
http://pieterhoste.be/firefox_bugs/caret_position_incorrect_when_hidi...
So, my question is if this is an already known bug, and if it is still
possible to fix before the release of Firefox 2.0?
Thanks a lot!
Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061002 BonEcho/2.0
"
I'll attach the testcase to the bug.
This regressed between 2005-06-28 and 2005-06-29:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-28+10&maxdate=2005-06-29+08&cvsroot=%2Fcvsroot
I think it might be a regression from bug 293504.
| Reporter | ||
Comment 1•19 years ago
|
||
Updated•19 years ago
|
Flags: blocking1.8.1.1?
Comment 2•19 years ago
|
||
not going to block 1.8.1.1 since this regressed well before 1.8
nominating for 1.9 though
Flags: blocking1.9?
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1-
Works for me on trunk. Anyone able to reproduce?
Minusing since it doesn't seem to be present on trunk; please renominate if that's not the case.
Flags: blocking1.9? → blocking1.9-
Comment 5•19 years ago
|
||
On trunk I see a different problem with the testcase: If you reload (but not shift-reload!) the page, the text disappears from the input box. Clicking the input box at this point has no visual effect, but typing any character reveals the hidden text. After doing this, I need to reload twice to produce the problem again.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a3pre) Gecko/20070308 Minefield/3.0a3pre
| Reporter | ||
Comment 6•19 years ago
|
||
I'm still seeing the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070309 Minefield/3.0a3pre
So renominating, because comment 4 said so.
Flags: blocking1.9- → blocking1.9?
I still don't see this on trunk, on Mac. Could it be Windows only? That would be surprising.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
| Reporter | ||
Comment 8•18 years ago
|
||
Worksforme with current trunk build with the testcase and url.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Updated•18 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in
before you can comment on or make changes to this bug.
Description
•