I have a web app with a popup window for entering data. I don't want to access the web every time this window is opened, as most of the app is AJAX. But I can't figure out how to open a new window and build it with DOM rather than having to provide a src. Even a blank.html as src takes time to fetch.
How can I create a popup and dynamically add DOM content without any html at all?
jonathon wrote: > How can I create a popup and dynamically add DOM content without any > html at all?
Unfortunately, you can't. When you open a window, it must have a url.
A work-around is to use the url of "about:blank", but this causes security warnings on secure sites, and doesn't work in some browsers. You can use a javascript: pseudo-protocol to write out dummy content, but this also throws up security warnings in some cases. You can leave a blank url, but only some browsers prefer this over about:blank.
This is, IMO, unfortunate. There should be a cross-browser way to pop up a new window and fill it with content without any security issues or problems.
If anyone knows of a solution, I would _love_ to know it.
I am not familiar with ajax, so I don't know if this is a plausible solution:
But the only other idea I would be able to think of is to actually make the "popup" as content inside a div element which is hidden. Then on some event you make it visible, and using z-index style you can then position it above the other content.
I don't know if this is an acceptable avenue to venture down, but it would be a possible way to mimic a "popup" without actually having to supply an url for a window.open();
The 'Reader()' function opens a popup without any src and write()'s content as a string to the new window. But my window is just a bit more complex than this one, and doesn't lend itself to this approach. Especially since it uses iframes.
Xandax wrote: > I am not familiar with ajax, so I don't know if this is a plausible > solution:
> But the only other idea I would be able to think of is to actually make > the "popup" as content inside a div element which is hidden. Then on > some event you make it visible, and using z-index style you can then > position it above the other content.
That's a possibility. A very good one, actually. I prefer the windows that seem to be part of the page rather than entirely separate anyway. I'll give that a shot.
> You can use a > javascript: pseudo-protocol to write out dummy content, but this also throws > up security warnings in some cases. You can leave a blank url, but only some > browsers prefer this over about:blank.
Again, about:blank is an unique domain name...
> This is, IMO, unfortunate. There should be a cross-browser way to pop up a > new window and fill it with content without any security issues or problems.
> I am not familiar with ajax, so I don't know if this is a plausible > solution:
> But the only other idea I would be able to think of is to actually make > the "popup" as content inside a div element which is hidden. Then on > some event you make it visible, and using z-index style you can then > position it above the other content.
http://www.netscape.com/ does almost that on a load event. The What's new box moves into the viewport for 10 sec. or so and then moves back into a negative top value. Click the yellow "What's new" button if you want to see it in action again..
> I don't know if this is an acceptable avenue to venture down, but it > would be a possible way to mimic a "popup" without actually having to > supply an url for a window.open();
Yeah, but it's as annoying as a popup actually. It's still the same too: unrequested content popping up, popping in the browser viewport. Netscape DevEdge had a article on how to bypass unrequested popups and Netscape was among the first to use it. It's sooooo stupid!
This example doesn't demonstrate your (incorrect) point. It opens a file called "PopupWindowOnlyImage.html" when it does window.open. It doesn't open a "blank" window with no contents.
>> This is, IMO, unfortunate. There should be a cross-browser way to >> pop up a new window and fill it with content without any security >> issues or problems. > Well, yes, there is.
Gérard Talbot wrote: > Xandax wrote : > > But the only other idea I would be able to think of is to actually make > > the "popup" as content inside a div element which is hidden. Then on > > some event you make it visible, and using z-index style you can then > > position it above the other content.
> Yeah, but it's as annoying as a popup actually. It's still the same too: > unrequested content popping up, popping in the browser viewport. > Netscape DevEdge had a article on how to bypass unrequested popups and > Netscape was among the first to use it. It's sooooo stupid!
But having given the link, I agree with Gérard. These divs implementing popups are a real annoyance because they cover content and you cannot be sure when you click on them what they will do (I'm thinking specifically of news sites that pop up one of these ads that cover content). Even if they eventually become well implemented to the point of having a nice fake title bar, and are draggable, etc. they will still make me suspicious because I don't know their standard functionality. That means, that a click on a good looking fake popup might actually be license for a real popup to be popped up. By the way, I just had a thought... since popup blockers generally don't block popups from user initiated actions, can you (a) accumulate a bunch of popups just based on a single action like a click (since it's actually a mouse down, mouse up, mouse click)? (b) delay the actual popping (sort of save up your popup popping credits and spew them all out at the end - possibly in conjunction with window.setTimeout)?. As opposed to another poster, I WANT to be able to move a popup so that it doesn't cover the parent window so I can read the entire parent window. The upshot: in general, I recommend against this route.
> Gérard Talbot wrote: > > Xandax wrote : > > > But the only other idea I would be able to think of is to actually make > > > the "popup" as content inside a div element which is hidden. Then on > > > some event you make it visible, and using z-index style you can then > > > position it above the other content.
<--snipped out for lenght -->
> I recommend against this route.
> Csaba Gabor from Vienna
Well - as with everything, it can be abused. But there are situations where such popups are justified, as well as ordinary popups. The reason that some mis-use popups due to advertisments, practically hijacking ones browser, doesn't mean such an avenue couldn't/shouldn't be explored. It is fully depending on what the situation the OP is in whether or not he should use such a "pseudo-popup" as descriped in my post.
I myself have used it in a project, when the user moves his mouse over a specific icon, some information about the product in question is shown. There it would be practically insane (in my view) to use "ordinary" popups, or even shift the entier layout of the page to show the notes somewhere "in-page". Likewise there are many other situations where such a popup can be useful, and perhaps even the optimal solution.
So is it with all technologies and techniques, that they can be misused, but that shouldn't stop legitiment usage of them either.
Xandax wrote: > I am not familiar with ajax, so I don't know if this is a plausible > solution:
> But the only other idea I would be able to think of is to actually make > the "popup" as content inside a div element which is hidden. Then on > some event you make it visible, and using z-index style you can then > position it above the other content.
This works great! It's a new iframe with an entry form. But I noticed some odd behavior. In Firefox on Win32, there is a little shimmer, or wiggle, when I move the mouse over the fields in the iframe. On FreeBSD, the blinking cursor never appears in the fields. You can edit, but you have to guess where the cursor is. I need to figure these out.
> I don't know if this is an acceptable avenue to venture down, but it > would be a possible way to mimic a "popup" without actually having to > supply an url for a window.open();
This isn't a popup in the advertising sense of the word. It's a pseudo-dialog box that's part of the application. That's the AJAX way.
> > Gérard Talbot wrote: > > > Xandax wrote : > > > > But the only other idea I would be able to think of is to actually make > > > > the "popup" as content inside a div element which is hidden. Then on > > > > some event you make it visible, and using z-index style you can then > > > > position it above the other content. > <--snipped out for lenght --> > > I recommend against this route.
> > Csaba Gabor from Vienna
> Well - as with everything, it can be abused.
Such as quoting, for example. I don't have any issues with what you wrote, but that quote from me above is incomplete and can be misconstrued. My read of what the OP was asking for was a modal dialog box (or at least a non modal one: a popup). And the OP expressed succinctly the main issue: he can't pop up an empty one cross browser and configure it. This is a heinous state of affairs and has bugged me for years. But even so, for the reasons I gave in my prior post, >> in general << I do recommend against them. And that in general means when they are used to simulate another window (popup). It amounts to whether one prefers the altered usability or whether one prefers to not support certain browsers.
At the same time, let me repeat that I don't have issues with what you wrote. Floating divs are extremely useful and I am using them quite a bit. Everywhere from tool tips (because some browsers fall down on providing multiline alt/title) to individual entries in family trees, to heirarchical menus. But I don't think of a floating div as a popup.
> But there are situations where such popups are justified, as well as > ordinary popups. > The reason that some mis-use popups due to advertisments, practically > hijacking ones browser, doesn't mean such an avenue couldn't/shouldn't > be explored. > It is fully depending on what the situation the OP is in whether or not > he should use such a "pseudo-popup" as descriped in my post.
> I myself have used it in a project, when the user moves his mouse over > a specific icon, some information about the product in question is > shown. There it would be practically insane (in my view) to use > "ordinary" popups, or even shift the entier layout of the page to show > the notes somewhere "in-page". > Likewise there are many other situations where such a popup can be > useful, and perhaps even the optimal solution.
> So is it with all technologies and techniques, that they can be > misused, but that shouldn't stop legitiment usage of them either.
> > > Gérard Talbot wrote: > > > > Xandax wrote : > > > > > But the only other idea I would be able to think of is to actually make > > > > > the "popup" as content inside a div element which is hidden. Then on > > > > > some event you make it visible, and using z-index style you can then > > > > > position it above the other content. > > <--snipped out for lenght --> > > > I recommend against this route.
> > > Csaba Gabor from Vienna
> > Well - as with everything, it can be abused.
> Such as quoting, for example. I don't have any issues with what you > wrote, but that quote from me above is incomplete and can be > misconstrued. My read of what the OP was asking for was a modal dialog > box (or at least a non modal one: a popup). And the OP expressed > succinctly the main issue: he can't pop up an empty one cross browser > and configure it. This is a heinous state of affairs and has bugged me > for years. But even so, for the reasons I gave in my prior post, >> in > general << I do recommend against them. And that in general means when > they are used to simulate another window (popup). It amounts to > whether one prefers the altered usability or whether one prefers to not > support certain browsers.
> At the same time, let me repeat that I don't have issues with what you > wrote. Floating divs are extremely useful and I am using them quite a > bit. Everywhere from tool tips (because some browsers fall down on > providing multiline alt/title) to individual entries in family trees, > to heirarchical menus. But I don't think of a floating div as a popup.
> Csaba Gabor
Ahh - I'm sorry. I misread your post. I hadn't noticed the link seperating the two quotes and thought your answer was to my post, because I hadn't noticed this seperation :o
Matt Kruse wrote: > jonathon wrote: > > How can I create a popup and dynamically add DOM content without any > > html at all?
> Unfortunately, you can't. When you open a window, it must have a url.
> A work-around is to use the url of "about:blank", but this causes security > warnings on secure sites, and doesn't work in some browsers. You can use a > javascript: pseudo-protocol to write out dummy content, but this also throws > up security warnings in some cases. You can leave a blank url, but only some > browsers prefer this over about:blank.
> This is, IMO, unfortunate. There should be a cross-browser way to pop up a > new window and fill it with content without any security issues or problems.
Yes, this state of affairs has bugged me for years and it has gotten worse. In particular, it is a perfectly reasonable thing to want to have a modal dialog box, especially in light of the fact that more and more we will be moving to internet based apps. And the OP is perfectly reasonable in not wanting another hit to the server - that's a waste. It's eminently clear that if javascript is running, then it could pretty well do whatever it wants to on the original page so what's the problem with letting it create and configure another page upon user action?
I've done some experimenting and find FF to be in a pretty sorry state on this point. The code below works fine on my (Win XP Pro) IE 6, but FF has some major issues (not that the javascript console says even Peep). If you run it with the alert line commented out, the button won't get placed. With the alert line there, it will be place. But this seems misguided at best, since the user has already clearly had to take action to get this far - what purpose does clicking the errant alert box serve?
<button id=btn1 accesskey=c onclick="window.setTimeout('dlgShow()',10)"> <u>C</u>lick me</button> <button accesskey=t onclick="window.setTimeout('dlgShow()',10)"> <u>T</u>ry me</button> <script type='text/javascript'> function dlgShow() { var nw=window.open("javascript:'<html><head><title>" + "Test</title><head><body>should be a button here </body>'");
> This example doesn't demonstrate your (incorrect) point. > It opens a file called "PopupWindowOnlyImage.html" when it does window.open. > It doesn't open a "blank" window with no contents.
You're right. It does not open a pure, virgin "about:blank" document. Updating via dynamically DOM-inserting an "about:blank" can not be done because of cross-domain security restrictions... but the PopupWindowOnlyImage.html document could be a blank document, could be a blank window with no contents, not a pure "about:blank" one though. The current PopupWindowOnlyImage.html contains only this: <body onload="buildImg();"></body>
so, I'd say it's pretty close to an empty document... It has script and style etc...
>>>How can I create a popup and dynamically add DOM content without any >>>html at all?
>>Unfortunately, you can't. When you open a window, it must have a url.
>>A work-around is to use the url of "about:blank", but this causes security >>warnings on secure sites, and doesn't work in some browsers. You can use a >>javascript: pseudo-protocol to write out dummy content, but this also throws >>up security warnings in some cases. You can leave a blank url, but only some >>browsers prefer this over about:blank.
>>This is, IMO, unfortunate. There should be a cross-browser way to pop up a >>new window and fill it with content without any security issues or problems.
> Yes, this state of affairs has bugged me for years and it has gotten > worse. In particular, it is a perfectly reasonable thing to want to > have a modal dialog box, especially in light of the fact that more and > more we will be moving to internet based apps. And the OP is perfectly > reasonable in not wanting another hit to the server - that's a waste. > It's eminently clear that if javascript is running, then it could > pretty well do whatever it wants to on the original page so what's the > problem with letting it create and configure another page upon user > action?
> I've done some experimenting and find FF to be in a pretty sorry state > on this point. The code below works fine on my (Win XP Pro) IE 6, but > FF has some major issues (not that the javascript console says even > Peep). If you run it with the alert line commented out, the button > won't get placed. With the alert line there, it will be place. But > this seems misguided at best, since the user has already clearly had to > take action to get this far - what purpose does clicking the errant > alert box serve?
> <button id=btn1 accesskey=c > onclick="window.setTimeout('dlgShow()',10)"> > <u>C</u>lick me</button> > <button accesskey=t > onclick="window.setTimeout('dlgShow()',10)"> > <u>T</u>ry me</button> > <script type='text/javascript'> > function dlgShow() { > var nw=window.open("javascript:'<html><head><title>" + > "Test</title><head><body>should be a button here </body>'");
> > <script type='text/javascript'> > > function dlgShow() { > > var nw=window.open("javascript:'<html><head><title>" + > > "Test</title><head><body>should be a button here </body>'");
Well, those two pages have NOTHING to do with the situation here. Those pages say don't put href="javascript:..." within a link. This situation has nothing to do with a link. The fact that we're using window.open at all guarantees that javascript is running, and the reason for using the javascript: is to return html that is to be used as page content (as opposed to having a string url which causes the browser to run out to the internet. That can mean a potentially huge delay, which is what started this whole thread off)
> I don't understand the purpose, reasons, justifications of setTimeout at > each of the 3 spots called in this code.
OK, this is a good point. I shouldn't have them there for the purposes of this discussion (and I should only have one button). But here's why they were there: If you put the alert back into the code, then the button appears as you would expect. However, on my system (where I embedded the whole page within a frame) using FF, I would get an intermittent error (I can't consistently reproduce it else I'd have already reported it to http://bugzilla.mozilla.org ) where after one button press, the button would no longer fire if it tried to execute the window.open. I tried putting in window.setTimeouts just in case (that why the first two were there), but that didn't work. The fix that actually worked was to reset the handler to its original function (which is why the third one was there - it's just a copy of the first button's event handler). Thus, the second button still failed from time to time.
Here's the code again, without the distracting setTimeout Csaba Gabor
<button id=btn1 accesskey=c onclick="dlgShow()"> <u>C</u>lick me</button> <script type='text/javascript'> function dlgShow() { var nw=window.open("javascript:'<html><head><title>" + "Test</title><head><body>should be a button here </body>'");
alert("Alert needed for FF"); // should not be needed
>>><script type='text/javascript'> >>>function dlgShow() { >>> var nw=window.open("javascript:'<html><head><title>" + >>> "Test</title><head><body>should be a button here </body>'");
> Well, those two pages have NOTHING to do with the situation here. > Those pages say don't put href="javascript:..." within a link. This > situation has nothing to do with a link.
Are you actually saying that you provided code which did not make use of href="javascript:..." within a link?
>>>// alert("Alert needed for FF");
>>> var btn = nw.document.createElement("button"); >>> btn.innerHTML = "Dialog <u>b</u>utton"
>>Validation error here too: unescaped /
> ???
Unescaped forward slashes in a script will trigger validation errors by the validator. That's what I meant.
>>You're right. It does not open a pure, virgin "about:blank" document.
> Ummm, that _was_ the point, you know :)
>>Updating via dynamically DOM-inserting an "about:blank" can not be >>done because of cross-domain security restrictions...
> That's not true either. You can popup an about:blank window and change it.
In which browser and browser version can you do that? about:blank is an unique domain name... With stricter security controls nowadays in browsers, I doubt this can remain forever...
Indeed, what browser is so bad as to not realize that it's only the <script> tag that must be closed here? But it is prudent to escape "</script>" when appearing in a javascript string because an unescaped "</script>" will be interpreted as closing the opening <script...> element.
Oops, in my script above, it should be </head> that follows </title>
Gérard, I assume your question was rhetorical - after all, did you see any <a> elements in my code?
> what purpose does clicking the errant alert box serve?
The line "window.open("javascript:'<html><head><title>" + "Test</title><head><body>should be a button here </body>'"); Opens a new window in another thread, the original thread continues but you cannot be sure that window is ready. The alert gives the other thread time to open the window and continue.
|
