Image map <area> context menu should be for a linked image, not for a link

NEW
Unassigned

Status

19 years ago
9 months ago

People

(Reporter: the-enigman, Unassigned)

Tracking

({helpwanted, top100})

Trunk
x86
Other
helpwanted, top100

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

19 years ago
Overview Description:
The View Image context menu item is not appearing in the context menu for the
header image.

Steps to Reproduce:
1)load given url.
2)right-click "News.Com" header image

Actual Results:
there is no View Image element in the menu

Expected Results:
a View Image item should appear.

Reproducibility:
always

Build Date & Platform Bug Found:
Build ID 2000032708, Win95

Additional Builds and Platforms Tested On:
none

Additional Information:
none
not xpmenus.
Assignee: pinkerton → law
Component: XP Toolkit/Widgets: Menus → XPApps

Comment 2

19 years ago
The reason the block-image menu item does not appear is because those items are 
not images.  If you look at the html for that page you will see that the 
news.com header image is not an image but rather html text fetched from yet 
another page.  Here's the html source for both the c/net red circle and the 
"news.com" that appear on the first orange line of this page:

<area shape="circle" coords="28, 27, 25" 
   href="/frontdoor/0-1.html?st.1003.1003-ron.yhed.1">
<area shape="rect" coords="53, 0, 215, 54"    
href="/news/0-1002.html?st.ne.1003.hdgif.1002">
Status: UNCONFIRMED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID

Comment 3

19 years ago
The HREF parameter of the AREA tag specifies the link to follow when that 
portion of the map is clicked, not any sort of source fopr the map.  The map 
name "redball" that you're referring to in this page is used a few lines down, 
as part of an IMG tag.  

Looks to me like there should be a View Image (as per the original bug report) 
context menu item and this bug should be reopened.  Oh, and such a menu item 
appears in 4.x.

Comment 4

19 years ago
It appears that the problem is that clicking on a client-side image map now 
associates the <area> element with the context menu rather than the underlying 
<img>.

On the one hand, this is good because it might provide a means of fixing a 
different bug relating to image maps not surfacing their links properly.  
Unfortunately, I'm not sure how to get from the <area> back to the image.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 5

19 years ago
Sorry, I guess I jumped the gun here in closing it out as invalid.  First, I 
didn't see that the image tag was actually a few lines lower and, second, I 
looked quickly and thought that the bug was assigned to me.

The good news is that I'm glad that the bug is not assigned to me because I have 
no idea how to fix it. ;-)
Confirming - but if morse can't fix it, well, who can? ;-)

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
strangely, this wfm...then again, i'm using today's commercial bits --perhaps
this is mozilla only?

another easy place to check (just another testcase) would be:

1. go http://www.mozilla.org/
2. move mouse over to topbanner, specifically, over Mozilla's grinning red head.
3. bring up context menu.

result: i see View Image in the context menu (mac, linux and winNT).

Comment 8

19 years ago
I'm going with the WORKSFORME.  I think the "bug" I noted previously (see my 
comment of 03/28) was a temporary thing.
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 9

19 years ago
I'm testing this with the 2000051012 build...the View/Save image items are 
showing up in the menu for that image, but they're not doing anything. Strange, 
because for the "advertisement" image on the top right-hand column of that same 
page, they're working fine. Is that another bug or what?

Comment 10

19 years ago
There are problems (already reported and I've got fixes for some of them) with 
certain, more convoluted HTML.  E.g., client side image maps don't work.  Also, 
images coded via <object> tags don't work.  Also, certain images (such as 
background images defined vis CSS) and specified via relative URLs don't work 
properly.

