window.showModalDialog missing/not implemented

[Bjorn]

Error: window.showModalDialog is not a function
Source File: http://www.jobsdb.com/HK/EN/V6/JS/Home/Home.asp?PN=JSHome&53016
Line: 113

1. Go to: http://www.jobsdb.com/HK/
2. Create an account and log in.
3. Click on any of the options

Expected behavior: a window/tab opening
Current behavior: nothing happens

I've seen this on other websites as well

[Pschwartau (pschwartau)]

---> DOM for consideration

[Alfonso (amla70)]

you can do it using dependent windows. The fact that IE doesn't support this
option is of course a bug in IE:

  window.open("test.html", "popup", "width=300,height=300,dependent=1");

[Jpatadia (jpatadia)]

Oh, interesting,

So in the below method : dependent=1 means that 1 is the id of the parent ? how
do I know what to use for dependent ?

Also the other thing, I really do not want to open a new window, even though it
might be modal on top of the other one, since I do not want to show the menubar,
titlebar, windowbar etc.

[Bzbarsky (bzbarsky)]

"dependent=1" should not work for untrusted content. In fact, untrusted
content should not ever be able to create a modal dialog like that.

[Alfonso (amla70)]

Jalpesh:
You should try the code that I posted, here is an example: attachment 115195
Dependent=1 is just the way that you want this feature in window.open, in fact
it should also work with just "dependent" (and maybe it is even the correct way).

Boris:
Do you mean that this is a bug?
I don't understand why it shouldn't work at least launching a URL in the same
domain.

[Jpatadia (jpatadia)]

I just tried the code in Mozilla 1.2.1.

Two Problems :

a) I still see the menubar when the window opens (with minimize/maximize/close
buttons). What I want is a dialog with just one item in the menubar (The "X")
for closing the dialog. Open the following link :

http://javascript.about.com/library/weekly/aa091001a.htm

Click on the "Try It" button in IE. You'll know what I'm talking about. (This
page does not use the showModalDialog, but some other logic - especially to see
the grey background, but the showModalDialog function would have simplified the
code a lot.)

b) The window which opens in the attachment, is not modal (at least not in
mozilla on linux). I can still interact with my main window without closing the
other one. So it's not really a modal dialog.

That's why the showModalDialog is such an attractive option - you can customize
what the user sees, since it takes a valid url as a parameter.

[Jst (jst)]

Mass-reassigning bugs to <email address hidden>

[Rvjanc (rvjanc)]

I don't know if this is of use or interest - if not just ignore.

I switched from Safari to Mozilla because of the much better support for
Javascript. Now, all the secure sites I use work except one (it uses the
showModalDialog method). I know there are other ways to do this; however, it
might be good to look at supporting some of these non W3C or ECMA constructs.

From a user's perspective it would seem that it might be useful to track these
MS unique constructs and append those that gain traction in the world to
Mozilla. Having been involved in SW since 1968 (no comments about age), I know
that much of the what the vendors of the day (DEC, IBM, ...) added to try to
lock in their customers, eventually made it into the "standard". It's very
frustrating to have to launch IE on my Mac to use one site.

[Swaters (swaters)]

Network Associates' Magic Service Desk Enterprise Edition seems to rely on it...
http://www.networkassociates.com/us/products/magic/home.asp

[Rvjanc (rvjanc)]

Since my comment of 10/28/03 I have run into two more sites that use the
showModalDialog method. Again, from a users' perspective, it is a real pain to
have to switch to IE for these sites.

[Ricardo Almeida (ric-almeida)]

I also believe this to be a major blocker for mozilla. Try to explain to my
father, who knows very little about computers, that mozilla is better than IE
but he still has to lauch IE to access is homebank account.
showModalDialog() is a de facto standard. If there is even a comment that says
it is that same that using window.open() with dependent=1, then the code to
support it is already, just need to change the parser so that when it finds the
showModalDialog() reacts the same way as parsing window.open() with dependent=1.

[Ricardo Almeida (ric-almeida)]

What about making use of the donation system? Like, this "bug" will be
immediately fixed if we get <i>some amount</i> of money...
I don't understand the mozilla code for sure but I think it's a easily solved "bug".
As stated in previous comment, in my own experience, this a blocker for mozilla
acceptance.

[Bzbarsky (bzbarsky)]

