Javascript / browser / OS problem???

[Eric]

I have a user of a web application written in Java/JSP that is unable
to login to the site simply because certain links on the page do not
run when they are clicked. Other popups using Javascript on the same
page work correctly.

It appears to be isolated to 1-2 machines in a particular network. I
cannot verify whether these machines have had virus/spyware scans, but
I do know the user is running Firefox 2.1 and IE 7 with the same
problem in both browsers. I am not involved with their network setup
or PC setup.

A much paired-down version of the page works properly for this user.
But the fully coded page renders incorrectly and does not appear to
run any javascript. The window status bar always displays Done, on
mouse over of the links, whereas it normally would show the javascript
about to be run. I have tried to isolate certain sections of code,
with no success.

An <img...> tag in the HTML source is completely missing, and the JSP
code which contains it has no logic surrounding.

JSP
<td><img src="/images/login/photo.gif" width="250"
height="250"></td>
Page Source
<td></td>


I am wondering if this is a code issue, a browser issue, or an OS
issue. Of the many users of our software, this is the only one to
ever encounter such an issue.

 

[Adambrz]

I have a user of a web application written in Java/JSP that is unable
to login to the site simply because certain links on the page do not
run when they are clicked. Other popups using Javascript on the same
page work correctly.

It appears to be isolated to 1-2 machines in a particular network. I
cannot verify whether these machines have had virus/spyware scans, but
I do know the user is running Firefox 2.1 and IE 7 with the same
problem in both browsers. I am not involved with their network setup
or PC setup.

A much paired-down version of the page works properly for this user.
But the fully coded page renders incorrectly and does not appear to
run any javascript. The window status bar always displays Done, on
mouse over of the links, whereas it normally would show the javascript
about to be run. I have tried to isolate certain sections of code,
with no success.

An <img...> tag in the HTML source is completely missing, and the JSP
code which contains it has no logic surrounding.

JSP
<td><img src="/images/login/photo.gif" width="250"
height="250"></td>
Page Source
<td></td>

I am wondering if this is a code issue, a browser issue, or an OS
issue. Of the many users of our software, this is the only one to
ever encounter such an issue.

do you have other users with the same browsers running ok?

 

[Elegie]

Eric wrote:

Hi Eric,

A much paired-down version of the page works properly for this user.
But the fully coded page renders incorrectly and does not appear to
run any javascript. The window status bar always displays Done, on
mouse over of the links, whereas it normally would show the javascript
about to be run. I have tried to isolate certain sections of code,
with no success.

Instead of using IE's console, ask your user to open the Firefox
javascript console, clear it, load the page and report the errors - you
will get some much more detailed information. Also, carefully compare
the source produced by your faulty user with the expected source.

An <img...> tag in the HTML source is completely missing, and the JSP
code which contains it has no logic surrounding.

Then you definitely have a problem, either the page isn't delivered
properly (e.g, server error, proxy error), is modified on the client
prior to being displayed (e.g, popup blocker software, user scripts), or
fails due to some particular client setting (e.g, javascript deactivated).

Your approach to determining what goes wrong is absolutely correct, so
don't get too desperate and keep on, you'll eventually find what's the
problem.


Kind regards,
Elegie.

 

[Eric]

Eric wrote:

Hi Eric,


Instead of using IE's console, ask your user to open the Firefox
javascript console, clear it, load the page and report the errors - you
will get some much more detailed information. Also, carefully compare
the source produced by your faulty user with the expected source.


Then you definitely have a problem, either the page isn't delivered
properly (e.g, server error, proxy error), is modified on the client
prior to being displayed (e.g, popup blocker software, user scripts), or
fails due to some particular client setting (e.g, javascript deactivated).

Your approach to determining what goes wrong is absolutely correct, so
don't get too desperate and keep on, you'll eventually find what's the
problem.

Kind regards,
Elegie.

Thanks for the reply. I suspect this user has Symantec firewall or
internet security running, as I am seeing some javascript functions
(Sym*) in the source that is not mine, and other things are
reformatted and/or missing.

 

[Eric]

Thanks for the reply. I suspect this user has Symantec firewall or
internet security running, as I am seeing some javascript functions
(Sym*) in the source that is not mine, and other things are
reformatted and/or missing.- Hide quoted text -

- Show quoted text -

