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)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Assigned: jst)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
bzbarsky
:
review+
bryner
:
superreview+
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
Comment 2•21 years ago
|
||
Any chance of a smaller (like 1-day) regression window?
Comment 3•21 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•21 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•21 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
Assignee | ||
Comment 6•21 years ago
|
||
Duh, I apparently missed your comment in bug 226462. Looking.
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•21 years ago
|
||
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•21 years ago
|
Attachment #141371 -
Flags: review?(bzbarsky)
Comment 8•21 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•21 years ago
|
Attachment #141371 -
Flags: superreview?(bryner)
Updated•21 years ago
|
Attachment #141371 -
Flags: superreview?(bryner) → superreview+
Reporter | ||
Comment 9•21 years ago
|
||
jst checked in a fix yesterday.
Assignee | ||
Comment 10•21 years ago
|
||
FIXED.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Flags: blocking1.7b?
You need to log in
before you can comment on or make changes to this bug.
Description
•