caret not displayed for text inputs using style="text-align: right" on first click

VERIFIED FIXED in mozilla1.3beta

Status

()

Core
Editor
P1
major
VERIFIED FIXED
17 years ago
15 years ago

People

(Reporter: Christopher Aillon (sabbatical, not receiving bugmail), Assigned: mjudge)

Tracking

({access, topembed+})

Trunk
mozilla1.3beta
access, topembed+
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2] [ETA Needed], URL)

Attachments

(3 attachments)

See Attachment 14202 [details] from bug 50758

Clicking on one of the inputs with right aligned text (the top or bottom one)
will not display the blinking cursor.

This bug is an annoying one for any text inputs of this style and gives the
appearance that the form control is perhaps disabled or has an
onfocus="onblur()" thing going.

I searched for dupes but came up empty so I'm assuming this hasn't been reported
even though it has been alluded to in the more recent comments of 50578.

For the record, I am currently on linux 2001101608.
Fixing bug 50758 will likely fix this too
Depends on: 50758
Bug 50758 should probably be marked fixed.  I don't see the problem described
there but I do see this one.

Updated

17 years ago
Summary: cursor not displayed for text inputs using style="text-align: right" on first click → caret not displayed for text inputs using style="text-align: right" on first click

Comment 3

16 years ago
--> mjudge (selection/caret)
Assignee: kin → mjudge
*** Bug 114546 has been marked as a duplicate of this bug. ***

Comment 5

16 years ago
layout behaviour, there is no frame being aligned in the right spot for the 
caret. marking Future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 118659 has been marked as a duplicate of this bug. ***

Comment 7

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

Comment 8

16 years ago
We have seen this behavior as well. Although the Styles do not seem to make a
differance in what I see. On some of our JSP forms that are launched using a
JavaScript popupWindow((it just opens a new window to a certain size)) function
, the <INPUT type="text">  cannot be focused on with the cursor or edited. If I
do a view source on the page and then close the view source window and refresh
the window with the unfocusable fields.... they will then become focusable and
editable.

Comment 9

16 years ago
Comment #8 seems to be different to this bug. This bug relates only to the
cursor being invisible - the field is focusable and can be edited, but the
cursor is not displayed correctly.

Comment 10

16 years ago
Also seing this on Windows XP and Mac OS 9.
*** Bug 165745 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
We have a complaint from users in Japan that Epson Shopping
site's shopping cart page is very confusing because they cannot
see the cursor due to this bug. For fields indicating quantity 
of shopping items, aligning right should be a normal thing to do. 
Insuead of futuring this bug, we should fix this confuing bug
soon.
Changing OS to All. 
Try this page for the quantity field:

http://store.epson-supply.co.jp/query/qryfrm.asp?FrameSrc=qrylist.asp&action=query&GQ=true&PrdCls=3010000000
Severity: normal → major
OS: Linux → All
Keywords: access, nsbeta1

Comment 13

16 years ago
Created attachment 102792 [details]
Example to reprodoce bug with 3 Lines

this bug can be reproduced under Windows XP, Mac OSX and Suse Linux 8.1 with
Mozilla 1.2 alpha when the inputfield is empty and style is right-aligned.

The caret becomes visible when at least one character is in the inputfield.

Comment 14

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

Comment 16

16 years ago
As mentioned earlier, this bug appears on Macs too.
Please change Platform to All.

Prog.

Updated

16 years ago
Hardware: PC → All

Updated

16 years ago
Keywords: topembed

Comment 17

16 years ago
Marking as nsbeta1+/topembed+ as this effects a top site in Japan (see Comment #12).
Blocks: 178882
Keywords: nsbeta1, topembed → nsbeta1+, topembed+
Priority: -- → P1
Whiteboard: [adt2] [ETA Needed]
Target Milestone: Future → mozilla1.3beta

Comment 18

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

Comment 19

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

Updated

16 years ago
Attachment #106254 - Flags: review?(mjudge)

Updated

16 years ago
Attachment #106254 - Flags: superreview?(kin)

Comment 21

16 years ago
Created attachment 106850 [details] [diff] [review]
Alternate approach? (uses padding on internal div)

What do you guys think of this approach which basically enforces a 1px left and
right padding on the internal div which is the thing that does the actual
clipping inside the text widget?

Comment 22

15 years ago
Comment on attachment 106254 [details] [diff] [review]
Patch

Sring for kin.
Attachment #106254 - Flags: superreview?(kin) → superreview+

Comment 23

15 years ago
Comment on attachment 106254 [details] [diff] [review]
Patch

r=kin@netscape.com - if it's cool with sfraser, it's cool with me. :-)
Attachment #106254 - Flags: review?(mjudge) → review+
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
vrfy'd fixed with 2003.02.19.
Status: RESOLVED → VERIFIED

Comment 26

15 years ago
*** Bug 200253 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.