A desktop support user on the same network/PC setup confirmed the
problem being Symantec Client Security/Firewall. With firewall on,
page doesn't load fully/properly. With firewall off, page works
fine. Now they have to either disable firewall, or enter certain
sites as exceptions so that the software doesn't parse our code
incorrectly.

We are also sending the code and page source to Symantec to have them
explain themselves, should be interesting.

Hopefully this will help somebody in the future.

 

[Eric]

Thanks for the reply. I suspect this user has Symantec firewall or
internet security running, as I am seeing some javascript functions
(Sym*) in the source that is not mine, and other things are
reformatted and/or missing.- Hide quoted text -

- Show quoted text -

A desktop support user on the same PC setup confirmed the
problem being Symantec Client Security/Firewall. With firewall on,
page doesn't load fully/properly. With firewall off, page works fine.
Now they have to either disable firewall, or enter certain sites as
exceptions so that the software doesn't parse our code incorrectly.

We are also sending my code and the page source to Symantec to find
out
why they are doing this. That should be interesting.

 

[Elegie]

Eric wrote:

Hello,

A desktop support user on the same network/PC setup confirmed the
problem being Symantec Client Security/Firewall. With firewall on,
page doesn't load fully/properly. With firewall off, page works
fine. Now they have to either disable firewall, or enter certain
sites as exceptions so that the software doesn't parse our code
incorrectly.

Glad you found the problem, given its nature this should now be fairly
easy to solve.

We are also sending the code and page source to Symantec to have them
explain themselves, should be interesting.

I don't think you will get any answer though, after all that is just a
basic popup-blocking mechanism

There are basically two approaches a popup blocker software can adopt
for its product:

[1] It can inserts some generic script content inside every HTML page,
before the page is rendered by the browser. The inserted script
generally deactivates "window.open", among other things.

[2] It can monitors new browser instances and close the window
immediately. This is how built-in popup blockers work in popular user
agents (firefox, opera).

The thing is that popup blockers are well spread in the internet
community. Unless the product is aimed at a known environment (like an
intranet), it is generally advised not to use regular popups, for which
acceptable fallback often cannot be devised, and rather use some
DHTML-based system (with clean degradation).

If you want to learn more about popup-blocking, I recommend your
searching comp.lang.javascript archives, there were some truly
interesting discussions in the past.


Kind regards,
Elegie.

 

[Randy Webb]

Elegie said the following on 1/31/2007 4:17 PM:

[2] It can monitors new browser instances and close the window
immediately. This is how built-in popup blockers work in popular user
agents (firefox, opera).

I find it very difficult - nearly impossible - to believe that is how
"built-in popup blockers work" whereby it simply closes new windows.
That is *not* how they work. I never get a popup using any one of the
three browsers I use unless I explicitly tell it to give me a new window.

 

[Elegie]

[2] It can monitors new browser instances and close the window
immediately. This is how built-in popup blockers work in popular user
agents (firefox, opera).

I find it very difficult - nearly impossible - to believe that is how
"built-in popup blockers work" whereby it simply closes new windows.

Honestly, I absolutely do not know what strategies vendors of browsers
have deployed on their products, I was just using this as an example to
demonstrate the approach (since I usually tend to group into one
category built-in popup blockers with external software that do not
insert content to block the popup).

I realize that I should have been more precise (sorry for the
confusion), but didn't think that was needed as I was simply giving a
"hint".

That is *not* how they work.

Well, do *you* know how it really works? I mean, imagine your core
product with two millions of lines, and the boss that says "add some

I never get a popup using any one of the
three browsers I use unless I explicitly tell it to give me a new window.

That's because there's logic inside your browser that kills unwanted
popups, hopefully before any resource is allocated to create them,
determining what popups are unwanted, maybe using the way the popup is
created, maybe inferring a strategy from content in the called URL...


Regards,
Elegie.

 

[Eric]

[2] It can monitors new browser instances and close the window
immediately. This is how built-in popup blockers work in popular user
agents (firefox, opera).

I find it very difficult - nearly impossible - to believe that is how
"built-in popup blockers work" whereby it simply closes new windows.

Honestly, I absolutely do not know what strategies vendors of browsers
have deployed on their products, I was just using this as an example to
demonstrate the approach (since I usually tend to group into one
category built-in popup blockers with external software that do not
insert content to block the popup).

I realize that I should have been more precise (sorry for the
confusion), but didn't think that was needed as I was simply giving a
"hint".

That is *not* how they work.

