When the URL box is clicked, the cursor does not always appear right away. This is non-standard behavior as far as text widgets go under Windows. Perfect Reproducing: Click on some HTML widget and watch the cursor blink. Wait until the cursor disappears and then click on the URL box right away. Actual Results: The cursor does not appear right away after the click, but "waits" until the next time it's supposed to blink. Expected Results: The cursor should appear right away after the click. Otherwise, the user may be confused whether or not the text box actually recieved focus and may repeatedly click on it until the cursor appears (aggravation).
Rewriting summary to indicate that the problem is the caret, not the cursor. ->xpapps, since this works in other text fields. confirming.
Assignee: trudelle → beppe
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets → Editor
Ever confirmed: true
QA Contact: jrgm → sujay
Summary: Cursor Misbehaving Upon URL Box Click → Caret doesn't appear immediately on clicking in URL bar.
Doh! really xpapps...
Assignee: beppe → don
Component: Editor → XP Apps
QA Contact: sujay → sairuh
Component: XP Apps → XP Apps: GUI Features
QA Contact: sairuh → claudius
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
This is a caret timing issue.
Assignee: vishy → anthonyd
Component: XP Apps: GUI Features → Editor
*** Bug 64167 has been marked as a duplicate of this bug. ***
Target Milestone: --- → mozilla0.9.1
move to mozilla1.0
Keywords: correctness, helpwanted
Target Milestone: mozilla0.9.1 → mozilla1.0
From the dup I filed: this happens in all XUL text fields in Modern, but doesn't happen in Classic or in HTML forms.
Summary: Caret doesn't appear immediately on clicking in URL bar. → [modern] Caret doesn't appear immediately on clicking in URL bar.
if this is a theme issue, should this go to hewitt?
there is no way a caret problem is a themes issue
this is a caret draw issue i think.
Status: NEW → ASSIGNED
*** Bug 94101 has been marked as a duplicate of this bug. ***
*** Bug 94420 has been marked as a duplicate of this bug. ***
QA Contact: claudius → sujay
Assignee: anthonyd → kin
Status: ASSIGNED → NEW
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1
Is this still an issue in current trunk builds?
Martin, I just tested it with  and it is still a problem. It seems that there is a "caret on" flag that is not getting reset to "on" upon clicking. Just to clarify -- this is the way native Windows widgets work. I just re-confirmed with Wordpad, IE6, Notepad, and Microsoft Word. This is also the way INPUT and TEXTAREA widgets appear to work within the HTML canvas.  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20060308 Firefox/22.214.171.124 - Build ID: 2006030804
Ilya, please test with the latest nightly trunk build: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk
Fixed! :) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Fixed by bug 287813?
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.