Closed Bug 64212 Opened 24 years ago Closed 23 years ago

unable to view source after mousing over DHTML menu

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.1

People

(Reporter: bugzilla, Assigned: saari)

References

(
URL
)

Details

(Keywords: dom0)

Attachments

(1 file)

Testcase/example, I love this kind of things!
11.54 KB, text/html
Details 
if you go to:
http://vind.tv2.dk/
and select View -> Page Source nothing happens.

The console says it all:

JavaScript error:
chrome://navigator/content/navigator.js line 1271: focusedWindow has no properties

Build 20010102
hmm... wfm using 2001.01.03.08 comm verif bits on linux [i used the stubs
installer, fwiw]. is it still a problem with a more recent build?
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Works for me using 2001010108 Linux
sometimes this works for me too. But I can also reproduce the error. Will try to 
find other site...
Try this to reproduce:

1) Go to http://vind.tv2.dk
2) Log into the service using the form to the left. Use mozilla for both the 
username and password. Click the checkmark left of Gem and klik "Log På"
3) Now reload the page by pressing enter in the Location field.
4) Now click anywhere on the main page
5) Now do View -> Page Source
5) nuthing should happen...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
hm, i followed those steps, but...am still able to view source. weird.

out of curiosity, what did you use to install the build? [tarball, stubs
installer, or blob [sea] installer?]
could be a win thing only?
Used the win32-installer.
Got build 2001010220

So you're logged into the site with the user mozilla?
yep, i used mozilla/mozilla... i'll try it again with win32, once a verification
becomes available today. :)
Try this to reproduce:
1) start clean browser
2) go to http://vind.tv2.dk
3) verify that is says "Du er logget på som: Mozilla"
4) Now press "Ping" link in upper right cover
5) Right click on the page and select View Page Source

do you still get the source?

I have user_pref("javascript.options.strict", true);
in my prefs. Could it matter????

You're right! I'm working with WinNT4 sp6b build 2000122920. It almost looks
like it that it doesn't work at all. b.t.w. did you see that message in the
JavaScript console?? Line 1271. After pressing right-click on the blue part of
the screen, context menu activated, but hell, no source, not even that new
window opens!

Hey and if I do that on that banner on top of the page, then I't opens a new
window, with source! Isn't that an <iframe> ??
CC:ing sorry for the SPAM
weirdness. i still cannot get this problem to occur [ie, i get the view source
window just fine], even using 2001.01.03.11 comm verif bits on winNT. don't get
the js error in the js console that henrik initially reported.

the js strict pref is true by default, so i don't *think* that'd be the cause...
cc'ing bill and mitch to see if they see this...
Found it, it is the menu JavaScript. Make sure NOT to activate the menu! And
then, there it is, new window, and the source! After using the menu, BINGO, no
source will be shown!
A final and working reproduce:
1) go to http://vind.tv2.dk
2) move around in the DHTML menus at the top of the screen.
3) Now right click on the page and select View Page Source
4) Nuthing happens due to a javascript error.
exactly!

cc'ing prashant and jst who might know more... but which component should this
reside in?
Summary: unable to view source → unable to view source after mousing over DHTML menu
first guess: over to DOM 0...
Assignee: vishy → jst
Status: REOPENED → NEW
Component: XP Apps → DOM Level 0
QA Contact: sairuh → desale
Looks like some sort of (focus) event handling thing.  DOM is probably close enough.

There's another bug that might be related (similar event handling snafu) that
appears when you do a right-mouse double-click.  I can't find that bug at the
moment, though... 
Has line 1271 become line 1274 in newer builds? I.e. this line:
  var docCharset = "charset=" + focusedWindow.document.characterSet;

If so, that implies document.commandDispatcher.focusedWindow returned a null,
which it shouldn't, I think.

This smells like hyatt's code, reassignin to hyatt.
Assignee: jst → hyatt
Law: Were you thinking of bug 30841?
Did you read my comment? Isn't that an <iframe>? Yes sir, line 59 in the example
writes an <iframe> thats seems to be the problem. Take it out, and it works!

It doesn't give an document as object in return, but HTMLDocument instead!
And Peter, isn't that missing <iframe> object your problem in navigator.js??

Huh, what's that? That second part of my last comment shouldn't be in here.
That's an other bug I'm working on. Shit, I messed things up with copy/past,
sorry guys!
But to help you a bit further, that 59 line is using function t_flickdivs(vis).
That's in menu.js, as I told before. And that function seems to cause this problem!
Menu's are displayed with function t_popup() and is called after onmouseover. In
this function var t_aaben=id is the active menu number. So if you are in menu 2
and hover to menu 3, t_aaben gets this id set to 3.

Menu's are hidden with function t_ud() and is called after onmouseout. This
function is a bit more complicated then t_popup(). It's calling a bunch of other
functions to do the job. Function t_flickbanner(vis) is one of them. This
function is calling t_frame = document.getElementByID() tons of times, and
there's no check if t_frame==null. I changed this function in order to store the
t_frame after the first time, it's always the same, so why call getElementByID
ton and tons of times? Anyway, Because it's always the same, so why call
getElementByID ton and tons of times? So then it's never setting things like this:
		m.style.visibility=(vis)?"visible":"hidden"
		m.style.left=m_xPos[id-1]+t_offsetW
		m.style.top=m_yPos
		m.onmouseover=t_over
		m.onmouseout=t_ud

Function t_flickdivs(vis) is also called by t_ud() and also calling
getElementByID tons and tons of times. This seems to be the same problem.

Note: members.v3space.com/xxxxxxx (where xxxxxx is a membername) is having the
same problems! Neil Pryde and I are working on that problem right now. It seems
related. Thats why that second part of my was in that other comment, now you
know. There report is: "Out <iframe> get fucked up after a call to
getElementByID() and getElementsByTageName()". Sorry not my words!!

In response to Dean Tessman's question: Yes, that's the one.
Are you saying this might be a dup of that bug "Double right-clicking on a page
disables keyboard"? You don't have to use a mouse buttons to trigger this bug!
Or is this related to that bug? Please clarify!
It might be a dup.  What I said, though, was that it "might be related" since
both bugs seem to involve event-handling (and consequently, focus) screw-ups.
Just trying to be helpful.

That's pretty much exactly what I already said, though.  What more
"clarification" might one be looking for?


Law, do you know www.v3space.com? A lot of people are using this site, thats the
reason we like to know what is hapening with here! And Law, NP => :)
Keywords: dom0
->saari for consideration
Assignee: hyatt → saari
This assertion could be the key to why commands are generally hosed lately.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
resolving as wfm using today's builds on Win98 and Linux
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
now I'm getting the view source window and the following in the console:
"focusedWindow = null"
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: