32982 - context-click on client-side imagemap; doesn't pass base URL to new window (?)

Status: VERIFIED DUPLICATE of bug 19523

(Core :: DOM: Navigation, defect, P3)

Description

[John Morrison]

Overview Description:
  If you do a context-click, "open link in new window", on an image
  that is a client-side imagemap (usemap=#foo), the current base url
  is not passed on to the new window

 e.g., page at http://www.nytimes.com/, and <area href="foo.html"> :
 the new window will attempt to open http:///foo.html

Steps to Reproduce:
1) load the abbreviated testcase (to follow)
2) context-click on the image, and select "open link in new window"
3) (for comparison, also try a select-click -- that works)

Actual Results:
  New window opens, loading "http:///somelink.html"

Expected Results:
  New window opens, loading "http://www.nytimes.com/somelink.html"

Reproducibility: always

Build Date & Platform Bug Found:
  2000032206 win98 beta1

Additional Builds and Platforms Tested On:
  2000032211 win98 trunk
  2000032206 linux beta1
  2000032209 linux trunk


Additional Information:
  There are a number of imagemap bugs in bugzilla, but none describing this
  condition (as far as I could see). Note that a simple click (select-click)
  on the imagemap will take the browser to the right location.

  Also, the example attachment uses a BASE HREF, but that is not a factor --
  the live site at www.nytimes.com exhibits the same problem.

  I've set this to XPApps, on a guess that it is the app code that is not
  passing on the right info to the new browser window.

Comment 1

[John Morrison]

Attachment: testcase; simple clientside imagemap (from nytimes)

Comment 2

[Paul MacQuiddy]

spam: qa contact to [e-mail]

Comment 3

[verah (gone)]

Reassigning as per Don

Comment 4

[John Morrison]

I just noticed that this bug was severely sidetracked (this isn't embedding, 
travis is gone, and this should be fixed for nsbeta2 (nominating)). 

The front page of the NY Times, and the simple attached testcase are now 
throwing an exception when you context-click on the left-hand imagemap:

Entry at index 1 is www.nytimes.com
JavaScript error:
 line 0: uncaught exception: [Exception... "<no message>"  code: "-2142568438" 
nsresult: "0x804b000a (<unknown>)"  location: 
chrome://navigator/content/nsContextMenu.js Line: 282"]

Document: Done (9.23 secs)
*** check number of frames in content area
Document http://www.nytimes.com/ loaded successfully
JavaScript error:
 line 0: contextMenu has no properties

JavaScript error:
 line 0: contextMenu has no properties


Passing on to law for a look; nominating nsbeta2 as this is a generic bit of 
functionality that is used on many web sites, and on top of that, this 
particular web site has, um, a fairly web readership.

Comment 5

[John Morrison]

er, fairly _wide_ readership.

Comment 6

[Bill Law]

Crap.

This bug started out as a dup of bug 19523 which addresses the basic problem 
with context menus for client-side image maps.

However (and this is where things get a little more complicated), the most 
recent comments refer to a JavaScript exception.  After some investigation, I 
find the error occurs in the isLinkSaveable function of nsContextMenu.  
Specifically, JS is throwing this exception when that code simply tests the 
value of "link.protocol".

It shouldn't do that, I don't think.  "link" is [object HTMLAreaElement] which 
doesn't have a "protocol" property.  But the test is for existence of that 
property (and if it fails, the code uses link.href instead, a property which 
HTMLAreaElements *do* have).

I've decided to open a new bug on that problem (bug 44115).

I'm closing this as a dup of 19523.

Everybody got it?

*** This bug has been marked as a duplicate of 19523 ***

Comment 7

[John Morrison]

Got it.

Comment 8

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2.