As I recall, we explicitly _removed_ the ability to create modal windows by
untrusted content. I'm not sure we want to be adding it in this guise, as I
said in comment 4.

[Ricardo Almeida (ric-almeida)]

(In reply to comment #13)
> we explicitly _removed_ the ability to create modal windows

Why? I don't understand...
What about a solution like the pop-ups. Modal windows are implemented, but
blocked for al sites. When a site tries to open a modal window an icon appears
at the bottom of the browser where a user can allow it for the given site (with
options such as: all pages within this server/all pages within this directory
(and subdirs)/just this page).

As I said, at least in Portugal, most homebanking sites use modal windows to
introduce the password, so how to you explain people like my dad that Mozilla is
great but to do homebanking he has to use IE?! He just uses IE and never has a
problem...

[Alfonso (amla70)]

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

[Danm-moz (danm-moz)]

Netscape has never allowed untrusted content to pose modal dialogs. (Though it
does allow alerts. Huh.) It's an ancient decision. Once, early on in Mozilla
development, modal windows were accidentally allowed and there was a big
scramble by everyone to get them turned the heck back off. To think otherwise
was to have your sanity questioned.

Personally there are three things I don't want my browser doing: installing
trojan horses, stabbing me in the eyes with a fork, and putting modal windows in
my face. Mozilla is pretty well behaved on all three accounts, and I like that.
That said, the main objection is unrequested modal windows. It's possible we
could subject them to the same controls as popup windows: simply disallow them
as best we can unless they're initiated by an explicit user action, like clicking.

Mozilla's popup control is imperfect. It would still be possible for an
unscrupulous site to hammer a browser with a string of modal dialogs. (Why? I
can't figure that out, either. But I'm living in 1997, there.) If we decide it's
a good idea, allowing untrusted content to pose modal windows, it should
probably wait for a fix for bug 237317. Even then I'd probably want a pref in
the same vein as dom.disable_window_open_feature allowing an advanced user to
turn them completely off.

I think it's a possibility. I've added a few more Mozilla gawds to the cc: list.

PS: most Portuguese banks (apparently) have bad UIs. Tell them I said so.

[Ricardo Almeida (ric-almeida)]

(In reply to comment #16)
> Netscape has never allowed untrusted content to pose modal dialogs.

Homebancking runs over https. Maybe showModal() should only be available for
https sites? What is trusted content?

> Personally there are three things I don't want my browser doing: installing
> trojan horses, stabbing me in the eyes with a fork, and putting modal windows
in my face.
I don't understand what modal windows have to do with horses and forks, but
showModal(), for all I care, could pop-up a window event if it isn't modal. I
don't care, I just won't my homebank to work on mozilla.

> That said, the main objection is unrequested modal windows. It's possible we
> could subject them to the same controls as popup windows: simply disallow them
> as best we can unless they're initiated by an explicit user action, like clicking.

Clicking, pressing enter, etc... That would be perfect.

> I think it's a possibility. I've added a few more Mozilla gawds to the cc: list.

Great :-)

> PS: most Portuguese banks (apparently) have bad UIs. Tell them I said so.

I know, they don't care. They don't even care about my option, and I'm their
customer... Most people use IE, it works with IE it's great for them :-(

[Timeless-bemail (timeless-bemail)]

no!

1. showModal should not be available <period>

2. evil sites can and do run https. heck, they'll sign jars if necessary.

3. now, making showModal* not trigger an error, and perhaps even provide the
info that the caller wants, i could live with.

[Danm-moz (danm-moz)]

> showModal should not be available <period>

Your flat refusal without reason given or response to my earlier comment
detailing its potential acceptability makes me want to ignore you.

[Rvjanc (rvjanc)]

This thread is taking on the look of a religious debate. As far as I'm aware the
following are true (willing to be corrected):

1 - Modal dialogs are generally considered poor from a usability standpoint.
However, there are many poor sites out there. One man's work of art is
another's garbage.

2 - Java script already has simple modal windows (alert, confirm and prompt)
that don't use a HTML source. So, your stuck in the mode until you click on "OK"
or "Cancel".

3 - The argument about a site sending you to another domain in the modal window
is weak. There are many sites out there (including secure ones) that do this.
This could be handled in the same way Mozilla currently handles popups with the
allowed sites option. Give the user the ability to select trusted sites that
use the showModalDialog method.

4 - Like it or not, IE and what it supports is the de facto standard for script
methods. So, in spite of religious convictions some banks in Portugal, my
online pharmacy, my online benefits site, and other sites use the
showmodaldialog method.

The internet and open source are about enabling the user to do it his/her way.
Given that I have not heard any sound security issues, give the users what they
want. Access to all sites using Mozilla.

[Brendan-mozilla (brendan-mozilla)]

I think now that we have whitelist-based popup controls, with good notification
when a site not whitelisted yet attempts a suppressed action, then we can allow
showModalDialog, for the big reason given here: compatibility with the mess that
IE has made of the web.

Purity of bodily fluids is not valid as a counterargument when Mozilla's market
share is as low as it is, unless you think Mozilla is a free lunch to which you
are entitled, or you're willing to be the last kook hacking on it, in a few years.

/be

[Danm-moz (danm-moz)]

There is widespread agreement that showModalDialog, despite the function's
horrible, lame-brained, unique syntax, would be a good thing to implement,
subject to restrictions as in comment 16. There is some dissent, but not from
any of several Mozilla principals I've asked. Besides, Brendan gets like 50
votes. So it's official, this is a desirable project.

[Micha-mschopman (micha-mschopman)]

So this would mean the Mozilla team agrees to implement this feature? If so..
hurray :)

