620030 - New alert effect doesn't apply using uc js or addons

Status: RESOLVED WONTFIX

(Core :: General, defect)

Description

[Jake]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8) Gecko/20100101 Firefox/4.0b8

not too much to say here, just when we already have a better effect, why don't we use it globally? 

Reproducible: Always

Comment 1

[Rob Campbell [:rc] (:robcee)]

Not sure I understand what you mean by "uc js or addons", but I assume you're talking about the new non-modal alert dialogs. Moving to Firefox::General and cc'ing dolske.

Comment 2

[Jake]

http://userchromejs.mozdev.org/
most time uc js can carry out the same function as an addon, only simpler.
e.g. you can add a button to the status-bar

var myButton = document.createElement('statusbarpanel');
    myButton.setAttribute("id", "alertbutton");
    myButton.setAttribute("class", "statusbarpanel-iconic");
    myButton.setAttribute("label", "abc");
    myButton.setAttribute("image", "data:image/icon;....");
    myButton.setAttribute("tooltiptext", "123");
    myButton.setAttribute("onclick", "mybuttondo(event)");

 function mybuttondo(event) { 
   alert("why no effect?");
 }
I assume addons will be the same.

Comment 3

[Jake]

in page it works just fine.
data:text/html,<a href=javascript:alert("better");>alert Link</a>

Comment 4

[Jake]

Sorry, I forgot something.

var myButton = document.createElement('statusbarpanel');
    myButton.setAttribute("id", "alertbutton");
    myButton.setAttribute("class", "statusbarpanel-iconic");
    myButton.setAttribute("label", "abc");
    myButton.setAttribute("image", "data:image/icon;....");
    myButton.setAttribute("tooltiptext", "123");
    myButton.setAttribute("onclick", "mybuttondo(event)");
    document.getElementById("status-bar").appendChild(myButton);
 function mybuttondo(event) { 
   alert("why no effect?");
 }

Comment 5

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

This seems to boil down to "alert() dialogs displayed from a chrome window context aren't tab-modal prompts". That's because they aren't associated with a tab... we could have a chrome-window global stack for prompts and some more complicated logic when it comes down to search for somewhere to show the new-style prompt (getTabModalPrompt), I suppose, but there's not much benefit to that, particularly since throwing modal dialogs in chrome isn't exactly a recommended practice.

Comment 6

[Jake]

But it doesn't mean we can't do, just modify current tab's content if no other windows open. it's not difficult. If you think it's not necessary, please at least reomve the sound, it's very annoying, previous versions don't have the sound.

Comment 7

[Jake]

You can't openwindow or opendialog in a uc js, even if you write it as a xul, because you can't invoke this xul itself, therefor if you want to show some info you have to use alert(), if you want to get data from user you have to use prompt(), it's very frequently used, I see no reason why you don't want to give it a better look.

Comment 8

[Jake]

Actually there is a very popular addon called noscript, people using it will never encounter an alert during surfing, the only way they experience it is using a uc js. for them the effects are more terrible than before due to the annoying sound.

Comment 9

[Justin Dolske [:Dolske]]

If you addon/script wants to open a dialog as tab modal, it should use the content window's alert() method instead of the chrome window's alert(). Simple as that. [You can also open prompts through XPCOM via nsIPromptFactory, again using the content window for the window argument.]

Comment 10

[Jake]

(In reply to comment #9)
> If you addon/script wants to open a dialog as tab modal, it should use the
> content window's alert() method instead of the chrome window's alert(). Simple
> as that. [You can also open prompts through XPCOM via nsIPromptFactory, again
> using the content window for the window argument.]

Thanks, it worked. but still, I thinks an app should be consistent in any way, just like a person, if you look good here, but terrible there, makes people doubt your real quality.

Comment 11

[Jake]

I found a new problem, you can't copy (rightlick) in the new tab-modal prompts, sometimes people don't know the meaning of the information, they may want to copy and searth it, of course you can use control + c, but not everybody konws that.

Comment 12

[Jake]

You may say it's been made this way on purpose, because the contextmenu is inconsistent(you do care the consistency)with the "exquisite" look of the tab-modal, but I think conveniency should be your first concern, after all, you make an app for people to use other than just look.

Comment 13

[Rob Campbell [:rc] (:robcee)]

(In reply to comment #12)
> You may say it's been made this way on purpose, because the contextmenu is
> inconsistent(you do care the consistency)with the "exquisite" look of the
> tab-modal, but I think conveniency should be your first concern, after all, you
> make an app for people to use other than just look.

thanks for your comments. If you have an actual bug or feature enhancement please file it. This bug is closed.

Comment 14

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

Alerts not having context menus is bug 619134.