62880 - javascript prompt() does not select default text

Status: RESOLVED DUPLICATE of bug 28583

(Core :: XUL, defect, P4)

Description

[Tim Powell]

Using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001213.

The JavaScript window.prompt() function generates a dialog to get information
from the user. If default text is included in the call, it would be nice for the
text to be automatically selected when the dialog appears so that the user can
immediately type over it. This is very useful in bookmarklets, such as the
bugzilla bookmarklet.

The text is automatically selected in Netscape 4.x and IE 5, so Mozilla feels
less friendly here.

Comment 1

[Peter Trudelle]

->danm p4/moz101

Comment 2

[Azrael AOD]

Can't find a duplicate of this (doesn't mean one doesn't exist).
Marking NEW

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed patch

Comment 4

[Boris Zbarsky [:bzbarsky]]

Taking bug.

This patch will actually make all sorts of dialogs that only have one textfield
default to selecting that textfield.  ccing mpt for his thoughts, and requesting
review.

Comment 5

[John Morrison]

Seems reasonable to me, but whadda I know. Maybe you should ping alecf, blake
or ben for [s]r.

Comment 6

[Boris Zbarsky [:bzbarsky]]

ccing blake and alec.  What do you think of this change?

Comment 7

[Matthew T (active 1999-2002)]

It shouldn't apply just to those dialogs which have only one text field.

*** This bug has been marked as a duplicate of 28583 ***

Comment 8

[Boris Zbarsky [:bzbarsky]]

Er.  Right.  Except we're _not_ tabbing to the dialog; we're focusing it
programmatically.  Under those circumstances, will the fix to bug 28583 apply?

I would say that this one-line fix is worth getting in even if bug 28583 is not
fixed....

Comment 9

[Boris Zbarsky [:bzbarsky]]

mpt, does tabbing into a widget _always_ select its contents?  On all platforms?

The behavior asked for in this bug should be platform-independent, it seems to
me.....

Comment 10

[Boris Zbarsky [:bzbarsky]]

pushing out pending response from mpt...

Comment 11

[Matthew T (active 1999-2002)]

> Except we're _not_ tabbing to the dialog; we're focusing it programmatically.

See the 2000-12-26 23:40 comment in bug 28583.

> mpt, does tabbing into a widget _always_ select its contents?  On all
> platforms?

See the 2001-04-16 12:11 comment in bug 28583.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> See the 2000-12-26 23:40 comment in bug 28583.

Thank you.

> See the 2001-04-16 12:11 comment in bug 28583.

This implies that the code in bug 28583 will not select the text on Linux... In
my view, the text described in this bug should be selected on all platforms.

If I'm wrong about either of those, please feel free to re-dup the bug.

Comment 13

[Michael Coxon]

In fact, default text has a very severe length limit, and will not diplay any 
text with a newline character, except for the last line.

Comment 14

[Tim Powell]

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

Comment 15

[Sebastian Späth]

This will also fix bug 49574, marking as blocker

Comment 16

[Matthew T (active 1999-2002)]

> This implies that the code in bug 28583 will not select the text on Linux...
> In my view, the text described in this bug should be selected on all
> platforms.

Why? Surely that would hork the selection clipboard on X just like any other 
selection would. I still think this is a dup.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Keyboard selections don't hork the clipboard... just mouse ones do.  So there
should be a mechanism for selection without keyboard horkage.

That said, I think I've come to agree that this is a dup (and don't have the
time to deal with pushing this through even if it were not.  :) )

*** This bug has been marked as a duplicate of 28583 ***

Comment 18

[Tim Powell]

So does this mean the attached patch is just getting thrown away? I'd much
rather have some dialogs automatically do the default text selection than none,
<rant>especially if it means waiting another year until some progress is
made</rant>. Can't this minimal patch be checked in (assuming it still works)
until bug 28583 is fixed? Thanks for the work on this, Boris. I think I know
what you mean about not having the time to push this through.

Should bug 49574 be added to the block list for 28583? Or perhaps treated as a
dup? It seems identical to this bug.