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
Last Resolved: 18 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. :)
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...
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 => :)
->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
resolving as wfm using today's builds on Win98 and Linux
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
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.