233260 - onclick return value ignored if intervening mouseout throws

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Florian Hars]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

The confirm() function always returns true if I select "Cancel", either with the
keyboard or the mouse, al least if called from an onclick-handler. This is
slightly inconvenient when the handler protects an "delete all billable hours
for this project" link...

This is not the same as bug222316 (that dialog works, and I don't have the
downloadbar installed)
The URL from bug68675 works correctly, too, where confirm() is called from
another javascript function.

Reproducible: Always
Steps to Reproduce:
1. Create a page that contains something like

<a href="dont-go-here" onclick="confirm('Testing confirm(). Click with a pointer
device on Cancel\n\nExpected behavior is to return false.\nActual is to
incorrectly return true.');">Test</a>

load it and click on the "Test" link
2. Click on "Cancel" in the popup dialog
3.

Actual Results:  
The browser tries to load "dont-go-here"

Expected Results:  
The browser does nothing.

Comment 1

[Florian Hars]

My first diagnosis was wrong (and the example code broken), the true reason for
this behaviour seems to be an interference with an additional onMouseOut handler
(probably because you have to leave the area of the link to click on the cancel
button):

<a href="dont-go-here" 
onClick="return confirm('Testing confirm() without onMouseOut.');"> 
Cancel works without onMouseOut </a>
/
<a href="dont-go-here" 
onMouseOut="self.status='Cancel will not work';"
onClick="return confirm('Testing confirm() without onMouseOut.');">
doesn't work with onMouseOut </a>

It does not matter wether the onMouseOut handler returns true of false.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Florian, please attach a page showing the problem to this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=233260&action=enter

Comment 3

[Florian Hars]

Attachment: Basic page that triggers this bug on my computer

Comment 4

[Boris Zbarsky [:bzbarsky]]

That testcase worksforme with Linux GTK1 trunk SeaMonkey build 2004-02-03-08.

Comment 5

[Florian Hars]

Attachment: New testcase

My new theory: the behaviour is triggered when the onMouseOut handler tries to
do something forbidden or produces a javascript error.

I narrowed my original problem down to a line in my prefs.js (that is there for
reasons that transcend my memory and knowledge):

user_pref("capability.policy.default.Window.status", "noAccess");

which caused the onMouseOut handler to fail.

The new testcase assigns to foo.bar.baz in the onMouseOut handler, which should
produce a javascript error "foo is not defined" in almosty any configuration,
and which triggers the bug for me, too.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> that is there for reasons that transcend my memory and knowledge

You set a pref to prevent pages setting the status bar text at some point in a
really really old build....

For the rest, if an exception is thrown inside onclick, we proceed with the load
even though there is no return value.  I sounds like the exception being thrown
here confuses either the JS engine or the DOM code into thinking the onclick threw.

Comment 7

[Kris Shannon]

Attachment: test233260.html

If a container of the clicked element is rewritten (with innerHTML for exmaple)

the return value seems to be lost as well (attached testcase)

Discovered on the edit contacts page of gmail

Comment 8

[Boris Zbarsky [:bzbarsky]]

That last testcase:

1) Works fine in a 1.8a3 build.
2) Has nothing to do with this bug.

I'm not sure why it was attached here, and I hope there will be no more spamming
of this bug related to that testcase.  If there is a problem with that testcase
in current trunk builds, file a separate bug (and feel free to cc me).

Comment 9

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.