[DOGFOOD][DEMO][4.xP] onclick event handler has side effect of changing doc contents when it shouldn't; handler function return false being ignored?

VERIFIED FIXED in M12

Status

()

Core
DOM: Core & HTML
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: ekrock's old account (dead), Assigned: vidur (gone))

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+][TESTCASE], URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
This bug is [DOGFOOD] because it breaks the XBDHTML presentation template used
for all of the marketing presentations about Gecko--including those we use in
front of audiences and need to work by 12/5 for XML Tech'99 and 12/7 for
Builder.com.

On WinNT4.0 SP3 using AppRunner 1999111108.

To repro:
1) open URL (this is a DHTML preso 3-frame frameset doc; frames are left
edge-midddle content area-right edge across page)
2) click right edge of page in white area above the "Goto"

EXPECTED:
3) onclick event handler for the transparent image you just clicked causes
center content frame to "page forward" to the next HTML file in sequence, with
no change to the appearance of the clicked image

ACTUAL:
3) onclick event handler for the transparent image you just clicked causes
center content frame to "page forward" to the next HTML file in sequence, *BUT*
the "document" displayed in the right frame changes to a directory listing for
/users/ekrock/publish/bugs/M10/htmlpreso/basefile/

Additional info:
A) If you repeat the same steps in M9 or Nav4.7, the code works as expected.
B) If you repeat these steps in a copy of the preso on your local hard disk,
instead of displaying the directory listing, that right frameset instead
displays a mysterious document with three columns whose headers are N..S..L..
If you then click on the left edge of the page, the left frameset seems to
change to that same mysterious document, and you can see that the headers are
Name Size Last ..
C) Analysis of code: the apparent cause is that "return false" from the onclick
method handler function (which should prevent the click on the image from having
an effect other than that of the JavaScript which has already been executed) is
being ignored:

i) Top level frameset document index.htm has three frames which point at the
documents prev.htm, start.htm, next.htm:

<FRAMESET MARGINHEIGHT=0 MARGINWIDTH=0 COLS="135, *, 66" BORDER=0 NORESIZE
onLoad="goto_slide(1, true)">
     <FRAME SRC=basefile/prev.htm NAME="prev" NORESIZE SCROLLING="NO"
MARGINWIDTH="0" MARGINHEIGHT="0">
     <FRAME SRC=basefile/start.htm NAME="slide" NORESIZE SCROLLING="NO"
MARGINWIDTH="0" MARGINHEIGHT="0">
     <FRAME SRC=basefile/next.htm NAME="next" NORESIZE SCROLLING="NO"
MARGINWIDTH="0" MARGINHEIGHT="0">
</FRAMESET>

ii) Here are the contents of next.htm, edited to remove comments for brevity:

<BODY bgcolor="#FFFFFF"><CENTER>

<A HREF="" onclick="return next_slide();">
<!--  onclick="return next_slide();" -->
<IMG SRC="spacer.gif" hspace=0 vspace=0 border=0 height=350 width=66>
</A>

<FORM name="gotoform" onsubmit="goto_slide(this.slidenum.value); return false">
<A HREF="javascript:goto_slide(document.forms['gotoform'].slidenum.value)">
<IMG SRC="goto.gif" hspace=0 vspace=0 border=0></A>
<INPUT name="slidenum" TYPE="text" SIZE=3></FORM>

</CENTER></BODY>

iii) When you click the transparent GIF image in next.htm, the onclick handler:
<A HREF="" onclick="return next_slide();">
... calls next_slide();

iv) next_slide() is defined in included .js file navbar.js. Here's the source of
navbar.js:

// navbar.js
// (Global variables are declared in slide.js.)
// Display previous/next slide in sequence, or goto other slide.

// 22 May 98: rewrite to calculate base index.htm directory URL and add
filename;
//            this eliminated need for caller_in_base_directory argument *and*
//            finally eliminated the occasional slide "Not found" error message!
// 20 May 98: add Help window code
// 10 April 98: IE4 compatibility added.

// This is a simplified version of the JavaScript Client Sniffer code
// found at
http://developer.nextscape.com/docs/examples/javascript/browser_type.html

// This is a simplified version of the JavaScript Client Sniffer code
// found at
http://developer.nextscape.com/docs/examples/javascript/browser_type.html

