60513 - alert(), prompt(), confirm() box text has static text (text not selectable)

Status: RESOLVED FIXED

(Core :: XUL, enhancement, P3)

Description

[Christopher W. Curtis]

While the alert is being displayed, it is not possible to highlight the error
message, for instance, to copy into a bug report.

Comment 1

[R.K.Aa.]

Is this bug valid at all?
I've never seen selectable alert-box text in any application.

Comment 2

[Christopher W. Curtis]

Well, when Gnome crashes the window presented has a hyperlink on it that sends
all sorts of basic info (platform, program, version) to a form, so there's
really no need to say 'nobody else does it...'  If it's a problem to do it, it
can be dropped - I reclassified it 'enhancement' to reflect this - but I've
always hated not being able to cut&paste error messages.  Furthermore, when a
Windows app crashes, the call stack (or whatever that is) appears in a subwindow
where it can be copied from.  And in my own experience, I'd rather someone send
me error text than a screenshot of an error, which is the only alternative if
you don't want to retype whatever message is being displayed, not to mention
that retyping can introduce its own errors such as transposed numbers.  Seems to
me to be simple and useful.  If it's not simple, mark it WONTFIX or let someone
else work on it, but please don't simply dismiss it.

Comment 3

[R.K.Aa.]

The Gnome window you refer to is the "Bug-buddy". The equivalent in Mozilla is
the QA Talkback. Talkback has various settings available, you can make it store
the talkbacks it send.

Is it the Talkback dialog-box/window you refer to in this bug, or alert-box'es
in general, throughout mozilla?

Comment 4

[Christopher W. Curtis]

I was specifically referring to just the Alert boxes, but was trying to show
similar things (problems the user should be aware of) where text could be
copied.

There is a bug in the IMAP code that presents invalid alert messages.  I wanted
to copy these messages for a bug report and was unable to.  In my own code, my
alerts contain useful information to me, as the developer, and I see no reason
to prevent the user from giving me this information easily.  Not allowing me to
highlight and copy the text makes this process difficult, for no good reason
(that I see).

Now, I could be talking completely out of my rearend here, but aren't these
things called "text-boxes" (selectable) and "labels" (non-selectable)?  The
message being displayed in an Alert isn't really a label, if that is the case,
it is a text message ... either way, it was just something that irked me and
which had no obvious reason except "that's how it's always been done", which
isn't much of a reason at all.  ;-)

Comment 5

[Peter Trudelle]

It would be an enhancement, but realistically it is never going to be a priority
for us.  It could still get done if it is trivial, or if someone else wanted to
do the work. ->future

Comment 6

[Jesse Ruderman]

Confirming as an enhancement and moving to all platforms.

Comment 7

[Daniel Wang]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Brian 'netdragon' Bober]

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

Comment 10

[Brian 'netdragon' Bober]

Daniel: Please provide the reason you dupe a bug. That is common bug etiquette.
This is not a dupe of bug 31655. Besides, bug 31655 is too general. From bug 31655:


Sebastian Späth wrote:
>You can already do this. Start Mozilla with the -console option. You will get a 
>DOS box with all the error and timing output. You can easily select and copy >it.
Says nothing about alert() just about general errors being trapped to the
console. Also, alert doesn't appear in the console on my Win32. 



> Do I need to do something more in oder to get the error-messages on the >console 
alert() not appearing on console should be another bug (if it is one).


I will fix this, it would not be harmful to make alert() text selectable.

trudelle: Mind if I take this?

Comment 11

[Brian 'netdragon' Bober]

prompt() and confirm() might be fixable with the same stroke of the magic wand.

I remembered about prompt() and confirm() from looking at bz's comments on bug
50348.

Comment 12

[Mats Palmgren (inactive)]

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

Comment 13

[u32858]

Could the priority on this be increased at all?  I think this would be a very
useful feature and currently there is not much chance of it being implemented.

JG

Comment 14

[Brian 'netdragon' Bober]

