619134 - alert() text doesn't have a context menu anymore

Status: NEW

(Toolkit :: Content Prompts, defect)

Description

[Dão Gottwald [:dao]]

Bug 613742 made it possible to select alerted text again and copy it with accel+c. However, you still can't select and/or copy it using the context menu.

Comment 1

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

Tempting to WONTFIX. I guess some people don't know Cmd/Ctrl+C...

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to comment #1)
> Tempting to WONTFIX. I guess some people don't know Cmd/Ctrl+C...

My parents are amazed when I can move files around in Windows Explorer without touching the mouse. Context menus are important.

Comment 3

[Marat Tanalin]

Ability to select all text by pressing Ctrl+A (standard shortcut equivalent to standard "Select all" item in context menu of any text field) is important as well.

Comment 4

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

(In reply to comment #2)
> My parents are amazed when I can move files around in Windows Explorer without
> touching the mouse. Context menus are important.

Yes, I know of the general importance of context menus. Copying text from an alert dialog is not a common user action, though, so I was just bemoaning the need to add code to support this.

Comment 5

[Marat Tanalin]

(In reply to comment #4)
> Copying text from an
> alert dialog is not a common user action

It's quite common as for bug reports (or any feedback that needs technical support) sent from users to employee of company or site's webmaster. For example:
— [support:] What message are you seeing?
— [user:] Message is "[smth. copied from alert dialog]"

Comment 6

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

I am also able to imagine scenarios where this feature is useful :) Let's not quibble over the meaning of "common". I don't think this bug needs more advocacy. Someone who wants to write a patch can base it on the existing commonDialog.xul code.

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Attachment: v1

I have no idea if this works (or even builds), but it looked like the right thing to do...

Comment 8

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

It's missing the context="contentAreaContextSet" at least.

Comment 9

[Dão Gottwald [:dao]]

This is anonymous content, it shouldn't use ids.

Comment 10

[Jake]

Alert information sometimes is important or you find it useful so that you want to make a copy, and sometimes you simply don't understand the meaning of it, you might want to copy and search it, and sometimes it contains error description you need to report...... these are just off the top of my head......

Comment 11

[Jake]

Most importantly we can copy from alert dialog before, this "bug" makes the new tab-modal much less tempting.

Comment 12

[Jake]

(In reply to comment #6)
> I am also able to imagine scenarios where this feature is useful :) Let's not
> quibble over the meaning of "common". I don't think this bug needs more
> advocacy. Someone who wants to write a patch can base it on the existing
> commonDialog.xul code.

Even if someone wrote a patch, would they accept it as official? if not, what's the point? everytime FF updates, you have to rewrite(at least remodify) it again, and only benefit few.

Comment 13

[Jake]

If a "patch" means an addon, it's another story, but to me it's crazy to install an addon just for a little adjustment. I would much perfer a userChrome js, question is "will it do the work?"

Comment 14

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

(In reply to comment #12)
> Even if someone wrote a patch, would they accept it as official?

Yes

Comment 15

[Jake]

What if the one who wrote the patch is a rookie, 20 lines can do the trick, but he wrote 100 and may contain latent bugs?
whatever the answer is, it's a bittersweet, if the don't care so much of the writer's qualification，it means this bug can be fixed faster, but......

Comment 16

[Jake]

The new tabmodalprompt still have problems, trigger an alert, stay for a while, this js will stop responding.
jar:file:///X:/core/omni.jar!/components/nsPrompter.js:463
and affects stylish
chrome://stylish/content/overlay.js:46

Comment 17

[Jake]

// If we can't do a tab modal prompt, fallback to using a window-modal dialog.
        const COMMON_DIALOG = "chrome://global/content/commonDialog.xul";
        const SELECT_DIALOG = "chrome://global/content/selectDialog.xul";
So it has nothing to do with commonDialog.xul

Comment 18

[Jake]

Could you please give it a ID or something, make it easier for others to write an addon or script to solve the problem.

Comment 19

[Jake]

I tried  deleting nsPrompter.js, not only didn't bring back the old prompt, but mouse justure didn't work anymore.
Maybe you guys shoud add an opption to about:config, leting people shoose what kind of prompt they want to use, since the new prompt is lack of basic function.

Comment 20

[Jake]

This "tabmodalprompt" only have a Local Name, doesn't have a ID, if I want to add a listener, how should I do it?
What I want to do is making it automaticly copy the letters you selected. the copy part is easy, but the "tabmodalprompt" is not a resident element and doesn't have a ID.

Comment 21

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

You should be able to only add <menupopup id="contentAreaContextMenu"> to the content directly (avoid the popupset), and use context="_child" on the content. Use |oncommand| rather than |command| for the menuitems, and omit the <command> elements. I think you also need to ensure that  chrome://global/content/globalOverlay.js is included, which could be somewhat annoying... you could load it via mozIJSSubScriptLoader, I guess, but I suppose ideally it'd be accessible via a JSM.

Comment 22

[Jake]

(In reply to comment #21)
> You should be able to only add <menupopup id="contentAreaContextMenu"> to the
> content directly (avoid the popupset), and use context="_child" on the content.
> Use |oncommand| rather than |command| for the menuitems, and omit the <command>
> elements. I think you also need to ensure that 
> chrome://global/content/globalOverlay.js is included, which could be somewhat
> annoying... you could load it via mozIJSSubScriptLoader, I guess, but I suppose
> ideally it'd be accessible via a JSM.

Thanks a million, although I don't care so much anymore, my solution is quitting using alert(), but using DOM creating my own "alert" window instead, this way you can copy it at will.

Comment 23

[Matthew N. [:MattN]]

Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.