Well, do *you* know how it really works? I mean, imagine your core
product with two millions of lines, and the boss that says "add some

I never get a popup using any one of the
three browsers I use unless I explicitly tell it to give me a new window.

That's because there's logic inside your browser that kills unwanted
popups, hopefully before any resource is allocated to create them,
determining what popups are unwanted, maybe using the way the popup is
created, maybe inferring a strategy from content in the called URL...

Regards,
Elegie.

The funny thing about all this.. the window.open javascript calls on
the page worked fine with Symantec firewall turned on. Links to
popups worked just fine, so I can't suspect the software is trying to
prevent ads. It was the normal href links and onclick javascripts
that weren't working. And not only was the software inserting
javascript into the page source near the top and bottom, but it was
completely reformatting my HTML. How else could you explain this???
An <img> tag is completely missing!

IE page source
<FORM name=UserLogin action=/ext/LoginEval?link_id= method=post>
<TABLE cellSpacing=0 cellPadding=0 width=800 align=center border=0>
<TBODY>
<TR>
<TD><IMG src="IE%20Login_files/black_knight_logo3.jpg"></TD></TR>
<TR>
....
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR>
<TD></TD>


JSP page source
<FORM name='UserLogin' action='/ext/LoginEval?link_id=<%=
request.getAttribute("R_link_id")%>' method='POST'>
<table width="800" border="0" align="center" cellpadding="0"
cellspacing="0">
<tr><td><img src="<%= hroot%>/<%= mfrid%>/images/<
%=sessionMgr.getMfr().getLogo()%>"></td></tr>
<tr>
....
<table width="100%" border="0" cellspacing="0"
cellpadding="0">
<tr>
<td><img src="<%= hroot%>/<%= mfrid%>/images/login/
photo.gif" width="250" height="250"></td>

 

[VK]

A desktop support user on the same PC setup confirmed the
problem being Symantec Client Security/Firewall. With firewall on,
page doesn't load fully/properly. With firewall off, page works fine.
Now they have to either disable firewall, or enter certain sites as
exceptions so that the software doesn't parse our code incorrectly.

We are also sending my code and the page source to Symantec to find
out
why they are doing this. That should be interesting.

