319436 - Clicking a link does nothing while modifying the innerHTML and the href of that link with Javascript

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Virpi H]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Clicking a link does nothing, while modifying the innerHTML and the href of that link frequently with Javascript to generate a typewriter effect. 

Only after typing is done, the link works again. 

The correct href is shown in the status bar while typing.

Firefox 1.0.7 reports in Javascript Console "Error: uncaught exception: Permission denied to call method Location.toString". 

Firefox 1.5 reports no errors but does not work either. 


Reproducible: Always

Steps to Reproduce:
1. Open http://www.geocities.com/virpih78/firefox_example.html with Firefox.
2. Click the link while the script is typing text.
3. Click the link after the script has typed the whole text.

Actual Results:  
In 2.: The link does nothing. Another web page is not shown. 


Expected Results:  
In 2.: Another web page should be shown.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Phenomenon of this bug was reproduced with Firefox(latest-trunk 2005/12/02 build,Win-2K) and Seamonkey(latest-trunk 2005120309,Win-2K)。
In addition to your observetion, next are observed.
 (a) Properties thru context menu of the "typewriting" link displayed
     proper HREF.
 (b) "Right click(context menu)" and "Open link in new tab" jumped to the link
     which is currently displayed by the "typewriting".
 (c) If the link is clicked several times in very short period, the link worked
     well several times in my testing, although single click/several clicks
     didn't work many times in my testing as you says.
     (Very quick 3 to 5 clicks just after start of "typewriting", )
     ( but far before end of the "typewiting".                    )
 (d) I couldn't find any difference between left click and middle click.

My guess is as follows because of (c).
 (1) "box area for the link" is destroyed/recreated when each inner HTML
     text change because length of text of the inner <a> is changed
     on each very short timeout.
 (2) (a) Destory clickable box due to text length change.
     (b) Re-create clickable box due to text length increse of a byte.
 (3) If the (left/middle) click occurs before (a), and if the processing of
     the click is after (b), HREF is not invoked.

Questions to reporter.
(Q1) How about "onClick" event of the link(<a> tag) when the innerHTML length is
     changed repeatedly?
     Will "onClick" handler be scheduled when <a ... onClick="handler_func();">?  

Comment 2

[Virpi H]

(Q1) It appears to me that onclick is not working either. 

I added simple function "function click() { alert("click"); }" and a call to it as onclick="click();return false;". 

That behaves similarly to the href ie. it works, when there is no "typewriting", or if it is clicked at right moment (between writing characters?).

See http://www.geocities.com/virpih78/firefox_example_2.html

Comment 3

[WADA:World Anti-bad-Duping Agency]

Attachment: Modified test case

Your "Link_Obj.innerHTML=msgText;" is replaced by "Link_Obj.childNodes[Index of the first text node].nodeValue=msgText;"
In this thest case, link click works well.

This bugs phenomenon look to be phenomenon only when innerHTML is changed.

Comment 4

[WADA:World Anti-bad-Duping Agency]

Attachment: Test case-2 (Link text is placed in span. InnerHTML of span is changed.)

The link text for "typewriting" is placed in <span>...</span>, and your "Link_Obj.innerHTML=msgText;" is replaced by "Span_Obj.innerHTML=msgText;".
When this change, link click doesn't work, and it's same result as your original "Link_Obj.innerHTML=msgText;" case.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Attachment: Test case-3 (waitBetweenCharacters of case-2, 100 msec, is increased to 500 msec.)

waitBetweenCharacters, 100 msec in case-2, is increased to 500 msec.
When this change, probability of link click working well is increased.
 - 1/2 to 2/3 when case-3(2 clicks work well in 3 times of click try),
   although nealy equall to zero when your original case and case-2.

Comment 6

[WADA:World Anti-bad-Duping Agency]

My guess :
 (1) Changing innerHTML of <A> consists of two steps internaly.
     (1-1) Change "<A>current link text</A>" to "<A></A>"
           - Remove all child nodes of the <A> element,
             then box size of the <a> becomes (0 pixel x 0 pixel)
     (1-2) Change "<A></A>" to "<A>new link text</A>"
           - Reconstruct child nodes of the <A> element,
             then box size of the <a> becomes (mm pixel x nn pixel)
 (2) Assumptions
     (a) Time required to execute step (1-1) : T1
     (b) Time required to execute step (1-2) : T2
     (c) innerHTML change request by Script completes when the request is
         accepted, NOT after re-rendering, NOT after completion of step (1-2).
         Then time between start of (1-1) and next start of (1-1) is 100 msec.
 (3) T1<<T2, and (T1+T2) is not so smaller than "100 msec" which you specified.
     Then no chance that link click works well.
  

Comment 7

[WADA:World Anti-bad-Duping Agency]

My guess in comment #6 may be improper, because right clicking works well and status bar dislay is always done correctly.
Another guess is :
 - Click event is held in targrt element(inner most element in the clicking area).
 - Since replacing of innerHTML of <A> element destroys all child nodes of the
   <A> element, scheduling of click event is impossible, after start of step(1-1),
   and before end of step (1-2).
 - (T1+T2) is nealy equal to 100 msec, no chance that click works well.
  

