252542 - The attached events are not removed while reloading the page. JavaScript errors are occuring

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[arny]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707

The attached events should be removed when refreshing or leaving a location

Reproducible: Always
Steps to Reproduce:
1.hit Ctrl+R
2.move your mouse over the yellow areas
3.do it quickly

Actual Results:  
Error: foo is not defined
Source File: http://moolok.com/foo.htm
Line: 15

thats what you will get

Expected Results:  
nothing. like other browsers do.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: js for the testcase

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: testcase

Comment 3

[Boris Zbarsky [:bzbarsky]]

jst, peterv, it looks like we clear the global scope but the handlers are still
active... we should really disable them when we clear the global scope, I would
think.

Comment 4

[Ian Neal]

Confirming still a problem on BuildID 2004082007 on WinXP SP1

Comment 5

[Mike Caines]

Confirming still a problem on

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026
Firefox/1.0RC1

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041027

Comment 6

[WADA:World Anti-bad-Duping Agency]

Similar problem is Bug 199430.
> Bug 199430 : eventhandlers still fire while a new page is loading
(This bug is CTRL+R case=same URL, but Bug 199430 is even on new-URL=diffrent
URL case.)
See dependency tree for Bug 296639, which has been set as "depends on:" bug by
Boris.  

Comment 7

[Erik Fabert]

*** Bug 296260 has been marked as a duplicate of this bug. ***

Comment 8

[Erik Fabert]

*** Bug 276488 has been marked as a duplicate of this bug. ***

Comment 9

[WADA:World Anti-bad-Duping Agency]

