clicking border of text field misplaces caret

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
17 years ago
13 years ago

People

(Reporter: jwz, Assigned: mjudge)

Tracking

({testcase})

Trunk
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
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
(Reporter)

Comment 2

17 years ago
> 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.

Comment 3

17 years ago
-> HTML Form Controls
Assignee: sgehani → rods
Component: XP Apps → HTML Form Controls
QA Contact: paw → tpreston

Comment 4

17 years ago
could be mjudge bug?
Assignee: rods → kin

Comment 5

17 years ago
-->mjudge (selection)
Assignee: kin → mjudge

Comment 6

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

Comment 7

16 years ago
Created attachment 127627 [details]
Testcase: Example of Problem

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.

Comment 8

16 years ago
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.

Comment 9

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

Comment 10

16 years ago
Created attachment 127628 [details]
Testcase2: Example of Problem (easier to use)

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

has an exaggerated border.

Updated

16 years ago
Keywords: testcase
OS: Linux → All
(Reporter)

Comment 11

16 years ago
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

Comment 12

16 years ago
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?
(Reporter)

Comment 13

16 years ago
I do not, sorry.
*** Bug 214613 has been marked as a duplicate of this bug. ***

Comment 15

15 years ago
The border is not unclickable -- clicking there *does* focus the text field.  It
just puts the caret in the wrong place.
Summary: unclickable space near border of text fields → clicking border of text field misplaces caret
*** Bug 218644 has been marked as a duplicate of this bug. ***

Comment 17

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

Updated

15 years ago
Attachment #127627 - Attachment is obsolete: true
*** 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?

Comment 20

13 years ago
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.

Comment 21

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

Updated

13 years ago
Depends on: 338117
(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.

Updated

13 years ago
No longer depends on: 338117

Comment 23

13 years ago
I split the Mac bug into bug 343983.  Marking this as WFM.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.