Comment 8

[WADA:World Anti-bad-Duping Agency]

Cc-ing to Boris.

Is any fault of event handling involved?
Or simply user error?

Comment 9

[Boris Zbarsky [:bzbarsky]]

I have no idea; maybe I could tell with a minimal testcase or a lot of debugging... But clicking the links in all the testcases works fine for me (current Linux trunk Seamonkey build), so debugging is kinda hard.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #9)
> But clicking the links in all the testcases works fine for me
> (current Linux trunk Seamonkey build)

Boris, thanks for quick response.
I think "100 msec is too short for re-parsing and re-rendering" for me and  Mozilla, since my notebook is very poor, 'celeron 500MHz/Memory 128MB', and since I believe MS Win(even when MS Win NT family) is one of the worst OS among various OS'es in task sceduling mechanism in addition to his poor memory managemnt algorythm :-).
(Note: Link clicking works well when Opera 9.0 Preview-1, even if my poor PC.)

I'll try to create minimized test case with event hooking using addEventListner for elements involved in this phenomenon.

Virpi H, sorry but I can't say this is bug or user error.
Try one of next workarounds, please.
 (1) Change text node value of the <A> element, instead of changing innerHTML.
 (2) Increase timeout value.

Comment 11

[Virpi H]

The workaround (1) works fine for me. Thanks! 
So at least, the severity of this bug can be changed to minor. 

I don't think your laptop is the issue though as I have an 'AMD Athlon 2.09GHz + 1024MB' desktop at home and a 'Mobile Pentium(R) 4 1.80GHz + 512MB' laptop at work. (Also the link works fine in both Opera 7.11 and MSIE 6 on my laptop.)

Comment 12

[José Jeria]

Attachment: Minimized testcase

Nothing happens when clicking the link. Using latet trunk build on XP

Comment 13

[Boris Zbarsky [:bzbarsky]]

Ah.  So this is a matter of how fast you click... If the mousedown and mouseup happen on different content nodes (as would happen here if you hold the mouse button long enough), I believe we don't fire a click event...  We have existing bugs on that.

Comment 14

[WADA:World Anti-bad-Duping Agency]

Attachment: Minimized testcase-2 based on attachment 205475

As Boris Zbarsky says in comment #13, problem was when innerHTML change between mousedown event scheduling and mouseup event scheduling.
(This can occur even if mouse click is done normaly, even if not so slow click.) 

Next mouse events was traced.
 <div id=div1 onClick=onclick_handler_div1>
      <span id=span1 onClick=onclick_handler_span1></span>  
      <div id=div2 onClick=onclick_handler_div2>
           <span id=span2
                     onClick=onclick_handler_span2
                 onMouseover=onmouseover_span2
                  onMouseout=onmouseout_span2
                 onMousedown=onmousedown_span2
                   onMouseup=onmouseup_span2
            ></span>  
      </div>
 </div>

(Test result when innerHTML change interval is 100msec. Celereon 500MHz/Win-2K)

(Reversed order of events. First is last event.)
onmouseout_span2 is kicked.
typewriter is stopped.
click_handler_div1 is kicked.
click_handler_div2 is kicked.
interval is set to ZERO.
click_handler_span2 is kicked.
onmouseup_span2 is kicked.
onmousedown_span2 is kicked.
typewriter is kicked. character=16
typewriter is kicked. character=15
typewriter is kicked. character=14
onmouseup_span2 is kicked.
typewriter is kicked. character=13
onmousedown_span2 is kicked.
typewriter is kicked. character=12
typewriter is kicked. character=11
onmouseup_span2 is kicked.
typewriter is kicked. character=10
onmousedown_span2 is kicked.
typewriter is kicked. character=9
typewriter is kicked. character=8
typewriter is kicked. character=7
typewriter is kicked. character=6
onmouseup_span2 is kicked.
typewriter is kicked. character=5
onmousedown_span2 is kicked.
typewriter is kicked. character=4
typewriter is kicked. character=3
typewriter is kicked. character=2
typewriter is kicked. character=1
typewriter is kicked. character=28
typewriter is kicked. character=27
onmouseup_span2 is kicked.
typewriter is kicked. character=26
onmousedown_span2 is kicked.
typewriter is kicked. character=25
typewriter is kicked. character=24
typewriter is kicked. character=23
typewriter is kicked. character=22
typewriter is kicked. character=21
onmouseup_span2 is kicked.
typewriter is kicked. character=20
onmousedown_span2 is kicked.
typewriter is kicked. character=19
typewriter is kicked. character=18
typewriter is kicked. character=17
typewriter is kicked. character=16
typewriter is kicked. character=15
onmouseover_span2 is kicked.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #13)
> Ah.  So this is a matter of how fast you click... If the mousedown and mouseup
> happen on different content nodes (as would happen here if you hold the mouse
> button long enough), I believe we don't fire a click event...  We have existing
> bugs on that.

bug 6316 mentions mouseover/mouseout specifically, I couldn't find any others. Is that bug more general than it's summary indicates?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Well... the underlying issue is the same, but the fixes might need to be different, I guess.

Comment 17

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.