Similar Bug 199430 seems to be already resolved(See Bug 199430 Comment #13).
Is the problem still be recreatable?

Comment 10

[Erik Fabert]

(In reply to comment #9)
> Similar Bug 199430 seems to be already resolved(See Bug 199430 Comment #13).
> Is the problem still be recreatable?

I don't see any improvement in this bug's testcase with a current Firefox trunk build (2006031005, Win2000).

Comment 11

[arny]

this bug is not fixed yet

Comment 12

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10 comment #11)
> I don't see any improvement in this bug's testcase with a current Firefox trunk
> build (2006031005, Win2000).

> this bug is not fixed yet

Erik Fabert and arny, how did you confirm "Script error during Reload is caused by event scheduling of click event which was generated before Reload"?

I tested "Consecutive Click and Reload" when button is disabled by onUnload script and button is disabled just after <input button> definition.
  http://www.h2.dion.ne.jp/~radon/test/bug-252542-test-001.html
I can't see any JavaScript error when button is disabled by onUnload and disabled by script just after <input button>, although I can easily see JavaScript Error(cnt is not defined, in my test case) if button disabling logic is removed.

When this bug's case, URI is not changed because of Reload, and mouse related event can occur and can be scheduled even while early stage of Reload process, because page is already displayed, and because field where mouse event can occur always exists, and because the field is enabled.
Problem you are still seeing is "Mouse event at Reloaded page is scheduled too early when Reload", isn't it?

Comment 13

[Erik Fabert]

(In reply to comment #12)

I'm not quite sure what you're aiming at. If you look at this bug's testcase attachment 153948 [details], it adds the mouseover handlers in the onload event handler, so everything must be loaded at that time. Still we get JS errors when mousing over the areas during reload which indicates the summary of this bug is accurate: attached events are not removed while reloading the page.

Comment 14

[arny]

Just like Erik Said,
the event triggers should be disabled, as long the document and all dependencies are all completely loaded.
In this testcase we see event triggers firing on events which have been added on preview document load.
Why not just trash all events of DOM on eash refresh?
I'm using my own workarounds to prevent this messages since this bug wasn't fixed yet, even after a so long period. Sadly

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #13)
> If you look at this bug's testcase attachment 153948 [details] [edit], it adds the mouseover handlers in the onload event handler, so everything must be loaded at that time.

Oh sorry, I didn't understand test case correctly.
My concern is now :
  Mouseover events, which are scheduled and cause script error,
  are executed at "page(window) before Reload" or "page(window) after Reload". 

When my test case of Bug 199430 Comment #6, scenario is:
 (1) Submit button is clicked many times at old page(win1)
 (2) Submit is executed(submit to different URI) and URI is changed(win2)
   (A) Before fix of Bug 296639
       Event was apparently generated at old page, and the event was apparently
       scheduled at new page, and script of new page was apparently executed.
   (B) After fix of Bug 296639
       Error: DoScript is not defined
       Source File: http://www.h2.dion.ne.jp/~radon/test/bug-199430-win1.html
       Line: 1
Since DoScript is user defined function, it's still unclear for me what is happening. So I created second case - no user defined function call, access to global user variable(direct child of window object) only which is defined at both pages.
 (1) http://www.h2.dion.ne.jp/~radon/test/bug-199430-test2-win1.html
     Click "send" button several times quickly, then changes to next page.
 (2) http://www.h2.dion.ne.jp/~radon/test/bug-199430-test2-win2.html
  ==> Several following errors occur 
  Error: stat is not defined
  Source File: http://www.h2.dion.ne.jp/~radon/test/bug-199430-test2-win1.html
  Line: 1

JavaScript error always says "win1.html", and since it says always "Line:1", it looks to be executed at old page(window), instead of new page(window). So my guess is as follows, although I'm uncertain whether events are executed at old page(window) or new page(window). 
 (1) Several click events are held at old page
 (2) Unload process at old page starts
 (3) User variables are cleared  
     (C-1) Script of click event is executed => Script error
 (4) Unload process at old page completes
 (5) Load process starts, but user variable is not defined yet
     (C-2) Script of click event is executed => Script error
 (6) User variables are initialized
 (7) Load process completes
     (C-3) Script of click event is executed, but under different(old) window,
           then executed as if done at (C-1) => Script error
If the script error is (C-1) or (C-3), and if above is also applicable to this bug's Reload case(same URI), JavaScript error observed in this bug's test case can be (C-1) or (C-3) after fix of Bug 296639.
And if the script error is (C-3), problem of comment #3 is resolved, and original phenomenon is changed to new phenomenon of "script error at (C-3)", although external view(script error) is same as original when Reload case.

Is above applicable to this bug's Reload(same URI) case?

> the summary of this bug is accurate: attached events are not removed while reloading the page.

I agree with you. Remaining issue in Bug 199430' case(submit case) is same one as this bug, if main issue of Bug 199430 is resolved by fix for Bug 296639. 

Comment 16

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #15)
To clarify my question in comment #15, I created test case based on Christian Biesinger's test case.
 ( http://www.h2.dion.ne.jp/~radon/test/bug-252542-test-002-case-1.html )
Main differences are :
 (1) window.self.name is changed by script in HTML, onLoad and onUnload
     in order to see when event is scheduled.
 (2) To generate more events, eventListener for both capture and bubble, both
     mouseover and mouseout are added.
 (3) To make test case more clear, DIVs are hidden by display:none initially,
     and display:none is set again when unload by onUnload script.
     DIVs are displyed and eventListeners are added manually by onClick handler
     of a button.
 (4) Since event handler's execution stops at JavaScript error, try/catch is
     used in event handler in order to see more data when error occurs,
     and data is displayed by alert.
For test procedure and my test results, please see the page.

After fix of Bug 296639, environment for before Reload and environment for after Reload seems to be isolated, and event handler execution looks to be done in old environment where almost all Unload process comletes, although "window.name" is shared between them.
Fix for Bug 296639 seems to resolved problems of (2), (3-1), (3-2) by moving them to (1), then script error at (1) seems to occur always in both this bug's cases and Bug 199430' cases.
 (1) Old event is scheduled during Unload process at old page
     ==> many causes JavaScript error
 (2) Old event is scheduled at very early stages of Load process at new page
     ==> all causes JavaScript error
 (3) Old event is scheduled at near end of Load process of new page
 (3-1) If script is never executable in any stage, all causes JavaScript error
 (3-2) If script is executable, old event is executed at new page

Another test case is available : 
 - All eventListener are removed from DIVs by onUnload script.
   ( http://www.h2.dion.ne.jp/~radon/test/bug-252542-test-002-case-2.html )
In this case, I cound't re-create problem yet.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Can anyone reproduce this?
There has been quite a few fixes to event handling, and I
can't reproduce this anymore, not even in 1.8.1 branch.

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

This was fixed in bug 393762.