Creating popup using DOM and *no* html src

J

jonathon

Hi all,

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?
 
M

Matt Kruse

jonathon said:
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.
 
X

Xandax

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();
 
J

jonathon

Xandax said:
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.
 
G

Gérard Talbot

Matt Kruse wrote :
Unfortunately, you can't.

Well, I disagree. E.g.:

Create a sub-window and dynamically DOM-insert an image
http://www.gtalbot.org/DHTMLSection/DynamicInsertionDOMImageInPopup.html
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.

It should not work on all browsers which apply correctly the
cross-domain script security restrictions:
http://www.mozilla.org/projects/security/components/same-origin.html
also explained at
http://developer.mozilla.org/en/docs/DOM:window.open#FAQ
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.

Well, yes, there is.

Gérard
 
G

Gérard Talbot

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.

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!

Gérard
 
C

Csaba Gabor

Gérard Talbot said:
Xandax wrote :
http://subimage.com/sublog/subModal

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.

Csaba Gabor from Vienna
 
X

Xandax

Csaba Gabor skrev:
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
 
J

jonathon

Xandax said:
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.
 
C

Csaba Gabor

Xandax said:
Csaba Gabor skrev:



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
 
X

Xandax

Csaba Gabor skrev:
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 :eek:

I appologize :)

-Xandax
 
C

Csaba Gabor

Matt said:
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>'");

// alert("Alert needed for FF");

var btn = nw.document.createElement("button");
btn.innerHTML = "Dialog <u>b</u>utton"
btn.accessKey = "b";
btn.onclick = function() {nw.alert("Dlg button clicked");}
nw.document.body.appendChild(btn);

document.getElementById('btn1').onclick =
function() {window.setTimeout('dlgShow()',10); }
}
</script>


Csaba Gabor from Vienna
 
G

Gérard Talbot

Matt Kruse wrote :
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...

Gérard
 
G

Gérard Talbot

Csaba Gabor wrote :
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 will trigger a validation error. Also, there is no need for
"javascript:" pseudo-protocol. Unless you're creating a bookmarklet, the
recourse to "javascript:" pseudo-protocol is always wrong, incorrect.
http://jibbering.com/faq/#FAQ4_24
http://developer.mozilla.org/en/doc...D.22javascript:window.open.28....29.22_....3E

// alert("Alert needed for FF");

var btn = nw.document.createElement("button");
btn.innerHTML = "Dialog <u>b</u>utton"

Validation error here too: unescaped /
btn.accessKey = "b";
btn.onclick = function() {nw.alert("Dlg button clicked");}
nw.document.body.appendChild(btn);

document.getElementById('btn1').onclick =
function() {window.setTimeout('dlgShow()',10); }


I don't understand the purpose, reasons, justifications of setTimeout at
each of the 3 spots called in this code.

Gérard
 
M

Matt Kruse

Gérard Talbot said:
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.
 
C

Csaba Gabor

Gérard Talbot said:
Csaba Gabor wrote :

This will trigger a validation error. Also, there is no need for
"javascript:" pseudo-protocol. Unless you're creating a bookmarklet, the
recourse to "javascript:" pseudo-protocol is always wrong, incorrect.
http://jibbering.com/faq/#FAQ4_24
http://developer.mozilla.org/en/doc...D.22javascript:window.open.28....29.22_....3E

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)
Validation error here too: unescaped /
???


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

var btn = nw.document.createElement("button");
btn.innerHTML = "Dialog <u>b</u>utton"
btn.accessKey = "b";
btn.onclick = function() {nw.alert("Dlg button clicked");}
nw.document.body.appendChild(btn);
}
</script>
 
G

Gérard Talbot

Csaba Gabor wrote :
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?

Unescaped forward slashes in a script will trigger validation errors by
the validator. That's what I meant.
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).

Thanks.

Gérard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top