function Is ()
{   // convert all characters to lowercase to simplify testing
    var agt=navigator.userAgent.toLowerCase();

    // --- BROWSER VERSION ---
    this.major = parseInt(navigator.appVersion);
    this.minor = parseFloat(navigator.appVersion);

    this.nav  = ((agt.indexOf('mozilla')!=-1) && ((agt.indexOf('spoofer')==-1)
                && (agt.indexOf('compatible') == -1)));
    this.nav2 = (this.nav && (this.major == 2));
    this.nav3 = (this.nav && (this.major == 3));
    this.nav4 = (this.nav && (this.major == 4));
    this.nav4up = (this.nav && (this.major >= 4));
    this.nav5 = (this.nav && (this.major == 5));
    this.nav5up = (this.nav && (this.major >= 5));

    this.ie   = (agt.indexOf("msie") != -1);
    this.ie3  = (this.ie && (this.major < 4));
    this.ie4  = (this.ie && (this.major == 4));
    this.ie4up  = (this.ie  && (this.major >= 4));
    this.ie5  = (this.ie && (this.major == 5));
    this.ie5up  = (this.ie  && (this.major >= 5));

    this.opera = (agt.indexOf("opera") != -1);

}

var is = new Is();

// HACK: work around fact that Nav5 M5 doesn't support alert()
var nav5SupportsAlerts = false;

// Go to slide number slide_num.
function goto_slide(slide_num)
{       var indexURL = top.location.href; // get URL of top-level frameset doc
        var baseURL = indexURL.substring (0, indexURL.lastIndexOf("/") + 1);
	if(slide_num < 1 || slide_num > top.last_slide)
	{	if (!is.nav5 || nav5SupportsAlerts) alert("Please enter number
between 1 and " + top.last_slide);
	}
	else
	{	top.current_slide = Math.abs(slide_num);
		top.frames["slide"].location = baseURL +
top.filename[slide_num];
                // update displayed page count in goto field
                // TODO: Nav5 support!
                // top.frames["next"].document.forms["gotoform"].slidenum.value
= top.current_slide;
	}
        // ekrock added 13 May to work around #6222
        return false;
}

// Display previous slide in sequence.
function prev_slide()
{	if (top.current_slide == 1)
	{	if (!is.nav5 || nav5SupportsAlerts) alert("You are already at
the first slide.\nThere is no previous slide.");
	}
        else goto_slide(top.current_slide - 1);
        // ekrock added 13 May to work around #6222
        return false;
}


// Display next slide in sequence.
function next_slide()
{	if (top.current_slide == top.last_slide)
	{	if (!is.nav5 || nav5SupportsAlerts) alert("You are already at
the last slide.\nThere is no next slide.");
	}
        else goto_slide(top.current_slide + 1);
        // ekrock added 13 May to work around #6222
        return false;
}


... so the relevant line of code appears to be this:
top.frames["slide"].location = baseURL + top.filename[slide_num];

That line of code is working. The function next_slide() returns false, so the
next.htm document should not be changed.  But it is.  This appears to be the
problem.

E) Have posted a ZIP of the directory at
http://blues/users/ekrock/publish/bugs/M10/htmlpreso/htmlpreso.zip

Updated

18 years ago
Summary: [DOGFOOD][4.xP] onclick event handler has side effect of changing doc contents when it shouldn't; handler function return false being ignored? → [DOGFOOD][DEMO][4.xP] onclick event handler has side effect of changing doc contents when it shouldn't; handler function return false being ignored?
Whiteboard: [PDT+]
Target Milestone: M12

Comment 1

18 years ago
Putting on PDT+ radar.
(Reporter)

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+][TESTCASE]
(Reporter)

Comment 2

18 years ago
Created simplified testcase. See it on intranet at:
http://blues/users/ekrock/publish/bugs/M10/htmlpresotest/index.htm
(Reporter)

Comment 3

18 years ago
Even simpler test case:
http://blues/users/ekrock/publish/bugs/M10/htmlpresotest2/index.htm

Attaching ZIP of test case to bug report ...
(Reporter)

Comment 4

18 years ago
Created attachment 2883 [details]
WinZIP file of simplest test case

Updated

18 years ago
Blocks: 18951
(Assignee)

Comment 5

18 years ago
Fixed on 11/16/1999. Joki to follow up to make sure that capture phase event
dispatch doesn't happen unconditionally.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 6

18 years ago
Verified with 1999-11-22-09. Working fine now.

Updated

18 years ago
No longer blocks: 18951
You need to log in before you can comment on or make changes to this bug.