34667 - javascript: URLs in HREFs fail with JS error

Status: VERIFIED DUPLICATE of bug 31818

(Core :: DOM: Core & HTML, defect, P3)

Description

[khawk]

This site uses DHTML that is written for both NN4 and IE4+. In Milestone 14 for
win32 and preview 1, they allow the user to click on the hidden links. And even
when you click on them nothing happens if it is a "javascript:" tag. This
renders various popup menu's functionless. The site conforms to W3 standards to
the best of my knowlege.

Here is a sample of the link that should work:
<a href="javascript:drawMenu('externalMenu')">External links</a>
and the javascript function is:

function drawMenu(location) {
  if (is.dhtml) {
    destroyMenus()
    show(location)
  }
}
function show(obj) {
  var theObj = getObject(obj)
  theObj.visibility = "visible"
}

Comment 1

[troy]

Event related so reassigning to joki

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The links are now clickable.  However, the javascript: is producing a JS error
-- it seems getObj is returning either null or something that has no
properties.  (Could the problem be the use of 'location' as a variable name, or
is it something more mundane?)  Moving to DOM Level 0 component and confirming
bug and retitling, etc.

Comment 3

[khawk]

Perhaps this bug may have to do with the actual eval() javascript function?

the eval statement should return the object document.objectname where objectname
is the same as the ID tag in the html code. that object is doing nothing, and as
reported by [e-mail] the javascript error returned was that the
object had no properties. The object in question is a <div> and it should at
least have the properties of top and left (I would think). So is the eval
function returning a non-existant object?

Invisible links that are clickable was fixed in M15. No problem there. Hope this
can be of help. Only tested on Win32 platform with M15.


if(is.ns4 || is.ns6) {
  doc = "document.";
  sty = "";
  htm = ".document";
  window.captureEvents(Event.CLICK);
  window.onclick = netscapeCapture
  SetupMenu();
} else if(is.ie4 || is.ie5) {
  doc = "document.all.";
  sty = ".style";
  htm = "";
  SetupMenu();
}


function netscapeCapture() {
  destroyMenus()
  return true;
}

function getObject(obj){
  var theObj
  if(typeof obj == "string") {
    theObj = eval(doc + obj + sty)
  } else {
    theObj = obj
  }
  return theObj
}

function show(obj) {
  var theObj = getObject(obj)
  theObj.visibility = "visible"
}

Comment 4

[Johnny Stenback (:jst)]

Not a beta2 stopper

Comment 5

[Johnny Stenback (:jst)]

Not a beta2 stopper

Comment 6

[ekrock's old account (dead)]

Nominating nsbeta2. We have to start drawing a line on DOM0 backward 
compatibility; these bugs are supposed to be a high priority for nsbeta2 per the 
beta2 criteria.

Comment 7

[ekrock's old account (dead)]

Turns out that lack of support for javascript: URLs (bug 34667 or bug 38537, not 
precisely sure which) blocks Andrei from implementing the default plug-in. (The 
one that's invoked when the user lacks the necessary plug-in to see content.) 
Raising severity to blocker and setting milestone to M17. 

The other thing to keep in mind is that since javascript: URLs in the Location 
bar and HREFs aren't working, the JavaScript they would normally execute is not 
running on Mozilla/Netscape 6, so we're not exposing other bugs that will be 
revealed when that JavaScript is run. Nor are we enabling content developers to 
notice when they're using non-standards-compliant JavaScript in those URLs that 
they need to upgrade.

As a result, this bug should be a hard nsbeta2 stopper.

Comment 8

[rickg]

This is needed for beta2; giving PDT approval.

Comment 9

[vidur (gone)]

The following patch fixes a crash I saw associated with javascript: URLs and 
the fact that javascript: URLs are sometimes invoked multiple times. The 
remaining problems are addressed by bug 31818.

Index: nsJSProtocolHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp,v
retrieving revision 1.46
diff -r1.46 nsJSProtocolHandler.cpp
288c288,294
<         *aInputStream = str;
---
>         if (NS_SUCCEEDED(rv)) {
>             mResult = nsnull; // XXX Whackiness. The input stream takes owners
hip
>             *aInputStream = str;
>         }
>         else {
>             *aInputStream = nsnull;
>         }
411a418,422
>     // If the resultant script evaluation actually does return a
>     // value, we treat it as html.
>     if (NS_SUCCEEDED(rv)) {
>         rv = channel->SetContentType("text/html");
>    

Comment 10

[Johnny Stenback (:jst)]

I just checked in Vidurs patch that fixes part of this problem, the rest of this
bug should be coverd by bug 31818 so I'm marking this as a dup of that bug.


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

Comment 11

[Prashant Desale]

Dup verified.