I doubt very much that they stop software sells and make recall
worldwide :-(

<http://www.symantec.com/home_homeoffice/products/features.jsp?
pcid=is&pvid=npf2006>
By reading carefully all features of Norton (aka Symantec) Firewall
you may find the points you code is hitting to so you could change the
logic accordingly.
Both McAffee and Symantec/Norton are implementing for browser blocks
"pre-parsing content refactoring" and "environment maskoning". That
proves once over again that after brand is set strong enough, one can
sell any junk under this brand and users will mostly eat it and ask
for more...

"pre-parsing content refactoring" means that the source sent to UA's
parser is not equal to one received from the server. It will be
changed first in accordance to some "web-security rules" vairagrq ol
fbzr unvel chax jubf vqrnf bs frphevgl frrzf orvat yvzvgrq gb xrrc
unaqf qel juvyr znxvat n cvff.
My guess is that this is the corner you are hitting - but it's just a
guess.

"environment maskoning" means that, by some "web-security rules" of
the same origin as above, some native host methods are being shadowed
by maskons: custom methods hiding the real ones and imitating the
native behavior. In the most primitive form it is say:
window.Sym12345 = window.open;
window.open = new Function("return new Object;");
This way for your script window.open(URL) always "works" just fine,
but in the reality nothing happens. With all "security features"
activated an average scripts becomes like that guy from Matrix - it
"walks" and "talks" in its virtual existence, but in the reality it is
just floating in a gel - fed by pipes by maskon illusions.

Symantec/McAffee seems not only pushed this crap on the market, but
also made UA producers to believe that bypassing maskons is a security
threat. This way I only express my sorries for your current problems
in a _public_ Usenet post.


P.S. Sygate Personal Firewall is still my choice to advise to clients.
I mean the original 5.6 before they sold out to Symantec. From my
shampoo and software experience something making two things at
once oftenly does both bad. So it is better IMO to have shampoo and
conditioner by themselves so the same for firewall and antivirus.
<http://www.tucows.com/preview/213160>
<http://scan.sygate.com/home_homeoffice/sygate/index.jsp>

 

[Eric]

I doubt very much that they stop software sells and make recall
worldwide :-(

I can always hope....

 

[-Lost]

[2] It can monitors new browser instances and close the window immediately. This is
how built-in popup blockers work in popular user agents (firefox, opera).

I find it very difficult - nearly impossible - to believe that is how "built-in popup
blockers work" whereby it simply closes new windows.

Honestly, I absolutely do not know what strategies vendors of browsers have deployed on
their products, I was just using this as an example to demonstrate the approach (since I
usually tend to group into one category built-in popup blockers with external software
that do not insert content to block the popup).

I realize that I should have been more precise (sorry for the confusion), but didn't
think that was needed as I was simply giving a "hint".

That is *not* how they work.

Well, do *you* know how it really works? I mean, imagine your core product with two
millions of lines, and the boss that says "add some popup blocking mechanism"...

I never get a popup using any one of the three browsers I use unless I explicitly tell
it to give me a new window.

That's because there's logic inside your browser that kills unwanted popups, hopefully
before any resource is allocated to create them, determining what popups are unwanted,
maybe using the way the popup is created, maybe inferring a strategy from content in the
called URL...

Huh?

Anyway, check out Gérard's section on this topic (Firefox-specific, but informative
nonetheless).

http://www.gtalbot.org/FirefoxSection/

-Lost

 

[-Lost]

[2] It can monitors new browser instances and close the window
immediately. This is how built-in popup blockers work in popular user
agents (firefox, opera).

I find it very difficult - nearly impossible - to believe that is how
"built-in popup blockers work" whereby it simply closes new windows.

Honestly, I absolutely do not know what strategies vendors of browsers
have deployed on their products, I was just using this as an example to
demonstrate the approach (since I usually tend to group into one
category built-in popup blockers with external software that do not
insert content to block the popup).

I realize that I should have been more precise (sorry for the
confusion), but didn't think that was needed as I was simply giving a
"hint".

That is *not* how they work.

Well, do *you* know how it really works? I mean, imagine your core
product with two millions of lines, and the boss that says "add some

I never get a popup using any one of the
three browsers I use unless I explicitly tell it to give me a new window.

That's because there's logic inside your browser that kills unwanted
popups, hopefully before any resource is allocated to create them,
determining what popups are unwanted, maybe using the way the popup is
created, maybe inferring a strategy from content in the called URL...

Regards,
Elegie.

The funny thing about all this.. the window.open javascript calls on
the page worked fine with Symantec firewall turned on. Links to
popups worked just fine, so I can't suspect the software is trying to
prevent ads. It was the normal href links and onclick javascripts
that weren't working. And not only was the software inserting
javascript into the page source near the top and bottom, but it was
completely reformatting my HTML. How else could you explain this???
An <img> tag is completely missing!

<snip mangled markup>

All these new firewall "suites" pull this number, well, maybe not all. Symantec and
ZoneAlarm for example does it. ZoneAlarm affects both Opera and Internet Explorer for me.
That is why I like Firefox so much. I can control the JavaScript and privacy issues via
the browser rather than modifying the mobile code option in my firewall *every* time I
want to run some code.

-Lost

 

[Eric]

Randy Webb wrote:
[2] It can monitors new browser instances and close the window
immediately. This is how built-in popup blockers work in popular user
agents (firefox, opera).
I find it very difficult - nearly impossible - to believe that is how
"built-in popup blockers work" whereby it simply closes new windows.
Honestly, I absolutely do not know what strategies vendors of browsers
have deployed on their products, I was just using this as an example to
demonstrate the approach (since I usually tend to group into one
category built-in popup blockers with external software that do not
insert content to block the popup).
I realize that I should have been more precise (sorry for the
confusion), but didn't think that was needed as I was simply giving a
"hint".
That is *not* how they work.
Well, do *you* know how it really works? I mean, imagine your core
product with two millions of lines, and the boss that says "add some
popup blocking mechanism"... <kidding>
I never get a popup using any one of the
three browsers I use unless I explicitly tell it to give me a new window.
That's because there's logic inside your browser that kills unwanted
popups, hopefully before any resource is allocated to create them,
determining what popups are unwanted, maybe using the way the popup is
created, maybe inferring a strategy from content in the called URL...
Regards,
Elegie.

The funny thing about all this.. the window.open javascript calls on
the page worked fine with Symantec firewall turned on. Links to
popups worked just fine, so I can't suspect the software is trying to
prevent ads. It was the normal href links and onclick javascripts
that weren't working. And not only was the software inserting
javascript into the page source near the top and bottom, but it was
completely reformatting my HTML. How else could you explain this???
An <img> tag is completely missing!

<snip mangled markup>

All these new firewall "suites" pull this number, well, maybe not all. Symantec and
ZoneAlarm for example does it. ZoneAlarm affects both Opera and Internet Explorer for me.
That is why I like Firefox so much. I can control the JavaScript and privacy issues via
the browser rather than modifying the mobile code option in my firewall *every* time I
want to run some code.

-Lost- Hide quoted text -

- Show quoted text -

In my situation, Firefox page source was being altered and rendered
useless as well by Symantec Firewall.

And my biggest complaint with Firefox/Netscape are that they ignore
HTML/CSS parameters that IE handles, simple things such as width on a
<div> tag, or a hand cursor on mouseover of a link. Those things make
our website look very unprofessional.

 

[-Lost]

Randy Webb wrote:
[2] It can monitors new browser instances and close the window
immediately. This is how built-in popup blockers work in popular user
agents (firefox, opera).

I find it very difficult - nearly impossible - to believe that is how
"built-in popup blockers work" whereby it simply closes new windows.

Honestly, I absolutely do not know what strategies vendors of browsers
have deployed on their products, I was just using this as an example to
demonstrate the approach (since I usually tend to group into one
category built-in popup blockers with external software that do not
insert content to block the popup).

I realize that I should have been more precise (sorry for the
confusion), but didn't think that was needed as I was simply giving a
"hint".

That is *not* how they work.

Well, do *you* know how it really works? I mean, imagine your core
product with two millions of lines, and the boss that says "add some
popup blocking mechanism"... <kidding>

I never get a popup using any one of the
three browsers I use unless I explicitly tell it to give me a new window.

That's because there's logic inside your browser that kills unwanted
popups, hopefully before any resource is allocated to create them,
determining what popups are unwanted, maybe using the way the popup is
created, maybe inferring a strategy from content in the called URL...

The funny thing about all this.. the window.open javascript calls on
the page worked fine with Symantec firewall turned on. Links to
popups worked just fine, so I can't suspect the software is trying to
prevent ads. It was the normal href links and onclick javascripts
that weren't working. And not only was the software inserting
javascript into the page source near the top and bottom, but it was
completely reformatting my HTML. How else could you explain this???
An <img> tag is completely missing!

<snip mangled markup>

All these new firewall "suites" pull this number, well, maybe not all. Symantec and
ZoneAlarm for example does it. ZoneAlarm affects both Opera and Internet Explorer for
me.
That is why I like Firefox so much. I can control the JavaScript and privacy issues
via
the browser rather than modifying the mobile code option in my firewall *every* time I
want to run some code.

In my situation, Firefox page source was being altered and rendered
useless as well by Symantec Firewall.

In ZoneAlarm I can disable the mobile code insertion junk it puts in. However, I have to
turn it *all* off before it stops putting its code in the markup. That is:

Block JavaScript
Block scripts (VBScript, et cetera)
Block embedded objects (Java, ActiveX)
Block mime-type integrated objects (which always kills Flash for instance)

Something else I experienced with Symantec that *really* plagued me is when I set up a
security camera system for a local daycare. The camera system hosted its own server
available via TCP/IP (Ethernet).

Symantec however, no matter what I tried, including shutting it down and uninstalling, it
kept blocking the Java (and the ActiveX option). Only uninstalling it *and* changing the
security settings in Internet Explorer to allow the content worked.

Pretty sad though, I have no clue what to tell Symantec users other than "make sure you
allow domain.com for blocked content." You would be surprised at how many times they say,
"Huh?"

And my biggest complaint with Firefox/Netscape are that they ignore
HTML/CSS parameters that IE handles, simple things such as width on a
<div> tag, or a hand cursor on mouseover of a link. Those things make
our website look very unprofessional.

Um... am I understanding you correctly? This is a bit off-topic, but:

<div style="width: 100px; border: 1px solid #000;">styled DIV</div>

There is no width attribute for a DIV in HTML.

<a href="" style="cursor: hand;">styled link</a>

....which is pointless as that is the default in most browsers.

Both of those items are recognized by Firefox. Did I misunderstand?

-Lost

 

[Eric]

Randy Webb wrote:
[2] It can monitors new browser instances and close the window
immediately. This is how built-in popup blockers work in popular user
agents (firefox, opera).
I find it very difficult - nearly impossible - to believe that is how
"built-in popup blockers work" whereby it simply closes new windows.
Honestly, I absolutely do not know what strategies vendors of browsers
have deployed on their products, I was just using this as an example to
demonstrate the approach (since I usually tend to group into one
category built-in popup blockers with external software that do not
insert content to block the popup).
I realize that I should have been more precise (sorry for the
confusion), but didn't think that was needed as I was simply giving a
"hint".
That is *not* how they work.
Well, do *you* know how it really works? I mean, imagine your core
product with two millions of lines, and the boss that says "add some
popup blocking mechanism"... <kidding>
I never get a popup using any one of the
three browsers I use unless I explicitly tell it to give me a new window.
That's because there's logic inside your browser that kills unwanted
popups, hopefully before any resource is allocated to create them,
determining what popups are unwanted, maybe using the way the popup is
created, maybe inferring a strategy from content in the called URL...
Regards,
Elegie.
The funny thing about all this.. the window.open javascript calls on
the page worked fine with Symantec firewall turned on. Links to
popups worked just fine, so I can't suspect the software is trying to
prevent ads. It was the normal href links and onclick javascripts
that weren't working. And not only was the software inserting
javascript into the page source near the top and bottom, but it was
completely reformatting my HTML. How else could you explain this???
An <img> tag is completely missing!
<snip mangled markup>
All these new firewall "suites" pull this number, well, maybe not all. Symantec and
ZoneAlarm for example does it. ZoneAlarm affects both Opera and Internet Explorer for
me.
That is why I like Firefox so much. I can control the JavaScript and privacy issues
via
the browser rather than modifying the mobile code option in my firewall *every* time I
want to run some code.

In my situation, Firefox page source was being altered and rendered
useless as well by Symantec Firewall.

In ZoneAlarm I can disable the mobile code insertion junk it puts in. However, I have to
turn it *all* off before it stops putting its code in the markup. That is:

Block JavaScript
Block scripts (VBScript, et cetera)
Block embedded objects (Java, ActiveX)
Block mime-type integrated objects (which always kills Flash for instance)

Something else I experienced with Symantec that *really* plagued me is when I set up a
security camera system for a local daycare. The camera system hosted its own server
available via TCP/IP (Ethernet).

Symantec however, no matter what I tried, including shutting it down and uninstalling, it
kept blocking the Java (and the ActiveX option). Only uninstalling it *and* changing the
security settings in Internet Explorer to allow the content worked.

Pretty sad though, I have no clue what to tell Symantec users other than "make sure you
allow domain.com for blocked content." You would be surprised at how many times they say,
"Huh?"

And my biggest complaint with Firefox/Netscape are that they ignore
HTML/CSS parameters that IE handles, simple things such as width on a
<div> tag, or a hand cursor on mouseover of a link. Those things make
our website look very unprofessional.

Um... am I understanding you correctly? This is a bit off-topic, but:

<div style="width: 100px; border: 1px solid #000;">styled DIV</div>

There is no width attribute for a DIV in HTML.

<a href="" style="cursor: hand;">styled link</a>

...which is pointless as that is the default in most browsers.

Both of those items are recognized by Firefox. Did I misunderstand?

-Lost- Hide quoted text -

- Show quoted text -

Sorry, I was referring to a CSS styled anchor tag (not a div), applied
as follows... IE will create 120px wide buttons all day, Firefox/NS
will disregard and make each button a different height/width based on
the content. IE will use a hand pointer on mouse over, Firefox/NS
will show a text edit cursor on mouse over. It makes no sense to me.

My only point being, Firefox/NS spits out a less professional looking
webpage when using identical code. We've gone away from using these
buttons, because of this fact.

<a class="cssbtn" href='javascript: window.close();'>Close</a>

..cssbtn
{
width: 120px;
height: 15px;
padding: 3px;
line-height: 15px;
margin-top: 0.2em;
margin-bottom: 0.2em;
margin-left: 0.5em;
margin-right: 0.5em;
font-size: 12px;
font-family: Verdana;
font-weight: bold;
text-decoration: none;
text-align: center;
text-transform: lowercase;
vertical-align: middle;
background: #3366CC;
color: white;
white-space: nowrap;
cursor: hand;
border-color: #C7D5F1;
border-style: outset;
display: inline-block;
}