64212 - unable to view source after mousing over DHTML menu

Status: VERIFIED WORKSFORME

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

Description

[Henrik Gemal]

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

Comment 1

[sairuh (rarely reading bugmail)]

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?

Comment 2

[Joshua Eichorn]

Works for me using 2001010108 Linux

Comment 3

[Henrik Gemal]

sometimes this works for me too. But I can also reproduce the error. Will try to 
find other site...

Comment 4

[Henrik Gemal]

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...

Comment 5

[sairuh (rarely reading bugmail)]

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?]

Comment 6

[Henrik Gemal]

could be a win thing only?
Used the win32-installer.
Got build 2001010220

So you're logged into the site with the user mozilla?

Comment 7

[sairuh (rarely reading bugmail)]

yep, i used mozilla/mozilla... i'll try it again with win32, once a verification
becomes available today. :)

Comment 8

[Henrik Gemal]

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????

Comment 9

[HJ]

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> ??

Comment 10

[HJ]

CC:ing sorry for the SPAM

Comment 11

[sairuh (rarely reading bugmail)]

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...

Comment 12

[HJ]

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!

Comment 13

[Henrik Gemal]

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.

Comment 14

[sairuh (rarely reading bugmail)]

exactly!

cc'ing prashant and jst who might know more... but which component should this
reside in?

Comment 15

[sairuh (rarely reading bugmail)]

first guess: over to DOM 0...

Comment 16

[Bill Law]

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... 

Comment 17

[Peter "jag" Annema]

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.

Comment 18

[Johnny Stenback (:jst)]

This smells like hyatt's code, reassignin to hyatt.

Comment 19

[HJ]

Attachment: Testcase/example, I love this kind of things!

Comment 20

[:deanis74]

Law: Were you thinking of bug 30841?

Comment 21

[HJ]

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??

Comment 22

[HJ]

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!

Comment 23

[HJ]

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!!

Comment 24

[Bill Law]

In response to Dean Tessman's question: Yes, that's the one.

Comment 25

[HJ]

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!

Comment 26

[Bill Law]

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?

Comment 27

[HJ]

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 => :)

Comment 28

[Peter Trudelle]

->saari for consideration

Comment 29

[saari (gone)]

This assertion could be the key to why commands are generally hosed lately. 

Comment 30

[Peter Trudelle]

resolving as wfm using today's builds on Win98 and Linux

Comment 31

[Henrik Gemal]

now I'm getting the view source window and the following in the console:
"focusedWindow = null"