57174 - NS6b3: OnClick Event does not work with window.print()

Status: RESOLVED INCOMPLETE

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[William C. Dickinson]

I reported this under 57169; after further investigation found the problem is 
in the OnClick event of the ANCHOR tag failing to 'return false' when 
window.print() is called.

This causes the hyperlink to be activated or, as in this example, the 
javascript call to be executed.  Since the onclick event should ALWAYS return 
false the hyperlink / javascript in this example should never be activated. 
Unfortunately it is!

This HTML will recreate the problem ...

<a href="javascript: alert('Hello');" onclick="window.print(); return 
false;">TEST</a>

Clicking TEST will bring up the print dialogue box. Click <CANCEL> and an alert 
box with the HELLO message will appear; it shouldn't.

If you remove the 'window.print();' segment and replace it with a function that 
returns 'true' or 'false' the ANCHOR tag works as expected; i.e. you will NEVER 
see the hello message.  The problem appears to be quite specific 
to 'window.print()'

This problem does not occur in NS4+ or IE4+

Comment 1

[Loco]

Confirmed on Mac 10-18-08, although it is beyond me why anyone would want to make 
code like this.  Whatever.  Also changing platform to ALL.

Comment 2

[William C. Dickinson]

I must respond to the statement 'why would anyone want to write code like 
this'...
 
Basically it is to work around bugs in the Mac Implementation of IE5 and NS4 
which do not always respond to ANCHOR tags written as follows <a 
href="javascript: window.print()">PRINT THIS FRAME</a> in a multi-framed 
environment.
 
In theory clicking PRINT THIS FRAME should cause the window.print() method to 
be called. This does not happen with all browsers on all platforms, with 
particular problems on the Mac, ergo the workaround code which is ...
 
<a href="javascript: window.print()" on click="window.print(); return 
false;">PRINT THIS FRAME</a>
 
The above structure seems to be highly portable across quite a number of 
browser platforms. Some respond to the 'onclick' event, return false and never 
call the script associated with 'href'. Others never see the 'onclick' event 
but always call the 'href' script. With the single exception of NS6 and 
CANCELLING the window.print() call this structure works.
 
The problem is quite specific to the window.print() javascript method within 
NS6. If you replace window.print() with a function named "DoThis()" it matters 
not if that function returns true or false ... the 'href' script call will 
NEVER be executed. However if "DoThis()" is replaced by "window.print()" NS6 
will respond to the 'onclick' event and execute the window.print() method. If 
the print applet is CANCELLED (allowing it to print works OK) NS6 will proceed 
to execute the href="javascript: window.print(). Since the onclick event ALWAYS 
returns false this should NEVER happen.
 
I agree that no sane person would write code like this if all the gawd damn 
browsers complied with the W3C DOM. However quite a lot do not and quite a few, 
NS6 in particular, are riddled with obscure bugs that we applications 
developers have to work around to ensure cross-browser and cross-platform 
compatibility.
 
I yearn for the day when I can say that anyone using a browser that does not 
comply with the W3C DOM1 and HTML 4.01 specifications can take a hike. Until 
that day comes I, and most other people I know, have to live with the aftermath 
of the incompatibilities that fell out of 'Browser Wars'.
 
I guess it could be worse - we could always hand the whole mess over to an ANSI 
committee and not see a standard emerge until the internet becomes obsolete.
 

Comment 3

[Hixie (not reading bugmail)]

But why would someone want to provide a link to the print feature? Isn't that
the job of the browser's interface?? Seems a bit redundant. I mean, what if the
page is being displayed using an aural browser, such as over the phone? (Think
tellme.com style interface.) Print wouldn't mean anything in that context.

Comment 4

[William C. Dickinson]

Ian -

Have you ever worked with a multi FRAMED document or POP-UP windows in a cross-
browser, cross-platform e-Commerce environment? Such an envrionment is highy 
scripted to provide interaction and error checking of user actions.

If you have tried the PRINT button on different browsers and different 
platforms you would know that it behaves in all sorts of mysterious and 
unpredictable ways where FRAMES and POP-UP windows are involved.

Some browsers, the good ones like IE45 and NS4, allow the user to click a frame 
to give the document within it the focus. You can then click the PRINT button 
to print only the contents of the selected frame. Not all browsers are this 
user friendly. Many will print the contents of every frame regardless of which 
frame has the focus. Others won't print the frames at all - just blank sheets 
of paper for the base frameset.

The only practical workaround I have found is to provide an ANCHOR tag with a 
hyperlink calling the window.print() method on each document which you wish to 
allow the visitor to print.

POP-UP WINDOWS: It is often visually unacceptable to fork an entire browser 
just to provide the user with some additional information, such as the current 
stock status for a product. This information appears in a small floating window 
without any banner and hence no PRINT button. ERGO if the user needs to print 
the contents of this window there is only one way to do it ... through an 
ANCHOR tag, etc, with a hyperlink that calls the window.print() method.

These comments notwithstanding there is a serious bug in NS6 and window.print() 
when it is CANCELLED. For whatever reason it overrides any script call which 
follows winddow.print(). In my application the construct is 
onclick="window.print(); return false;" ERGO the onclick event should NEVER 
return true as this kicks off the href javascript call which is should not do 
under any circumstances. Read my previous comments as to why I need to build in 
both the "href=" as well as the "onclick=" constructs.

It isn't my fault that the browser suppliers don't comply with DOM or HTML 
standards - I just have to find ways to work around all of the 
incompatibilities. If this throws out a genuine bug in a new product like NS6 
it is in everyone's interest that I report it, as obscure as it may be.

Comment 5

[Hixie (not reading bugmail)]

Don't worry, I completely agree that this bug is valid, and am happy that you
filed it! Thanks for the help!

I was just wondering why anyone would use window.print(), your answer explained
that for me. Thanks!

Comment 6

[joki (gone)]

Very odd bug.  Futuring for the moment.  I'll try to pull it back.


This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.

Comment 7

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 8

[Madhur Bhatia]

QA contact updated

Comment 9

[Fabian Guisset]

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

Comment 10

[Ernest M. Campbell III]

Just to put in my $0.02 worth.... Bugs in window.print() don't appear to be 
limited to canceling the printing. My company has a similar situation: frames 
with a scripted print button in the content. When I click our print button 
(which attempts to resize an image before printing, so that it will fit within 
the boundaries of the printed page), I get the print dialog, I hit okay, I get 
a notification that the page was printed, then I get a crash. This happens both 
with Mozilla 0.9.3 and with Netscape 6.1. Oh, and BTW, it prints a blank page 
(just header/footer, the image doesn't print).

-- 
Ernest M. Campbell III <[e-mail]>
Web Developer, AAA Cooper Transportation

Comment 11

[Pham]

.

Comment 12

[Andrew McCreight [:mccr8]]

Event code has changed a lot in 20 years.