233142 - onmouseover that doesn't return prevents URLs from appearing in status bar

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Jesse Ruderman]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040203
Firebird/0.8.0+

Steps to reproduce:
1. Load the testcase.
2. Hover over the link.
Result: no URL appears in the status bar.

The testcase has an onmouseover that doesn't do or return anything:
javascript:document.onmouseover = function() { };

Regression window (testing Firebird trunk):
good: 12/16
broken: 12/31
broken: 02/03

Related: bug 227159 (but that was filed Dec 1, and this regressed after Dec 16.)

This bug is not present on the Firebird 0.8 branch.

Comment 1

[Jesse Ruderman]

Attachment: testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

Any chance of a smaller (like 1-day) regression window?

Comment 3

[Hermann Schwab]

tested on Mozilla Suite Win98, 
BuildID 2003121908 is working, 
BuildID 2003122308 is failing.

After loading has finished, 'done' is seen in the statusbar.
If you hover over the link, 'done' is cleared, so the hover is recognized, but
the URL not written to the status bar.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This is a regression from bug 226462.  The old logic was:

keep_going = "not bool returned" || (reverse ? !return : return);

The new logic is:

keep_going = ("not bool returned" || return) xor (reverse)

So in the old code, if the retval was not a bool, we kept going no matter what
retval happened to be or what reverse was.  In the new code, if the retval is
not a bool and reverse is true we kill the event.  In the testcase here, I
expect the retval is undefined or some such?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Note that you've also changed the behavior when the handler throws an exception.
 Prior to the patch for bug 226462 that would end up returning true (since "ok"
would be false) and such handlers would not cancel the event.   In the current
code, an exception in a handler will cancel an event.

Marking major due to that -- that's a pretty severe change in behavior,
especially if we don't intend it.

Comment 6

[Johnny Stenback (:jst)]

Duh, I apparently missed your comment in bug 226462. Looking.

Comment 7

[Johnny Stenback (:jst)]

Attachment: Fix, and take care of not submitting if onsubmit fails too

This should revert to the old logic (with some minor differences in error
cases, but I seriously doubt that matters), and it also makes us prevent the
default action of onsubmit events if there's any error in handling onsubmit
events.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141371 [details] [diff] [review]
Fix, and take care of not submitting if onsubmit fails too

Makes sense.  r=bzbarsky

Comment 9

[Jesse Ruderman]

jst checked in a fix yesterday.

Comment 10

[Johnny Stenback (:jst)]

FIXED.