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)
Tracking
()
VERIFIED
FIXED
M16
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.
Comment 1•25 years ago
|
||
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
Comment 2•25 years ago
|
||
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
Comment 3•25 years ago
|
||
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•25 years ago
|
||
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.
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 10•24 years ago
|
||
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 12•24 years ago
|
||
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 14•24 years ago
|
||
Worked for me on 2000-05-26-08-M16 Linux Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•