[Jst (jst)]

Yeah, now we just need someone to do it. Dan, are you already on it?

I'd even like to see this in 1.7, but I think that's quite a stretch.

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

A few points:

1) Would these modal windows allow navigation within the window? (i.e. could the
modal window navigate from one URL to another before closing itself?)

2) A user can always close the modal window (with the close "X").

3) We need to make sure that it's perfectly obvious in the window title that
this is *not* a mozilla dialog, but an untrusted content popup. Something like
"Web application - <author's window title>" might be appropriate.

4) This is a major win for remote XUL, if done correctly. However, I'm vaguely
worried about remote XUL and menubars (mainly on mac)... actually, I don't know
what we do *now* with remote XUL and menus on mac, so I'm gonna go check.

[Rvjanc (rvjanc)]

A month or so ago there was a burst of exuberance to make this happen. Is this
on a "list" to get done? If so, is there a release targeted?

[James Ross (twpol)]

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

[David-ballantyne (david-ballantyne)]

How about implementing it so that by default the support for it is off and
that if you want it on, you specifically have to add the URL to the list of
sites allowed to use it? Its similar to the solution to POPUP windows, but
without the option of turning it off globablly.

I'm trying to convince my company to switch from IE to Firefox due to all the
holes IE has. Unfortunately certain pieces of software refuse to run and until
such a time they won't even consider it.

[Brendan-mozilla (brendan-mozilla)]

jst said this was his.

/be

[Dbeckham (dbeckham)]

Something that no one here has mentioned is that there are two functions it
seems. One originating from IE 4, I think, (showModalDialog) and the other
originating from IE 5+ (showModelessDialog). Someone might want to keep this in
mind.

[Micha-mschopman (micha-mschopman)]

