this is reminiscent of bug 74019 --but i'm not sure if it's the same exact thing, hence this bug. :) 1. go to an ftp site or directory view listing --best to go to one where the listing does *not* take up the entire viewer region [ie, no scrolling needed]. 2. make sure that no file or folder is selected or highlighted. 3. bring up context menu result: context menu with extra helpings! ;) will attach screenshot soon.
I don't see this. Are you getting js errors to the console when this happens? If so, then this is a symptom of bug 74539 - when the JS is invalid, all the possible entries in the context menu show for some reason. (That may be the reason for bug 74019) If you can reliably reproduce this, please add comments to 74539 :)
*** Bug 77022 has been marked as a duplicate of this bug. ***
I'll steal this from blake, and attach a patch.
Assignee: blakeross → bbaetz
Target Milestone: --- → mozilla0.9.1
URL is no longer an attribute on the URL element. So the loop ends up in the XULDocument, which doesn't have a getAttribute method, and so we get a js error, which causes the context menu to include all items. This is possibly related to some of my directory viewer changes, but may not be. blake, can I get an r=?
Status: NEW → ASSIGNED
sr=ben since it's just code movement, but you know this is going to break if the directory viewer changes to outliner...
Yeah - this entire block (which is only entered if we are an instanceof a directory viewer) will. There are a couple of other places as well in the code that assume the directory viewer is a tree IIRC.
Fix checked in. Note to QA - to verify this, you'll have to turn off the html ftp directory listing (which is now on by default), or use a file:/// url.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
vrfy fixed using opt comm bits: winnt - 2001.05.17.10 linux and mac - 2001.05.17.08
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.