A recent build (2000 031708) puts "block image from loading" into most context menus, including empty areas of a page, links, and images. What's worse, this new item at the top of the menu, and it's also not really clear what it does.
Assignee: cbegle → law
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets: Menus
Ever confirmed: true
QA Contact: asadotzler → sairuh
Well, this bug was fixed elsewhere, but I took the opportunity to clean up this new "image blocking code." There is, believe it or not, a method to the madness in nsContextMenu.js. 1. It is an object with a constructor. You don't need to add some bogus init routine call to the .xul to call CheckForBlockingImages. 2. The menu items are disabled/removed in a simple and consistent manner by way of the init<category>Items functions. It needn't be done out in left field. 3. There is a property showItem() that can be called to hide/show a menu item. You don't need to replicate the setAtribute( "style" ... ) mumbo-jumbo helter-skelter. 4. I made it look more like the rest of nsContextMenu just on general principles. 5. Item #4 on the checkin guidelines says to get module owner approval. I am the module owner for the navigator context menu (well, Ben is but he'd stick up for me :-).
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
"Block Image from Loading" now appears in the context menu only when the cursor is over an image (linked or w/o link). verified with the following opt comm bits: linux 2000.03.28.09 macOS 2000.03.28.10 winNT 2000.03.28.09
Status: RESOLVED → VERIFIED
The "elsewhere" that law was referring to was bug 32352. So these two bugs can be marked as dups if anybody cares to do so.
Oops, I meant to say that the "elsewhere" is bug 32459.
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.