Closed Bug 27769 Opened 25 years ago Closed 24 years ago

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

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: rkaa, Assigned: joki)

References

()

Details

(Keywords: top100, Whiteboard: [NEED INFO])

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.
This is a similar problem to bug 27775.  Apparently the JS included via <script
src=".."> isn't executed.
Assignee: joki → vidur
Component: Event Handling → DOM Level 1
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.
Assignee: vidur → saari
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...

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.
Assignee: saari → joki
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?
In build ID 2000022808 it's broken again (since M15 appeared). Same error: new

window is empty.

Marking M16 and top100.
Keywords: top100
Target Milestone: M16
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.
The problem with the window size is bug 15555.
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.

No-brainer nsbeta2. JavaScript b.c. bug on Top 100 site.
Keywords: nsbeta2
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.
Would like a QA restest please
Whiteboard: [NEED INFO]
Worked for me on 2000-05-26-08-M16 Linux
Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified fixed
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.