(In reply to comment #30)

The thing that makes Modal Dialog so powerfull is the fact it is extremely
user friendly in a web application. You protect the user from clicking away
any tasks displayed in the dialog, and it makes web application so much more
powerfull and user centric.

Enabling the popup blocker for Modal Dialog effectively prevents any miss use
of the functionality.

[Jst (jst)]

(In reply to comment #30)
> Something that no one here has mentioned is that there are two functions it
> seems. One originating from IE 4, I think, (showModalDialog) and the other
> originating from IE 5+ (showModelessDialog). Someone might want to keep this in
> mind.

Good point.

[Danm-moz (danm-moz)]

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

[Philringnalda (philringnalda)]

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

[Rcecil (rcecil)]

(In reply to comment #34)
> *** Bug 272973 has been marked as a duplicate of this bug. ***

However the workaround seems to be a bug in Solaris/Linux versions of both
Mozilla 1.7 and 1.8 . Can some one at least make sure that the workaround works
on these platforms as well.

[Deanf (deanf)]

(In reply to comment #35)
> However the workaround seems to be a bug in Solaris/Linux versions of both
> Mozilla 1.7 and 1.8 . Can some one at least make sure that the workaround works
> on these platforms as well.
>

Roy, could you describe this workaround/bug? It does not seem to have been
covered in the previous discussion.
Dean

[Rcecil (rcecil)]

(In reply to comment #36)
> (In reply to comment #35)
> > However the workaround seems to be a bug in Solaris/Linux versions of both
> > Mozilla 1.7 and 1.8 . Can some one at least make sure that the workaround works
> > on these platforms as well.
> >
>
> Roy, could you describe this workaround/bug? It does not seem to have been
> covered in the previous discussion.
> Dean
>
>

Dean ,
 The workaround that I have been mentioning is
  window.open("test.html", "popup", "width=300,height=300,dependent=1");
 Also the given example
 https://bugzilla.mozilla.org/attachment.cgi?id=115195&action=view
 doesnt seem to work on Mozilla 1.7/1.8 on Linux and Solaris.
Thanks & Regards,
Roy

[Dznz (dznz)]

I find that nobody is if understanding. The thing is well simple, only wants to
have access the site: "http://cpd04.ufba.br/magictsd/" however the window to
logar is not appearing. After to talk with some programmers, was detected a
problem in the function: window.showModalDialog Summarizing: because mozila
firefox does not have access site:"http://cpd04.ufba.br/magictsd/"

Ezanazi <email address hidden>

[Ricardo Almeida (ric-almeida)]

(In reply to comment #37)
> https://bugzilla.mozilla.org/attachment.cgi?id=115195&action=view
> doesnt seem to work on Mozilla 1.7/1.8 on Linux and Solaris.

It's even worse, the workaround doesn't work in IE. Where I work we make
webpages to work on IE <period>. There is no discution. I wan't to change things
a little and make people code stuff that work in any browser. But the client
only uses IE, so stuff must work on IE...

I really don't understand what's so wrong in making the showModalDialog work. I
mean, if it is for security or so, why implement window.open? I can make an
infinite loop that opens "infinite" windows until the user has no memory...

There is lots of people wanting this particular feature. The feature already
existed, so it's just a matter of enabling it again.

Can someone explain why it isn't implemented? But explain me like I'm a 50 year
old, no knowlege in computer science, just wanting to access websites that use
the showModal for some reason (and there are lots of them).

Is it hard to understand that are people that don't use mozilla because of this?
The only thing they realize is that mozilla is broken. Trying to argument is
impossible. It's broken 'cause it works in IE.

[Dbeckham (dbeckham)]

I agree with this person. Mozilla needs this functionality to work with certain
types of websites, period.

The real problem here is that this is just not a priority to the people involved
who can actually implement the feature. It's a fact of life involving open
source software, but if the developers don't really need the feature themselves,
there is little incentive to actually spend the time writing the code. Outside
of hiring someone to write this, I'm not sure what could be done.

(In reply to comment #39)
>
> It's even worse, the workaround doesn't work in IE. Where I work we make
> webpages to work on IE <period>. There is no discution. I wan't to change things
> a little and make people code stuff that work in any browser. But the client
> only uses IE, so stuff must work on IE...
>
> I really don't understand what's so wrong in making the showModalDialog work. I
> mean, if it is for security or so, why implement window.open? I can make an
> infinite loop that opens "infinite" windows until the user has no memory...
>
> There is lots of people wanting this particular feature. The feature already
> existed, so it's just a matter of enabling it again.
>
> Can someone explain why it isn't implemented? But explain me like I'm a 50 year
> old, no knowlege in computer science, just wanting to access websites that use
> the showModal for some reason (and there are lots of them).
>
> Is it hard to understand that are people that don't use mozilla because of this?
> The only thing they realize is that mozilla is broken. Trying to argument is
> impossible. It's broken 'cause it works in IE.

[Danm-moz (danm-moz)]

I miss the days when bugzilla was a useful development tool, not a discussion
forum. We understand. Feel free to vote for the bug. Don't feel obligated to
explain your position as you might in a user forum. And for petesake don't feel
obligated to quote the previous comment.

[Jamil Ahmed (jamil)]

This bug is submitted on 2003 and now it is 2005!
Any update or target for this issue?

[Omi Azad (omi)]

From a long time I'm following this post, but as Jamil said that "This bug is
submitted on 2003 and now it is 2005! Any update or target for this issue?" I
need to say something. Are you really searious about the features of Mozilla or
you think other will finish the job. :) Actually when you said "Oh, interesting"
then it should be fixed on the next day. Please think about it...

[Omi Azad (omi)]

Seems FireFox people cannot produce this support. If you cannot then please let
us know. We can also un-subscribe from this issue and forget this.

[Omi Azad (omi)]

Friends, If you can then please delete the repeated posts above. I'm sorry, but
I didn't do it with my wills. My internet connection may have some problem and I
also got the repeat notice. But I told bugzilla to discard my post, but it didn't.

So please help me and I apologize for the inconvenience.

Omi

[Rvjanc (rvjanc)]

For those using a Mac running 10.3.x or 10.4.x, Safari 2.0.1 now supports
showModalDialog(). This has been my ONLY reason to hold onto IE.

My understanding (although rudimentary) is that Safari's JavaScriptCore is a
framework for Mac OS X that takes the cross-platform KJS library (part of the
KDE project), combines it with the PCRE regular expression library, and makes it
work with Mac OS X technologies. May be a way to facilitate adding this to FF.

Again, sorry if this is a dumb thought.

[Timeless-bemail (timeless-bemail)]

yes it's very silly. mozilla has its own javascript engine, and js engines have
*nothing* to do with this. this is entirely a dom issue. please leave this bug
alone. it is now unfortunately on a developer's plate along with many other
bugs. he'll drive it in when he can.

hopefully decent apis will be provided to embedders to supress and otherwise
annul this nonsense.

[Rkmohajan (rkmohajan)]

Mozilla at first support modal with this [i.e modal = yes in window.open param]
But after a time they removed this feature with the excuse of some security
issues..Now it cannot control its parent processes

I think we can create an Addon now for this to support showmodal feature in
Firefox

Between A point should be noted the gecko engine behaves differ in Linux and
Windows environment

Thanks
Ranju

[Fa-francoisauger (fa-francoisauger)]

It would be nice that, like the IE showModalDialog(...), the Firefox implementation stop the flow of JS. Consider in IE,

//JS snippet BEGIN
window.showModalDialog(...);
window.alert(...);
//JS snippet END

The alert will only fire after closing the dialog window. The window.open 'dependent' feature does not accomplish this.

Thanks,
François

[Reed Loden (reed)]

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

[Robinpelgrim (robinpelgrim)]

From the Mozilla developers homepage 'developer.mozilla.org' I click on 'AJAX' under Technologies.
There I read:
'Ajax: A New Approach to Web Applications'

But how am I supposed to design a real Web Application without de possibility of using a 'customizable' modal dialog??

Every application development for Mozilla Browser stops when a (IE) showModalDialog equivalent is not present (and so the only possibility is to use IE).

Why isn't this future not (re) implemented? For 3 years nothing has been done about it. Why not?

If it is a security issue than why isn't there an easy way to mark a site as trusted (and allow modal dialogs).
The reality is that more and more applications are built with HTML/Javascript (using AJAX...) and those applications mostly work on an intranet (and can be marked as trusted). Because it behaves like a 'normal' application it uses modal dialog windows (like Mozilla/Tools/Options)). But that can not be done with Mozilla's javascript/HTML ...

[Philringnalda (philringnalda)]

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

[Sciguyryan (sciguyryan)]

Its not in the W3C spec. as far as I know, should this be added as a compat bug?

[Robinpelgrim (robinpelgrim)]

(In reply to comment #56)
> Its not in the W3C spec. as far as I know, should this be added as a compat
> bug?

Of coarse it's a compat bug.
And it's the other way around. If mozilla will implement this it will probably become part of w3c. Till now there is no real modal dialog in FireFox, and till w3c comes up with a standard can better use the IE solution.

(XMLHttpRequest was long time no w3c standard either)

...

[Bjorn (bjorn-nostvold)]

A lot of Firefox newbs are going to assume Firefox is just broken when it doesn't support something like this. There's no point in trying to explain that the website is broken when it works in IE. I've tried this, and failed every time. I just tried with my wife and she's still blaming Firefox and wants me to install IE:Mac, "it works there, why not in Firefox?".

[Brendan-mozilla (brendan-mozilla)]

(In reply to comment #58)
Please, stop adding noise to this bug. It's assigned and it will be fixed. I'm nominating it for 1.9.

/be

[Dao (dao)]

(In reply to comment #21)
> I think now that we have whitelist-based popup controls, with good notification
> when a site not whitelisted yet attempts a suppressed action, then we can allow
> showModalDialog

(In reply to comment #28)
> How about implementing it so that by default the support for it is off and
> that if you want it on, you specifically have to add the URL to the list of
> sites allowed to use it? Its similar to the solution to POPUP windows, but
> without the option of turning it off globablly.

Contrary to popups, modal dialogs are expected to halt script execution.

[Bjorn (bjorn-nostvold)]

Error: window.showModalDialog is not a function
Source File: http://www.jobsdb.com/HK/EN/V6/JS/Home/Home.asp?PN=JSHome&53016
Line: 113

1. Go to: http://www.jobsdb.com/HK/
2. Create an account and log in.
3. Click on any of the options

Expected behavior: a window/tab opening
Current behavior: nothing happens

I've seen this on other websites as well

[Jeremy Teale (jteale)]

It's being worked on upstream.

[Robinpelgrim (robinpelgrim)]

Is there any activity on modal dialog support? I still can not migrate IE web application to Firefox (waiting for modal dialog support) ...

[Bugzilla-gtalbot (bugzilla-gtalbot)]

"has to lauch IE to access is homebank account." comment #11

"in Portugal, most homebanking sites use modal windows to
introduce the password" comment #14

"I just won't my homebank to work on mozilla" comment #17

Maybe a bug report in Tech evangelism bug should be created to try to do/achieve what
Blue Labs Software :: Financial Institutions and Mozilla Operability
http://blue-labs.org/rants/financial-shames.php
did a few years ago. Fixing bug 194404 will NOT necessarly fix bad webpage design, bad coding practices in banking webpages.

Bank webpages relying on "modal" windowFeature, showModalDialog() and showModelessDialog() methods are not serving at best their customers. A bank webpage does not need any of these methods to work, to serve their customers. A bank webpage should try to avoid resorting to secondary windows *_at all times_*.

If
"'modal' was never intended to be exposed to untrusted script." Dan M, bug
180048 comment #9
and/or if
"'dependent=1' should not work for untrusted content." B. Zbarsky, bug 194404
comment #4
then I don't see how showModalDialog() and showModelessDialog() should or could work for untrusted content/script ... and this is the case and the opposite for MSIE.

Bugzilla should fix bugs when it's the correct thing to do. Tech evangelism should be done when it's the correct thing to do. Fixing bugs should not replace or compensate tech evangelism efforts (or absence of these) when the correct thing to do is to evangelize banking webpages.

My 2 cents

[Brendan-mozilla (brendan-mozilla)]

I think IE has created a de-facto standard, which if you refrain from nit-picking the API details, is "just fine". We should support it. I'd like to see it supported for Firefox 3. jst, what would it take?

/be

[Jst (jst)]

I believe all the plumbing is there, shouldn't be way complicated to hook up, it'd be much like the XUL dialog opening code, though we probably want a XUL chrome wrapper around the HTML (whether its visible or not) in HTML dialogs for security UI purposes, popup blocker notifications, plugin notifications, etc...

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

We definitely want a chrome wrapper, if only to avoid security issues that dialogs loaded as a toplevel window have some additional privileges to open toplevel windows that we don't want to give to content sites.

[Jonas-sicking (jonas-sicking)]

There are security concerns with this since this feature lets you spin a new event queue (or whatever the equivalent is these days) and then execute arbitrary javascript there.

This is not to say that we shouldn't do this, but we shouldn't do it last minute, and we should be prepared to back it out if we don't have time to fix the issues.

[Jst (jst)]

Yes, that's true, but in theory that's trivial to deal with. If the opening code pushes a null context on the stack when the modal dialog is opened we should be in the exact same situation we're in right now. And from there on, any script that does execute in the modal dialog will push its context onto the stack and so on, as usually happens. Needs testing for sure, but should more or less just work.

[anonym (launch-mailinator)]

showModalDialog is an IE specific function.

http://blog.davidkaspar.com/archives/2005/10/showmodaldialog-in-firefox-and-frames.php

[Robinpelgrim (robinpelgrim)]

Why not as a first step add an option in the tools/options/content tab

'Allow modal dialogs' [Sites... ]

and allow modal dialogs for the sites you 'trust'.

The missing modal dialog is the only reason why I can not migrate our 'IE' web application to Firefox.

(I prefer Firefox, and I don't want to wait till FF4)

...

[Dao (dao)]

Is showModalDialog() considered to be tab-modal?
I remember there was a reason why alert() must block the whole window, but I can't recall it; so I don't know if that would apply here as well.

[Jsmith-doc-tor (jsmith-doc-tor)]

I have a web based medical practice management system. We've used little popup windows for years to display extra information about a particular bill or procedure. The users constantly lose track of these windows and forget to close them, but since it's just information, no big deal. Now I have to produce an auxillary pop up form to supplement the information on one line of a form containing hundreds of lines. Losing track of this pop up is a big deal. If the users are distracted and bring in some other application such as email, they'll bring back the parent window and forget all about the popup. I really need it be modal or at least stay on top of the referring form. I've been giving our customers the choice of uninstalling IE7 (helper apps don't work so good), reverting back to IE6, or installing firefox. Until this is implemented, now I'll have to tell them they're stuck with IE6. Solutions involving security certificates are unworkable. It should work the same as allowing popups from a particular site.

[Jonas-sicking (jonas-sicking)]

You should look at google calendar. It creates modal 'dialogs' in page by simply using html and css. Works fine in IE, Firefox, Safari and Opera, all recent versions.

[Jsmith-doc-tor (jsmith-doc-tor)]

(In reply to comment #71)
> You should look at google calendar. It creates modal 'dialogs' in page by
> simply using html and css. Works fine in IE, Firefox, Safari and Opera, all
> recent versions.
>
I researched this on the Internet before resorting to this website. I did come across the solution you mentioned. I also came across a couple dozen other solutions that may have worked at one time but now they don't. I'm sure the google calendar solution will also stop working sometime in the near future as the evangelists that are against web modal dialogs will close that loophole. Applications are moving from the desktop to the web in a big way now and these web applications need modal dialogs for the same reasons they were needed on the desktop. MS understands this and I have no problem telling my customers they have to use IE6, at least for this particular application. I think FF is an all around better browser and it just seems a shame my customers won't be able to use it.

[Bzbarsky (bzbarsky)]

Modal dialogs are bad for users because they block interaction with the browser UI. That's not a problem with the CSS approach, which only blocks interaction with your particular site. No one really cares what you do with your own site; it's blocking interaction with the rest of the browser that's bad. So I think you have no need to worry about the google calendar solution not working.

[Rvjanc (rvjanc)]

This is already in the pipeline to be addressed.

Also, this is bugzilla, not a FF forum. Boris Z, Jim S and Jonas S, if you want to debate this go to forums.mozillazine.org and click on Firefox Bugs.

[Dsicore (dsicore)]

Schrep, would you mind adding some notes as to why this is a blocker?

[Mtschrep (mtschrep)]

(In reply to comment #75)
> Schrep, would you mind adding some notes as to why this is a blocker?
>

Sure - we changed the behavior here for popup-blocking in FF2 and it has been a very common complaint of web authors looking to use modal dialog boxes:

http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/ca16846db5bb2b5

I've gotten multiple pings from different app groups looking for ways to do this. Yes there are workarounds via DIVs, etc. - but there doesn't seem to be any big objection to implementing as long as it obeys the popup-blocker and it would be a big help to web authors. Note Comment 59 and Comment 63 Brendan has been in favor of this. So before it is too late to take this kind of changes I'd like us to explore it...

I'm pasting an email discussion in here as well:

Johnny Stenback wrote:
> I've personally been wanting to implement showModalDialog() for years,
> just never got the time for it. Modal windows would be blocked by the
> popup blocker just like normal windows are, and would IMO not really
> make the popup situation noticeably different.

At that point we could also restore the "modal" option to window.open, right? It'd really be no different...

I think we should perhaps prevent modal popups any time a popup would be blocked, even if popup blocking is disabled (e.g. an open in popup conditions is forced to be nonmodal).

I think with that in place I'd be ok with doing modal stuff from content.

-Boris

[Jst (jst)]

Created an attachment (id=273876)
Implamentation of showModalDialog().

This adds an implementation of window.showModalDialog() to mozilla. It's a pretty simple implementation that doesn't attempt to go to the extremes of emulating all that IE does with modal dialogs (such as hiding context menus, forcing links to open in new windows, and probably a bunch of other stuff as well), but it gives web developers the ability to pose modal web dialogs from their apps.

[Jonas-sicking (jonas-sicking)]

(From update of attachment 273876)
>+nsGlobalWindow::ShowModalDialog(const nsAString& aURI, nsIVariant *aArgs,
>+ const nsAString& aOptions,
>+ nsIVariant **aRetVal)
>+{
>+ nsCOMPtr<nsIDOMWindow> dlgWin;
>+
>+ nsAutoString options(NS_LITERAL_STRING("modal=1,status=1"));
>+ nsAutoString dialogOptions(aOptions);
>+
>+ ConvertDialogOptions(dialogOptions, options);
>+
>+ options.AppendLiteral(",scrollbars=1,centerscreen=1,resizable=0");

So "scrollbars" or "resizeable" can appear twice. What will happen then? I guess it can appear any number of times if the same key appear multiple times in aOptions.

Should you have an nsAutoPopupStatePusher guard somewhere around here? And call EnsureReflowFlushAndPaint();?

looks good otherwise. r/sr=me

[Bzbarsky (bzbarsky)]

Fix the indent of the nsIVariant in the IDL?

The "No args" comment on the OpenInternal call should probably be adjusted.

Most important from my point of view: this functionality won't work in any embedded build (because it relies on nsXULWindow). Couldn't that code possibly live in window watcher? Or is the problem that this code needs to run before we create an inner window there? We should probably file a followup to fix for 1.9 to make this work without depending on our chrome code.

Oh, is it me or is the aCalleePrincipal argument something we could remove? Everyone seems to pass the same thing for it...

[Jst (jst)]

Filed bug 389634 on not depending on our chrome code for this.

aCalleePrincipal is still needed as OpenInternal() forwards to the outer whose principals could be different than that of the code calling open.

[Jst (jst)]

For the record, I misunderstood Sicking's review feedback and failed to act on it before checking in. I do need to deal with both those things, and in addition, I need to fire the DOM modal events etc around opening this modal content window. I'll follow up on that here after the tree is opened again.

[Jst (jst)]

Bug 389634 tracks the followup work I mentioned in comment 81. I filed bug 391455 for adding support for showModelessDialog() as well, and whether that will happen or not should be discussed in that bug, not here. I'm closing this bug as fixed.

[Alexander Sack (asac)]

upstream fixed this on trunk, so we will see the fix in firefox 3

[Bzbarsky (bzbarsky)]

Need regression tests so things like bug 391777 don't happen...

[Eshepherd (eshepherd)]

showModalDialog() is now documented:

http://developer.mozilla.org/en/docs/DOM:window.showModalDialog

Anybody have an example (or a testcase I can turn into an example) so I can add that to the doc and mark this as dev-doc-complete?

[Jst (jst)]

Created an attachment (id=282775)
Modal dialog for testcase.

[Jst (jst)]

Created an attachment (id=282776)
Testcase

Eric, feel free to base an example on the simple testcase I just attached.

[Eshepherd (eshepherd)]

OK, I've cloned that testcase onto MDC with only a couple of minor tweaks. Marking this bug as documentation complete.

[Nickolay Ponomarev (asqueella)]

It seems that showModelessDialog() wasn't implemented in this bug, changing summary. Should a follow-up be filed about that?

sheppy: The documentation doesn't mention the window.returnValue property that was added in this patch and it probably should. Also dialogArguments should also be marked as new in fx3. Not fixing it myself, since I should be sleeping already.

[Eshepherd (eshepherd)]

I've added returnValue to the DOM:window page, and tagged it and dialogArguments as new in Fx3. I have not added the subpages for either of them since I'm feeling lazy.

[Jst (jst)]

(In reply to comment #88)
> It seems that showModelessDialog() wasn't implemented in this bug, changing
> summary. Should a follow-up be filed about that?

See comment 82, it's already filed as bug 391455.

[Nickolay Ponomarev (asqueella)]

Thanks, sheppy and jst. Weird that I didn't find comment 82 by searching for "modeless", sorry about that...

[Jonathan Thomas (echidnaman)]

Firefox 3 has since been released.