This is probably related to bug 153069. Short version: It's hard to position the text cursor before the first character of a text field, because the interior margins of the text field (including the shaded bevels) are not considered to be part of the text, although they *do* present an i-beam cursor, indicating that clicking should work. Right fix: Clicks to the left of text should be considered beginning-of-line clicks. Clicks to the right of text should be considered end-of-line clicks. Wrong fix: Turning off the i-beam cursor when over the margins. Having more places where clicks work rather than less is better. Long version: Go to a page with a text field on it. Move the mouse in and out it and watch the cursor change back and forth between an arrow and an i-beam. This shows you the extent of the text field itself, as opposed to the parent HTML document. Note that the rectangle that is "in" the text field (which has the i-beam cursor) includes the pixels that comprise the shaded border; and everything inside them. Position the mouse so that it is on top of, but to the left of center of, the first character in the text field. Click. This causes the text cursor to be positioned before the first character. So far so good. Position the text cursor elsewhere in the text field. Now position the mouse pointer as far left in the text field as you can, while still having the i-beam cursor. It will be right on top of the left shaded border. Click. The text cursor does not move, because that pixel -- though it is considered to be inside the text field, as indicated by the i-beam cursor, and by the fact that the text cursor does not stop blinking, as it would if you had clicked in the HTML -- seems not to be considered to be over the text. That's bogus. It should move the cursor.

when you say "text field", you mean the form input text box and/or a textarea, right? for me, clicking on the shaded are moves the cursor to the end of the text box

> when you say "text field", you mean the form input text box and/or a > textarea, right? Yes, I meant <input type=text> or <textarea> > for me, clicking on the shaded are moves the cursor to the end of the text box Ah, so it does! It always goes to the end, no matter where in the margin area you clicked.

-> HTML Form Controls

could be mjudge bug?

-->mjudge (selection)

*** Bug 212515 has been marked as a duplicate of this bug. ***

Here is a testcase to provide an example of the issue. One of the things I did find out, is that Example #2 occurs in Internet Explorer as well. It still seems like a bug to me, even if it does occur in IE, but perhaps there is a reason.

According to my testcase, there is no "unclickable" space. The cursor is simply placed in the wrong spot (as described in the testcase). Can someone confirm this? Also, this issue occurs in Windows. Propose changing OS -> All.

For comparison purposes, here is a testcase that is a little easier to use. It has an exaggerated border.

Here's the testcase. For comparison purposes, here is a testcase that is a little easier to use. It has an exaggerated border.

This seems to be working better in Mozilla 1.4 on Linux: items 1 thru 3.4 in testcase 2 are working as desired. The only difference I'm seeing is that clicks in the top border always move the cursor to beginning-of-line and clicks in the bottom border always move to end-of-line. Mozilla 1.4 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

The issues are still the same on the latest Win32 build (20030711). Based on your description, it would seem that the issue in Linux is slightly different. I don't suppose you have Windows to compare it with?

I do not, sorry.

*** Bug 214613 has been marked as a duplicate of this bug. ***

The border is not unclickable -- clicking there *does* focus the text field. It just puts the caret in the wrong place.

*** Bug 218644 has been marked as a duplicate of this bug. ***

*** Bug 145430 has been marked as a duplicate of this bug. ***

*** Bug 271325 has been marked as a duplicate of this bug. ***

I can't reproduce this bug with the testcase. Is this still an issue with current trunk builds?

Still broken for me, using a Mac trunk debug build from an hour ago. Clicking anywhere in the top border puts the caret at the beginning of the text field, and clicking anywhere in the bottom border puts the caret at the end.

Looking fine on Windows, though. Should this bug should be marked as fixed and a new bug filed for the one remaining Mac issue?

(In reply to comment #20) > Still broken for me, using a Mac trunk debug build from an hour ago. Clicking > anywhere in the top border puts the caret at the beginning of the text field, > and clicking anywhere in the bottom border puts the caret at the end. > The behavior on Mac is due to the setting of browser.drag_out_of_frame_style to "1" by default on Mac (setting it to "0" makes the behavior as on Windows/Linux). I doubt if this is a bug - seems to me like it's by design. In any event, this is not the behavior reported in this bug - which seems to be fixed.

I split the Mac bug into bug 343983. Marking this as WFM.