textfield.focus() doesn't show caret

RESOLVED DUPLICATE of bug 64170

Status

()

P1
normal
RESOLVED DUPLICATE of bug 64170
18 years ago
17 years ago

People

(Reporter: taras.tielkes, Assigned: kinmoz)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
When calling textfield.focus(), I would expect the caret to become visible, be 
it at the end, or at the beginning of the textfield contents.

What happens now is that the textfield does get focus, but the caret is places 
at an invisible position.(At the end of the text). This can be seen my giving 
the textfield a maximum width, and filling it with a long string. Then call 
focus(), and see : no caret.
(Reporter)

Comment 1

18 years ago
Created attachment 14275 [details]
HTML+Script testcase
(Reporter)

Comment 2

18 years ago
When loading the testcase, hold "LEFT ARROW" to let the cares scroll into view.
This demonstrates that the textfield has acquired focus.
(Reporter)

Comment 3

18 years ago
Also seen on Linux, changing to All/All
OS: Windows NT → All
Hardware: PC → All

Comment 4

18 years ago

*** This bug has been marked as a duplicate of 48400 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 5

18 years ago
Verified dupe of ->M19 bug 48400: "Using textfield.select() with empty contents
doesn't show caret (collapsed selection)"
Status: RESOLVED → VERIFIED
(Reporter)

Comment 6

17 years ago
This bug has been marked duplicate, and the one is has been marked dupe of has
been fixed. A number of related bugs have also been fixed, but it seems that
this still does not work in a simple HTML page.

The testcase will call focus() on a textfield after the page has been loaded,
but alas: no caret appears.

It seems to me this bug is the best candidate to reopen.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

Comment 7

17 years ago
reassigning to brade - not a sizing issue.
Assignee: rods → brade
Status: REOPENED → NEW

Comment 8

17 years ago
sounds like a focus issue... -->saari
Assignee: brade → saari

Comment 9

17 years ago
brade, the focus is there, but the text entry field isn't "scrolling" to show
the caret. That is an ender thing.
Assignee: saari → kin

Updated

17 years ago
QA Contact: ckritzer → moied
(Assignee)

Updated

17 years ago
Blocks: 108120
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla1.0
Moving to Mozilla1.1
Target Milestone: mozilla1.0 → mozilla1.1

Comment 11

17 years ago
2002042008 OS/2 trunk

Doesn't anyone use Google advanced groups search?
http://www.google.com/advanced_group_search?hl=en Every time I execute back to
this page after a previous search failed to turn up needed results, there is no
apparent focus anywhere. I click in the first box (with all the words), and no
cursor shows up. Only after clicking in another input field does the cursor
appear anywhere.
(Reporter)

Comment 12

17 years ago
Still seeing this with Mozilla 1.0 RC1

Comment 13

17 years ago
Ditto here with RC1.  In addition to the scenario reported by
mrmazda@atlantic.net, I find that even a 1st loading of 

http://www.google.com/advanced_group_search?hl=en

produces no cursor in the "with all the words" input field.  The cursor would
only appear if I use the mouse to click in ANY one of the other input field.

Updated

17 years ago
Keywords: nsbeta1+
Priority: P3 → P1
Whiteboard: [adt2]
Target Milestone: mozilla1.1alpha → mozilla1.0
(Assignee)

Comment 14

17 years ago
FYI, the problem seen at http://www.google.com/advanced_group_search?hl=en is
totally different from the original reported problem.

The google problem was due to the fact that the textwidget was given focus and
then DemoteForm() destroyed and recreated the frame tree so the caret was never
turned back on for the new textwidget frame. The google problem should be fixed
on the TRUNK with the removal of DemoteForm() (bug 90756)
nsbeta1-. More severe issue in this bug is fixed by patch for bug 90756.
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt2]
Target Milestone: mozilla1.0 → mozilla1.1alpha
(Reporter)

Comment 16

17 years ago
Still present in mozilla 1.1 alpha.
(Assignee)

Updated

17 years ago
Target Milestone: mozilla1.1alpha → Future
(Reporter)

Comment 17

17 years ago
Are you sure you want to future this one?

A textfield that doesn't show any indication of being active when in actually 
should seems a pretty stupid usability flaw.

Comment 18

17 years ago

*** This bug has been marked as a duplicate of 64170 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.