That nsContextMenu.js code is making some bad assumptions and needs to be fixed. if (window._content.HTTPIndex == "[xpconnect wrapped nsIHTTPIndex]... --- can be changed to --- if(window._content.HTTPIndex instanceof Components.interfaces.nsIHTTPIndex... I'm not clear why this code would want to be checking for the 'constructor' property. Any JSObject that has Object.proto is into prototype chain would have that property. My fix to bug 64111 included correcting the oversight that the JSObject part of xpconnect wrapped natives did not have a __proto__. Now they do (like most every other JSObject). The DOM conversion to use xpconnect will require this soon enough anyway. Was this check there only to try to verify that you were looking at an xpconnect wrapped native?
Assignee: jband → blakeross
Tracing back through bonsai (The file has been moved), this was checked in by email@example.com for bug 32357. > Was this check there only to try to verify that you were looking at an > xpconnect wrapped native?
The code in question was just a reasonable attempt to verify that the content area was a ftp/file directory listing internally generated by the browser rather than some random web page. I don't recall the exact reasoning but I think it was to try to avoid being spoofed by a web page with conventional (non-xpconnect) JS. There's similar code elsewhere to handle charsets for such directory listings, BTW. Both of those need to change now. It sounds like the "instanceOf" operator is the right way to do it.
> There's similar code elsewhere to handle charsets for such directory listings, BTW. Where? Isn't everything in ASCII? They're uris, and escaped/unescaped. If charsets are a problem, I'll test my gopher stuff against it if someone can point me to something which triggers that code. So the three tests can be replaced with the single instanceOf test? Patch later tonight.
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#1120 That's to properly deal with file names that aren't plain ASCII, or so I believe. I think the instanceOf test seems to be the right solution. That's what the bogus code was trying to do.
Why is this mine? I didn't write that...
Assignee: blakeross → pinkerton
I assigned it to you because cvs blame showed you as the person who checked in the lines to nsContextMenu.js. I now see in the cvs log that you were 'extract'ing it from somewhere else. It's fine with me if you reassign this. Maybe Bill Law will volunteer to fix the cases - he seems to have a handle on things.
I'll take it.
Assignee: pinkerton → law
Priority: -- → P1
Target Milestone: --- → mozilla0.8
I did the patch, then checked my mail... Attached, and it fixed the problem for ftp, and html still works. I haven't tested on non-ASCII file names - anyone?
It looks like a strict warning will still be thrown if _content.HTTPIndex is null; you might want to keep the |"HTTPIndex" in _content| check. Also, why the window._content/_content inconsistency?
fix checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.