27769 - doesn't load CNN's quickvote result-window anymore

Status: VERIFIED FIXED

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

Description

[rkaa]

The daily Quick-Vote vote-button on CNN's frontpage launches a new little window
with results. Around two/three weeks ago this started to work OK in Mozilla
browser, for the first time. Now (build 2000021409) it's broken again and has
been so for 5 days. This likely is a redirection or javascript interpretation
error - not sure what compontent to file this under. A reassignment is probably
in place.

Comment 1

[Richard Zach]

This is a similar problem to bug 27775.  Apparently the JS included via <script
src=".."> isn't executed.

Comment 2

[vidur (gone)]

A focus bug actually. The method nsEventStateManager::CheckForAndDispatchClick 
calls HandleDOMEvent on the INPUT element content and hence triggers the onclick 
handler. The onclick in the source creates a new window (and hence removes focus 
from the window). By the time nsEventStateManager::CheckForAndDispatchClick 
attempts to pass the click event to the corresponding frame, mCurrentTarget has 
changed. As a result we never call the INPUT element frame's HandleEvent method 
and never submit the form. The popup window should be populated as a result of a 
successful form submission.

Cc:ing Hyatt since focus memory may also be implicated.

Comment 3

[saari (gone)]

Wait, the focus will fire in another ESM, meaning a different mCurrentTarget.

Further, focus doesn't reset mCurrentTarget. I don't see how focus is resetting

mCurrentTarget here... what am I missing?



Anyway, if this is really what is happening, saving off and restoring

mCurrentTarget should be OK...

Comment 4

[saari (gone)]

If you remove the line mCurrentTarget = nsull; in
nsEventStateManager::PreHandleEvent NS_DEACTIVATE, it still doesn't work right.

I'm not sure if we should reset mCurrentTarget for a deactivate or not... if we
do want to do that, and this bug implies that we do, just remove the line in
NS_DEACTIVATE.

Reassigning to joki so he can take this to the end zone for the big score.

Comment 5

[rkaa]

Seems this is being fixed now - CNN resultwindow loads fine.
BUT: when later exiting and restarting mozilla, the browser starts anew with the
same size that little CNN vote-result page had. It gets remembered as "default"
windowsize?

Comment 6

[rkaa]

In build ID 2000022808 it's broken again (since M15 appeared). Same error: new

window is empty.

Comment 7

[ekrock's old account (dead)]

Marking M16 and top100.

Comment 8

[rkaa]

Build ID: 2000020809
Now it works again; the page loads. The flaw with the tiny quickvote windowsize
being set as default when the next session of mozilla starts, remains.

Comment 9

[Richard Zach]

The problem with the window size is bug 15555.

Comment 10

[R.K.Aa.]

and in 2000041008 it doesn't work again - empty grey window. I don't check this

on each build so may have been broken again for a while.

Comment 11

[ekrock's old account (dead)]

No-brainer nsbeta2. JavaScript b.c. bug on Top 100 site.

Comment 12

[R.K.Aa.]

this seems to work now. I suspect there's other bugs on this being worked on..
haven't found the dup yet - or what this is a dup of.

Comment 13

[leger]

Would like a QA restest please

Comment 14

[Jan Carpenter]

Worked for me on 2000-05-26-08-M16 Linux
Marking fixed.

Comment 15

[Jan Carpenter]

verified fixed