Used Built: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020319(03) 1. open Composer (new composer page) 2. set any image into the page 3. mouse-double-click on image to open window "image properties" 4. mouseclick into image-location-url estimated result: cursor will be set to mouseclick-location actual reesult: it is impossible to place the cursor in 90% of tests often it will be possible after anoter activity in the "image properties"-window as for example open and close "advanced edit"
Probmel was also in mozilla 097, 098
This sounds familiar
Assignee: syd → cmanske
Keywords: nsbeta1, regression
Target Milestone: --- → mozilla1.0
I am also able to reproduce this problem. It should be noted though that the caret (cursor) is placed in the url field, it is just not visible. If after step 4, you try to type something, the text will show up. Reproduced on Win 98 and Win 2k both using the 03-25 trunk build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
If you can type, then it's a caret visibility problem in core, not UI.
Assignee: cmanske → kin
Component: Editor: Composer → Editor: Core
I can type - it is a visibility-problem.
nsbeta1-. Engineers are overloaded with higher priority bugs.
Keywords: nsbeta1 → nsbeta1-
Doesn't seem to be related to bug 133304, because I see the problem in Netscape 6.2.1, before the checkin that caused bug 133304
I looked at this in the debugger, and it seems that the caret is being turned off because there is a "disabled" attribute on the text widget. The attribute has no value, but it is set. cmanske said he thinks he knows what's causing it ... handing it back to him.
Assignee: kin → cmanske
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → ---
From discussion with Kin, this is probably an XBL problem for editable menulists. When the focus rect is set, it disables the embedded inputfield, which hides the caret. Bryner: Did you do this? Needs more detailed investigation.
Status: NEW → ASSIGNED
Keywords: nsbeta1- → nsbeta1
Target Milestone: --- → mozilla1.1alpha
No, I don't believe this is related to anything I've done.
still actual with Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020409(03)
Does not fit EDITORBASE criteria, but sounds like a good bug to fix in the trunk, so adding nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Whiteboard: EDITORBASE → EDITORBASE-
WFM on Win2k with nightlies but NOT on Linux
I did not have this problem for quite a lng time. Anyone who still has it with any OS? If not, I will close this bug.
I just tried this in my 06/28/02 Win32 debug build and the caret is not appearing when I click in the image-location-url textfield, though focus is being placed there. I can't remember if focus was truly placed in the text widget when I originally tested this bug, so I can't tell if this bug has slightly changed. In any case there is still a caret problem.
I've investigated this and can't pin down what's turning off the caret! The "disabled" attribute doesn't seem to be set, as kin mentioned in comment #9. The simplest way to reproduce this is to use the "Choose File" button. After selecting a file, we are returing focus to the input field by calling ".focus()" on the textbox. Focus is set, but caret doesn't reappear.
Summary: cursor cannot be placed in "Image Properties" window in Image-Location-Input → Caret disappears in location input field of "Image Properties" dialog
I tested the patch to bug 141888, which fixes this. It is a dup because we have a disabled textbox in the dialog when "Don't use alternate text" radio is checked. Thus it is the same cause. *** This bug has been marked as a duplicate of 141888 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.