That said, I'm still reopening this bug because there's definitely something 
funky going on with the banner on www.news.com.  The *first* time I right click 
on the CNet circle, I get link options (but it doesn't seem to work).  But at 
some point this stops working (the links-related items disappear).  Also, "Open 
link in new window" does work successfully for at least some other image-links.

Somethings horked so I'll investigate more with today's build.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 11

18 years ago
nav triage team:

Funny things still happen on this page, but not a beta stopper. Marking nsbeta1-
Keywords: nsbeta1-
Keywords: helpwanted
Summary: View Image not appearing in conext menu for an image → View Image not appearing in context menu for an image

Comment 12

18 years ago
OK, just to make sure everyone's on the same page, this bug as originally
reported is still an issue.  If you go to news.cnet.com and right-click on the
red CNet logo in the top-left corner, the context menu doesn't contain a "Save
Image As" menu item.

Adding a bit to the summary.
Summary: View Image not appearing in context menu for an image → View Image not appearing in context menu for an image in an <area> map tag
*** Bug 65106 has been marked as a duplicate of this bug. ***
adjusting summary [since i dup'd bug 65106, which smells like this one ;) ].
Summary: View Image not appearing in context menu for an image in an <area> map tag → View Image, Save Image, Block Image not appearing in context menu for an image in an <area> map tag

Comment 15

18 years ago
Another example from dup'ed bug 65106: go to http://www.yahoo.com/ and right-
click on the navigation bar at the top: whether View Image, Save Image and
Block Image appear depends on whether you clicked inside an <area> or not.
Of course other items appear instead, like "open link in new window" or "save
link as".

Comment 16

18 years ago
Resummarizing for clarity, and changing URL to a more obvious example. Original 
URL was <http://news.cnet.com/news/0-1003-200-1592142.html?tag=
st.ne.1002.tgif?st.ne.fd.gif.f>.
Keywords: 4xp, top100
Summary: View Image, Save Image, Block Image not appearing in context menu for an image in an <area> map tag → <area> context menu should be for a linked image, not for a link

Comment 17

18 years ago
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future

Comment 18

18 years ago
*** Bug 78902 has been marked as a duplicate of this bug. ***

Comment 19

18 years ago
is bug 88216 related somewhat?

Comment 20

18 years ago
*** Bug 88216 has been marked as a duplicate of this bug. ***

Comment 21

17 years ago
*** Bug 92724 has been marked as a duplicate of this bug. ***
*** Bug 113385 has been marked as a duplicate of this bug. ***
*** Bug 101550 has been marked as a duplicate of this bug. ***
Depends on: 75338

Comment 24

17 years ago
Created attachment 77442 [details] [diff] [review]
proposed hack

With this hack, you have both image and link context menu item.

Advantages:
Works (hope so)
Better than no image context menu at all.

Disadvantages:
Probably slow on large pages (it searches for the image that corresponds to the
map)
May not work if two images share the same map (i never saw this, since it makes
not much sense)

Comments of all kind welcome.

Comment 25

17 years ago
Created attachment 78127 [details] [diff] [review]
updated to new version of nsContextMenu.js
Attachment #77442 - Attachment is obsolete: true
FWIW, while it's undoubtedly rare, it's not unreasonable and in certain cases
even useful to associate a single imagemap (i.e., the hotspots and their link
targets) with more than one image.

Comment 27

17 years ago
*** Bug 137242 has been marked as a duplicate of this bug. ***
blake, any ideas?

Comment 29

17 years ago
I think that Bug 140172 and Bug 83047 are dupes of this bug.  Could someone
check into marking those as dupes of this bug, though, if that's the right thing
to do?
*** Bug 140172 has been marked as a duplicate of this bug. ***
As a note, the image --> map relationship is many to one.  That is, multiple
images could all use the same imagemap....
*** Bug 143571 has been marked as a duplicate of this bug. ***

Comment 33

17 years ago
*** Bug 145733 has been marked as a duplicate of this bug. ***

Comment 34

17 years ago
*** Bug 146085 has been marked as a duplicate of this bug. ***

Comment 35

17 years ago
not sure if 153747 is a duplicate of this bug.
the context menu of <img usemap> is same as the context menu of
<a>text</a> instead of <a><img></a> --> result save-image-as and
the like missing.

Comment 36

17 years ago
*** Bug 153747 has been marked as a duplicate of this bug. ***
*** Bug 153872 has been marked as a duplicate of this bug. ***
*** Bug 154590 has been marked as a duplicate of this bug. ***

Comment 39

16 years ago
Mozilla 1.0 RC3 buld 20020522306 on Win95.

URL: http://www.dn.se/

right-click on logo, top left. Context menu that appears is that of a normal
text link, while it is clearly and image.

Tested with Netscape 4.75, the correct context menu appears.

First assumed it was Javascript blocking context menu, but same result was
achieved with Javascript disabled.

Comment 40

16 years ago
*** Bug 159691 has been marked as a duplicate of this bug. ***
*** Bug 162975 has been marked as a duplicate of this bug. ***
*** Bug 163928 has been marked as a duplicate of this bug. ***
Keywords: topembed

Comment 43

16 years ago
->saari, topembed+, I'm dorking with this for embedding
Assignee: law → saari
Status: REOPENED → NEW
Keywords: topembed → topembed+
Target Milestone: Future → mozilla1.2beta
*** Bug 180505 has been marked as a duplicate of this bug. ***

Comment 45

16 years ago
nsIContext menu listener has flags that should be OR'd together to determine
what options are available. I think this works in an embedding case so I'd
topembed- just for mozilla.
Assignee: saari → sgehani
Target Milestone: mozilla1.2beta → mozilla1.3beta

Comment 46

16 years ago
Created attachment 115000 [details]
testcase

Simple control and test case.

"Context Menu | Save Image As..." is unavailable on usemap.

Comment 47

16 years ago
removing topembed since this works for embeddors
Keywords: topembed+

Comment 48

15 years ago
Is this different from bug 60561?
Summary: <area> context menu should be for a linked image, not for a link → Image map <area> context menu should be for a linked image, not for a link

Comment 49

15 years ago
*** Bug 60561 has been marked as a duplicate of this bug. ***
Assignee: sgehani → jag
Priority: P3 → --
QA Contact: sairuh → pawyskoczka
Target Milestone: mozilla1.3beta → ---

Comment 50

15 years ago
Is, or should there be, a property of a mouse event over an area that shows
which image the mouse is actually over?
*** Bug 234383 has been marked as a duplicate of this bug. ***
*** Bug 255217 has been marked as a duplicate of this bug. ***

Comment 53

14 years ago
*** Bug 208222 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
Created attachment 172906 [details] [diff] [review]
patch

With this patch, the context menu is for a linked image when there is only one
object (<object> or <img> tag) using the map.

I also fixed this javascript strict warning in the file metadata.js:
Warning : assignment to undeclared variable imgType
Attachment #172906 - Flags: review?(jag)
The context menu should be for both the image and the link. Any other way seems
broken, and will get bugs filed against it.

Comment 56

14 years ago
> The context menu should be for both the image and the link. Any other way seems
> broken, and will get bugs filed against it.

That is much right, when seeing the context menu... some users expect to see
link options and the others expect to see image options 
Attachment #172906 - Flags: superreview?(bzbarsky)
Comment on attachment 172906 [details] [diff] [review]
patch

>Index: xpfe/communicator/resources/content/nsContextMenu.js
>+             } else if ( this.target.localName.toUpperCase() == "AREA") {

I know this is the style of the file, but it's pretty wrong (since you can have
random XML elements named "area").  I think you want something more like:

  } else if (this.target instanceof HTMLAreaElement) {

or perhaps a check for instanceof HTMLElement followed by the localname check.

>+                 while ( map && map.nodeType == map.ELEMENT_NODE && !(map.localName.toUpperCase() == "MAP") )

Similar here.

>+                 var mapuri = "#" + map.getAttribute("name");
...
>+                     if (list.item(i).getAttribute("usemap") == mapuri) {

We support "usemap" attributes that don't have a starting '#', last I
checked....  Also, in XHTML we use the "id" attribute of <map>, not the "name"
attribute.  See
<http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsImageMapUti
ls.cpp#51>.  So this check is wrong...

What if two images point to the same imagemap, but one of them has a bogus
"src", so it's replaced by alt text?  Would you still want to bail out of here
claiming we're not on an image?

>+                         if (list.item(i).getAttribute("usemap") == mapuri) {
>+                             if (this.onImage) {
>+                                 this.onImage = false;
>+                                 this.imageURL   = "";
>+                                 break;

(for <object>).  What if it's not an image object?

>+                                        list.item(i).type.substring( 0, 6 ) == "image/") {

What if it's an image object but has no type attribute set?

In all of these cases, I think you want to check whether the list item actually
has an image (via nsIImageLoadingContent).  If it doesn't, it's not an image
for our purposes, I think.

>Index: browser/base/content/browser.js

Same comments apply.

>@@ -4338,7 +4378,7 @@
>-        if ( type.substring( 0, 6 ) == "image/" && data) {
>+        if (type && type.substring( 0, 6 ) == "image/" && data) {

And this code, both before and after the change, is completely and utterly
wrong.	It looks like the fix for bug 245660 will clean this stuff up quite
nicely; I'd get that in before working on this patch more....
Attachment #172906 - Flags: superreview?(bzbarsky) → superreview-

Comment 58

14 years ago
I'm seeing the opposite problem at http://americas-fair.com/  with Mozilla 1.8b2
build 2005053111, Mac OS X 10.3.8  The links don't work and the context menu
only shows the image related choices.  The links work ok in Firefox.
Created attachment 252192 [details] [diff] [review]
patch v2
Attachment #172906 - Attachment is obsolete: true
Attachment #252192 - Flags: superreview?(bzbarsky)
Attachment #172906 - Flags: review?(jag)
Comment on attachment 252192 [details] [diff] [review]
patch v2

Please get r= from the module owner before asking for sr?

In any case, this patch doesn't actually fix the bug it's attached to (since that's a Suite bug and this is a Firefox-only patch).
Attachment #252192 - Flags: superreview?(bzbarsky)
Comment on attachment 252192 [details] [diff] [review]
patch v2

(In reply to comment #60)
> In any case, this patch doesn't actually fix the bug it's attached to (since
> that's a Suite bug and this is a Firefox-only patch).
> 
I plan to do nearly the same patch for the suite once the firefox part will be reviewed.
Attachment #252192 - Flags: review?(mano)
Comment on attachment 252192 [details] [diff] [review]
patch v2

>Index: browser-context.inc
>===================================================================
>RCS file: /cvsroot/mozilla/browser/base/content/browser-context.inc,v
>retrieving revision 1.29
>diff -u -r1.29 browser-context.inc
>--- browser-context.inc	1 Dec 2006 12:33:29 -0000	1.29
>+++ browser-context.inc	21 Jan 2007 02:58:16 -0000
>@@ -92,7 +92,7 @@
>       <menuitem id="context-copyimage"
>                 label="&copyImageCmd.label;"
>                 accesskey="&copyImageCmd.accesskey;"
>-                oncommand="goDoCommand('cmd_copyImageLocation');"/>
>+                oncommand="gContextMenu.copyImageLocation();"/>
>       <menuseparator id="context-sep-copyimage"/>
>       <menuitem id="context-saveimage"
>                 label="&saveImageCmd.label;"
>Index: nsContextMenu.js
>===================================================================

>+  copyImageLocation: function() {
>+    var clipboard = Cc["@mozilla.org/widget/clipboardhelper;1"].
>+                    getService(Ci.nsIClipboardHelper);
>+    clipboard.copyString(this.imageURL);
>+  },

What's this purpose of this change?
(In reply to comment #62)
> >-                oncommand="goDoCommand('cmd_copyImageLocation');"/>
> >+                oncommand="gContextMenu.copyImageLocation();"/>
 
> >+  copyImageLocation: function() {
> >+    var clipboard = Cc["@mozilla.org/widget/clipboardhelper;1"].
> >+                    getService(Ci.nsIClipboardHelper);
> >+    clipboard.copyString(this.imageURL);
> >+  },
> 
> What's this purpose of this change?
> 

I made this change because cmd_copyImageLocation didn't work when the image was actually an <area>.
See http://lxr.mozilla.org/seamonkey/source/layout/base/nsDocumentViewer.cpp#2516 and
http://lxr.mozilla.org/seamonkey/source/layout/base/nsDocumentViewer.cpp#3161
I see, shouldn't we add this functionality to nsDocumentViewer's implementation then?
Comment on attachment 252192 [details] [diff] [review]
patch v2

Cleaning review request for that reason. At the very least, making the "Copy Image" menuitem (in SeaMonkey) do the right thing would be kinda hard otherwise.
Attachment #252192 - Flags: review?(mano)
Duplicate of this bug: 318878

Comment 67

11 years ago
This bug is still a problem in the latest release of firefox (2.0.0.5). My example: http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/Manhattan+by+Night+-from+DUMBO+in+Brooklyn/.
It's an imagemap: Left-clicking on the right side of the picture scrolls to the next picture. If you right-click on the right side of a picture (or left side if it's not the first picture) in IE, you get the usual context menu for a picture. But in Firefox, you get the context menu for a link, so you can't save the picture. Very frustrating !
> This bug is still a problem 

That's why this bug is still open, yes...

Comment 69

11 years ago
My gosh.... It's been EIGHT whole years and Mozilla haven't managed to fix this little bug. This is the only reason why I use Microsoft Internet Explorer.

Please fix this very annoying bug.

Comment 70

11 years ago
I helped set up an online gallery using image maps and wondered why people kept saying they couldn't save images... seems 54% of the visitors are using Firefox nowadays according to the site's stats.

Comment 71

11 years ago
(In reply to comment #70)
> I helped set up an online gallery using image maps and wondered why people kept
> saying they couldn't save images... seems 54% of the visitors are using Firefox
> nowadays according to the site's stats.
> 

Mike, did you click on the example posted by biz@alaporte.net couple of posts above? Here's the link:

http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/Manhattan+by+Night+-from+DUMBO+in+Brooklyn/

Not all images have the "save image" option in the context menu. I often come across many images where the option to save the image is missing in FireFox, but it's there in Internet Explorer.
QA Contact: pawyskoczka

Comment 72

10 years ago
Oh great, Firefox 2 got updated officially to firefox 3 just now (27th Aug 2008), and this bug isn't fixed still. Looks like it never will be fixed.

Why is it that Internet Explorer correctly shows the "save picture as" when you hover your mouse over the right side of the picture in the <a href="http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/Manhattan+by+Night+-from+DUMBO+in+Brooklyn/
">link</a> above, yet firefox doesn't "see" the image.

Comment 73

8 years ago
Well, late 2010 and the bug is still here, in Firefox 3.6.12.

I'm in two minds about this bug. On the plus side, it makes it easy to block casual saving of images. But on the down side, EVERY OTHER browser allows right-click and save in such circumstances.

Also, I can't believe this issue is 10 years old! And no devs appear to have commented, so I guess they just don't care and this minor (but niggling) issue will never, ever be fixed.
I (In reply to Conquerz from comment #72)
> Oh great, Firefox 2 got updated officially to firefox 3 just now (27th Aug
> 2008), and this bug isn't fixed still. Looks like it never will be fixed.
> 
> Why is it that Internet Explorer correctly shows the "save picture as" when
> you hover your mouse over the right side of the picture in the <a
> href="http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/
> Manhattan+by+Night+-from+DUMBO+in+Brooklyn/
> ">link</a> above, yet firefox doesn't "see" the image.

I checked http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/Manhattan+by+Night+-from+DUMBO+in+Brooklyn/
on FF 15.0.1. 
Do you still see the issue ?

Comment 75

6 years ago
Yes, still broken.

http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_areamap

right-click on the Sun -- there's no "Save image as" option.
Created attachment 707642 [details]
Patch to fix cmd_CopyImageLocation issue

cmd_CopyImageLocation issue as per Comment #64

WIP Patch to get FF part fixed and Seamonkey subsequently
Attachment #707642 - Flags: feedback?
Created attachment 707643 [details] [diff] [review]
Patch to fix cmd_CopyImageLocation issue

cmd_CopyImageLocation issue as per Comment #64

WIP Patch to get FF part fixed and Seamonkey subsequently
Attachment #707642 - Attachment is obsolete: true
Attachment #707642 - Flags: feedback?
Attachment #707643 - Flags: feedback?
Attachment #707643 - Flags: feedback? → feedback?(bzbarsky)
Comment on attachment 707643 [details] [diff] [review]
Patch to fix cmd_CopyImageLocation issue

I would assume this doesn't compile.

What part are you looking for feedback on?
(In reply to Boris Zbarsky (:bz) from comment #78)
> Comment on attachment 707643 [details] [diff] [review]
> Patch to fix cmd_CopyImageLocation issue
> 
> I would assume this doesn't compile.
> 
> What part are you looking for feedback on?

I'll update the patch and may be a good idea to build on top of the previous patch by Florian.
That doesn't quite answer my question...
(In reply to Boris Zbarsky (:bz) from comment #80)
> That doesn't quite answer my question...

I was hoping to update my patch and ask for feedback then again.

So, for cmd_CopyImageLocation issue, I decided to write the detection code for <area> element and see if I can then pick the topmost image via nodesFromRect(as discussed before)
Then the content->GetHrefURI should've the right image loation.
I hope this's the right path so far, and what Florian meant in comment #63.
Comment on attachment 707643 [details] [diff] [review]
Patch to fix cmd_CopyImageLocation issue

Oh, I see.

That might work, but be careful to still get the right URI....

It might also work to do the "oh, it's an area, look for the image" processing in the JS part of this.
Attachment #707643 - Flags: feedback?(bzbarsky) → feedback+
I was going through nsContextMenu.js and a few files w.r.t this bug.
Kept coming back to nsContextMenu.js especially 
http://dxr.mozilla.org/mozilla-central/browser/base/content/nsContextMenu.js.html#l361 
Hence the documentviewer.cpp. will look at the js part.
(In reply to Boris Zbarsky from comment #82)
> It might also work to do the "oh, it's an area, look for the image"
> processing in the JS part of this.

Which API would you suggest would be most suitable? (It might be possible to get mouse coordinates, but it's also possible to open the context menu by tabbing to the area, so...)
Hmm, I forgot about that part.

How do we track our "real" tab position in the tabbing case?
My understanding is that we just tab through tabbable frames.

Comment 87

6 years ago
Not sure what you're asking but tab navigation in image maps is handled by nsFocusManager::GetNextTabbableMapArea.
Assignee: jag-mozilla → nobody

Comment 88

11 months ago
Hey!! Can I work on this?
Aruna,

this is a very old SeaMonkey bug. Just verify that it is still valid and attach a patch. Ask me or IanN_bugzilla for review.
You need to log in before you can comment on or make changes to this bug.