264497 - Events are consistently failing: mouseup event

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Joseph Latouf]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

The Javascript console identifies the following error as the mouseup event
attempts to fire (appears to be partially handled). This error does not occur in
Mozilla 1.6
----------
Error: [Exception... "'JavaScript component does not have a method named:
"handleEvent"' when calling method: [nsIDOMEventListener::handleEvent]" 
nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location:
"<unknown>"  data: no]

Reproducible: Always
Steps to Reproduce:
1.Load solution
2.Open a window, such as in the "View" sub-menu, select "Open Results Window"
3.Drag this window within the browser.
4.Release the mouse to stop dragging the window. Normally the mouseup event
properly releases the dragging of this window. In Firefox it doesn't release and
cites the error included in "details" above.

Actual Results:  
The Window continues to drag as it follows the mouse within the browser. This is
by design... until the mouseup releases the window in question.

Expected Results:  
As the mouseup fires, the drag operation is released and other windows, icons,
or object may be selected. This works as expected in earlier releases of
Mozilla, Netscape and IE

This "handleEvent" is being called within "your code"; it is not being called
"directly" by the code within this website. I can provide more information as
required.

Comment 1

[Phil Ringnalda (:philor)]

Seamonkey 1.6 might do what you expect, but 1.8a4 certainly doesn't seem to.

-> DOM: Events, where someone who knows what's what might see it.

Comment 2

[Joseph Latouf]

I now find that all mozilla based browsers are exhibiting this same behaviour. 
Furthermore the "first time a Window is dragged" in the browser, it works as 
expected. Subsequent drags produce the error cited in the original bug report.

Comment 3

[Joseph Latouf]

I have done some brief research on the net and found other references to 
issues involving "nsIDOMEventListener::handleEvent", such as:

http://bugzilla.mozdev.org/long_list.cgi?buglist=6969
http://bugzilla.mozdev.org/show_bug.cgi?id=5985
http://blog.simon-cozens.org/songbee/bryar.cgi
http://www.mail-archive.com/[e-mail]/msg05813.html
http://groups.google.com/groups?
q=mac+only+dom+exception&hl=en&selm=3CB1E994.10003%40surfmind.com&rnum=1
http://www.interactivetools.com/iforum/Open_Source_C3/htmlArea_v3.0_-
_Beta_Release_F14/Setup_help%3B_Popup_(link,image,etc)_errors_P27428/

--------------------
Please note that this solution (www.casew.com/portable, and others) was 
verified to be working in Netscape 7.0, 7.1 and Mozilla 1.6 previously (prior 
this month).

Comment 4

[Boris Zbarsky [:bzbarsky]]

This bug needs a minimal testcase.

Comment 5

[Gérard Talbot]

Joseph, is this bug still happening?

I loaded the provided URL, clicked View and Open Results Window, dragged the
window and release the mouse to stop dragging the window. Everything worked
accordingly: I got the expected results. 

1 javascript error 

Error: _17 is not defined
Source File: http://www.casew.com/_PI/PI_3_2_10.js
Line: 5

and 10 CSS parsing errors though:

Error: Unknown property 'postion'.  Declaration dropped.
Source File: http://www.casew.com/portable.htm
Line: 0

Error: Unknown property 'word-wrap'.  Declaration dropped.
Source File: http://www.casew.com/_themes/pi3_1.css
Line: 209

Error: Unknown property 'backgroundColor'.  Declaration dropped.
Source File: http://www.casew.com/_themes/pi3_1.css
Line: 80

etc...

Tried with Mozilla 1.8a5 build 2004112306 and Firefox 1.0 final release rv:
1.7.5 build 20041107 under XP Pro SP2 here.

Comment 6

[Gérard Talbot]

> This bug needs a minimal testcase.

attachment 101322 [details]  (from bug 172031) is a reduced testcase for testing mouseup
event on a drag of a div. WORKSFORME

Otherwise, this bug is a DUPLICATE of bug 193548.

Comment 7

[Joseph Latouf]

As of this date (24 Nov 2004) this issue seems to have been resolved. The 
functionality is working as it was before the initial report I filed.

Comment 8

[Gérard Talbot]

Thanks for reporting back.
If the problem resurface again, just reopen this bug and give details, explanations.

Resolving as WORKSFORME