Closed Bug 200690 Opened 21 years ago Closed 21 years ago

javascript window does not open when I click on link

Categories

(Core :: DOM: HTML Parser, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: rdingman, Assigned: harishd)

References

()

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

In the page at
http://www.carlton-bates.com/cb/invsrch/invframe.asp?srchfield=stkmfgpart&vendor=ALL&codevend=ALL&sval=3433-6002&submit1=Go
when I click on the "Part Location Availability" hyptertext, nothing happens.

The JavaScript console shows the following:
Error: createWindow is not defined



Reproducible: Always

Steps to Reproduce:
1.Go to web site
2.Click on "Part Location Availability" (right half of page, 1/4 way down)


Actual Results:  
Nothing happens

Expected Results:  
Window should pop up in upper left corner.

If I use Netscape 4.79 for Windows or Linux, the window opens. However, If I use
Mozilla 1.0.2 for Windows (Windows 2000), the window opens.

Not sure if this is actually a Mozilla bug or a problem with the site's
javascript. Any suggestions?
Sorry. When I use Mozilla 1.0.2 for Windows, the window does NOT open.
Sorry, but I can't find such "Part Location Availability" link.
Sorry again. Click on the part number, 3433-6202. That opens the frame in which
the "Part Location Availability" link exists.

OR 

go directly to this page (the same frame):

http://www.carlton-bates.com/cb/invsrch/flocresult.asp?svend=MM&Start=0&Offset=10&srchfield=stkmfgpart&pmvndstkn=MM%2D3433%2D6002&pumdbn=276148

Thanks
Right - let me summarize here:

STEPS TO REPRODUCE
1. Go to the URL in the original report above
2. Click on the part number hyperlink at the extreme left (3433-6002)
3. This brings us to a page with the "Part Location Availability" hyperlink
5. The link is in the following frame:
http://www.carlton-bates.com/cb/invsrch/flocresult.asp?svend=MM&Start=0&Offset=10&srchfield=stkmfgpart&pmvndstkn=MM%2D3433%2D6002&pumdbn=276148

6. The source for that frame shows the createWindow() function:

<!-------------------- JAVASCRIPT SECTION BEGINS HERE ------------------->
<script language="JavaScript">
<!-- Hide script from old browsers

function createWindow(cUrl,cName,cFeatures) {
  var xWin = window.open(cUrl,cName,cFeatures)

}

// End hiding script from old browsers -->

</script>
<!-------------------- JAVASCRIPT SECTION ENDS HERE ------------------->



The problem is that in Mozilla, this section is showing up in View Source
as commented out. That is why we get the error that Bob reported above:

             Error: createWindow is not defined

IE6, on the other hand, does not treat this as a commented section, and
so the function is defined in IE6.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to HTML Parser component. I know that it is illegal 
according to the W3C to have two consecutive dashes inside an
HTML comment, like the site does:

<!-------------------- JAVASCRIPT SECTION BEGINS HERE ------------------->


But IE6 seems to tolerate this -
Assignee: rogerl → harishd
Component: JavaScript Engine → Parser
QA Contact: pschwartau → dsirnapalli
A reference for HTML comments is given here:
http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.4

Reduced testcase #1 uses incorrect HTML comments, the way the site does:
<!-------------------- JAVASCRIPT SECTION BEGINS HERE ------------------->

Reduced testcase #2 uses correct HTML comments, like this:
<!--                   JAVASCRIPT SECTION BEGINS HERE                  -->


Both testcases work in IE6. In Mozilla trunk binary 2003040404,
only the 2nd one works. The 1st gives an error in the JS Console.

Because of the site's mistake, we might assign this bug to Evangelism
and get the site to correct their HTML. On the other hand, IE6 tolerates
this mistake: can we or do we want to emulate that?
OS: Linux → All
Note: both the site and the testcases use this doctype:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN//3.2">

If we remove this, Mozilla tolerates the incorrect HTML comments.
I would say this is a clear Evangelism bug - do others agree?
I haven't been following the threads of Evangelism, but for what it's worth,
Netscape 4.79 also accepted the bad HTML. That doesn't make it correct, but it
gives some other fairly weighty precedence, I would think.

In any case, thanks for your analysis!
I contacted the site webmaster and he has corrected the HTML code.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Bob: thank you for contacting the webmaster, and for this report -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: