Closed Bug 233142 Opened 21 years ago Closed 21 years ago

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

Categories

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

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: jst)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files)

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.
Attached file testcase (deleted) —
Any chance of a smaller (like 1-day) regression window?
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.
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?
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
Blocks: 134878
Duh, I apparently missed your comment in bug 226462. Looking.
Status: NEW → ASSIGNED
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.
Attachment #141371 - Flags: review?(bzbarsky)
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+
Attachment #141371 - Flags: superreview?(bryner)
Attachment #141371 - Flags: superreview?(bryner) → superreview+
jst checked in a fix yesterday.
FIXED.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Flags: blocking1.7b?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: