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

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
--
major
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Jesse Ruderman, Assigned: jst)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Created attachment 140661 [details]
testcase

Comment 2

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

Comment 3

14 years ago
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

14 years ago
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

14 years ago
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.
Assignee: general → jst
Severity: normal → major
Depends on: 132777
Flags: blocking1.7b?
OS: Windows XP → All
Hardware: PC → All

Updated

14 years ago
Blocks: 134878
(Assignee)

Comment 6

14 years ago
Duh, I apparently missed your comment in bug 226462. Looking.
Status: NEW → ASSIGNED
(Assignee)

Comment 7

14 years ago
Created attachment 141371 [details] [diff] [review]
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.
(Assignee)

Updated

14 years ago
Attachment #141371 - Flags: review?(bzbarsky)

Comment 8

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

Makes sense.  r=bzbarsky
Attachment #141371 - Flags: review?(bzbarsky) → review+
(Assignee)

Updated

14 years ago
Attachment #141371 - Flags: superreview?(bryner)
Attachment #141371 - Flags: superreview?(bryner) → superreview+
(Reporter)

Comment 9

14 years ago
jst checked in a fix yesterday.
(Assignee)

Comment 10

14 years ago
FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Flags: blocking1.7b?
You need to log in before you can comment on or make changes to this bug.