The priority is up to the person the bug is assigned to. If anyone is going to
work on this, they can take the bug (with Peter Trudelle's permission) and then
assign the priority to whatever they want. The priority is more for individuals
implementing the feature to prioritize, and isn't the priority mozilla.org sees
of the bugfix.

Comment 15

[Jesse Ruderman]

AIM for Windows lets you copy text from its alerts.

Comment 16

[Jesse Ruderman]

Mozilla's GTK alerts now allow selection, as per the Gnome HIG.  The fix was in
bug 231750.

Comment 17

[Brian 'netdragon' Bober]

Ok, please leave this open until its also on Windows and Mac.

Comment 18

[Prognathous]

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

Comment 19

[Erik Fabert]

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

Comment 20

[Martijn Wargers (dead)]

Attachment: patch

So something like this, I guess.
I had to use cursor: text !important in xul.css, otherwise the skin's formatting.css rule takes over, apparently. but maybe that rule should be in formatting.css anyway.

Comment 21

[Simon Bünzli]

Wouldn't the proper solution for this be to simply allow Ctrl+C to copy the alert/prompt's content (i.e. title, message and button text)? At least for Windows that would be the consistent (if hardly discoverable) solution.

OTOH a context menu wouldn't be more discoverable and would look almost as out of place as having the dialogs' messages as read-only text fields.

Comment 22

[Phil Ringnalda (:philor)]

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

Comment 23

[Ria Klaassen (not reading all bugmail)]

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

Comment 24

[Martijn Wargers (dead)]

(In reply to comment #21)
> Wouldn't the proper solution for this be to simply allow Ctrl+C to copy the
> alert/prompt's content (i.e. title, message and button text)? At least for
> Windows that would be the consistent (if hardly discoverable) solution.

I think that would be nice to have too.

Comment 25

[Ryan Flint [:rflint] (ping via IRC for reviews)]

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

Comment 26

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 212171 [details] [diff] [review]
patch

Sorry for the delay in getting to this (I noticed the patch is bitrotten due to bug 317334).

>Index: toolkit/content/xul.css

>+dialog vbox[id="info.box"] description {

Can you use #info\.box instead?

>+  -moz-user-focus: normal;
>+  -moz-user-select: text;
>+  cursor: text !important;
>+  white-space: -moz-pre-wrap;
>+}

There shouldn't be any element-specific style rules in xul.css. I think you should create a commonDialog.css (probably fine in /content for now) and move commonDialog.xul's inline style rules to it.

Other than that I think this looks fine, though I'm a little bit wary of changing all dialog boxes in this way, it could potentially cause any odd styling issues in some cases.

Comment 27

[(not reading, please use [e-mail] instead)]

very cool.  

I just noticed that safari has this for alerts (but IE 7 doesn't).  But it is very useful. 

Thanks for working on this, Martin (and Gavin).

Comment 28

[Martijn Wargers (dead)]

Attachment: patch2

Updated the patch with the suggestions in comment 26.

Comment 29

[Martijn Wargers (dead)]

Attachment: patch2, updated

Gavin, could you review this?

Comment 30

[Martijn Wargers (dead)]

Attachment: correct patch2, updated

Comment 31

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 283003 [details] [diff] [review]
correct patch2, updated

Sorry (again) for the delay here :(

This should probably get ui-review. Ask in #ux on IRC? It think we may want a separator between "Copy" and "Select all".

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 283003 [details] [diff] [review]
correct patch2, updated

Yeah, this is OK. I don't think we actually need the separator.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 283003 [details] [diff] [review]
correct patch2, updated

a1.9=dbaron

Comment 34

[Martijn Wargers (dead)]

Attachment: correct patch2, diffed against current trunk

This is what I'll be checking in.

Comment 35

[Martijn Wargers (dead)]

RCS file: /cvsroot/mozilla/toolkit/content/commonDialog.css,v
done
Checking in content/commonDialog.css;
/cvsroot/mozilla/toolkit/content/commonDialog.css,v  <--  commonDialog.css
initial revision: 1.1
done
Checking in content/commonDialog.xul;
/cvsroot/mozilla/toolkit/content/commonDialog.xul,v  <--  commonDialog.xul
new revision: 1.13; previous revision: 1.12
done
Checking in content/jar.mn;
/cvsroot/mozilla/toolkit/content/jar.mn,v  <--  jar.mn
new revision: 1.33; previous revision: 1.32
done
Checking in locales/en-US/chrome/global/commonDialog.dtd;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/global/commonDialog.dtd,v  <--  co
mmonDialog.dtd
new revision: 1.4; previous revision: 1.3
done

Checked into trunk.

Comment 36

[Martijn Wargers (dead)]

I'll try to make a litmus test for this.
But first I need to know in which sub-group I should create it.
This might become clear in the next MozQAE meeting.

Comment 37

[Biju]

looks like bug 50348 and bug 397258 also got fixed along with this.

Comment 38

[Andrew Schultz]

For dialogs with a textfield (like the master passsword dialog), focus is now on the dialog text rather than the textfield when the dialog comes up.  Is this "correct" behavior?  Do the individual dialogs need to be fixed to explicitly focus the textfield?

Comment 39

[Martijn Wargers (dead)]

That sounds like a bug, sorry about that.
Please file a new bug for that and make it blocking this bug?

Comment 40

[Daniel B.]

In what sense is this fixed?  When I use the Find command to search for
unfound text, in the resulting dialog box titled "Alert" and having a
message saying that your text was not found, that message text is not
selectable.

This is in SeaMonkey 1.1.2 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2)).

Comment 41

[Daniel B.]

(In reply to comment #1)
> Is this bug valid at all?
> I've never seen selectable alert-box text in any application.

There's a X Window System guideline that says such text should be
selectable.  

(Why shouldn't it be selectable?  One might want to copy the text to
paste in, say, a bug report or a narrative.)

Comment 42

[Martijn Wargers (dead)]

You need to use trunk builds (e.g. Firefox 3) instead of branch builds (Firefox 2) to be able to test this.

Comment 43

[Vincent Lefevre]

(In reply to comment #42)
> You need to use trunk builds (e.g. Firefox 3) instead of branch builds (Firefox
> 2) to be able to test this.

Now that the trunk is Firefox 4, this comment is no longer valid: while there were no problems with Firefox 3, text is again not selectable in Firefox 4. I've reported a new bug about this: bug 622416.