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

VERIFIED DUPLICATE of bug 19523

Status

()

Core
Document Navigation
P3
normal
VERIFIED DUPLICATE of bug 19523
18 years ago
18 years ago

People

(Reporter: John Morrison, Assigned: Bill Law)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-], URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 6823 [details]
testcase; simple clientside imagemap (from nytimes)

Comment 2

18 years ago
spam: qa contact to jrgm@netscape.com
QA Contact: paulmac → jrgm

Comment 3

18 years ago
Reassigning as per Don
Assignee: don → travis
Component: XPApps → Embedding: Docshell
QA Contact: jrgm → travis

Updated

18 years ago
Keywords: embed
(Reporter)

Comment 4

18 years ago
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.
Assignee: travis → law
Keywords: embed → nsbeta2
QA Contact: travis → jrgm
(Reporter)

Comment 5

18 years ago
er, fairly _wide_ readership.
(Assignee)

Comment 6

18 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 7

18 years ago
Got it.
Status: RESOLVED → VERIFIED

Comment 8

18 years ago
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [nsbeta2-]
You need to log in before you can comment on or make changes to this bug.