unable to view source after mousing over DHTML menu




18 years ago
18 years ago


(Reporter: bugzilla, Assigned: saari)




Firefox Tracking Flags

(Not tracked)




(1 attachment)



18 years ago
if you go to:
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?
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 2

18 years ago
Works for me using 2001010108 Linux

Comment 3

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

Comment 4

18 years ago
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...
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?]

Comment 6

18 years ago
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. :)

Comment 8

18 years ago
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

18 years ago
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

18 years ago
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...

Comment 12

18 years ago
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

18 years ago
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.

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
Component: XP Apps → DOM Level 0
QA Contact: sairuh → desale

Comment 16

18 years ago
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

18 years ago
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

Comment 19

18 years ago
Created attachment 21722 [details]
Testcase/example, I love this kind of things!

Comment 20

18 years ago
Law: Were you thinking of bug 30841?

Comment 21

18 years ago
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

18 years ago
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

18 years ago
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:

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

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

Comment 25

18 years ago
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

18 years ago
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

18 years ago
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

Comment 28

18 years ago
->saari for consideration
Assignee: hyatt → saari

Comment 29

18 years ago
This assertion could be the key to why commands are generally hosed lately. 
Target Milestone: --- → mozilla0.9


18 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 30

18 years ago
resolving as wfm using today's builds on Win98 and Linux
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME


18 years ago

Comment 31

18 years ago
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.