19185 - document.clear() sets base URL to about:blank, not calling script's URL

Status: VERIFIED FIXED

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

Description

[Stephen Moehle]

At least this one page will not work properly.  The page consists of two frames.
Actions in the left hand frame updates the right.  The HTML of both frames is
created entirely by JavaScript.  The left frame consists of a table that uses
the onmouseover (highlight the cell), onmouseout (restore cell to normal
appearance, and onclick (update right hand frame) events in the cells.  In
Communicator 4.7, everything works fine, but in M11, it all goes to hell.
Clicking on a cell does not update the right hand frame.  In addition, moving
the mouse over the table can leave both the top cell and one other cell
highlighted.  Only one cell at a time should ever be highlighted.

In addition, M11 has made the width of the left hand frame much too big.
Visually the frame is layed out ok, but it has a horizontal scroll bar that
scrolls about a third of the frames width and that is not present in 4.7.

The URL is an ad so it may not be around for too long.  I have copied the code
of the left hand frame and placed it at:

http://www.wenet.net/~stephe/xfer/mozbug1/jshell.html

Comment 1

[Eric Pollmann]

The extra scrollbar is due to bug 14827.  I'll look in to onmouseout and onclick
not working as they are supposed to.

Comment 2

[Stephen Moehle]

Attachment: Testcase for this bug. gzip compressed tar file.

Comment 3

[Stephen Moehle]

Reviewing this bug in the post M12 world, I can see that Mozilla is behaving
better but is still not working correctly.  I can no longer duplicate the
problem of the multiple highlighted cells in the left frame due to onmouseover
and onmouseout.  Mozilla now partially updates the right hand frame, and the
extra scroll bar problem remains.  So, the previous bug description is obsolete.
A new description follows:

In the attached testcase, FrameWrite.tar.gz, when you click on one of the links
in the left hand frame, a JavaScript function is run that writes html into the
right hand frame.  The right frame should consist of a .gif image followed by
some text with another .gif image at the bottom.  In Mozilla, I only see the
text.  In Communicator 4.7, I see both images and text.

Comment 4

[Stephen Moehle]

A couple of things I forgot to mention:  The html that JavaScript code creates
has tables.  If I change the code to not use tables, Mozilla can load the html
in the right hand frame ok.  If I load the testcase in Communicator 4.7 and
click on a link in the left frame and then save the right frame as html, Mozilla
can load the saved right frame tables and all.

Comment 5

[Eric Pollmann]

Thanks for the update!  Updating summary...

Comment 6

[Eric Pollmann]

I'm able to reproduce this bug.  Perhaps the base URL for the image isn't set
correctly and that's why it's not loading?  Looking in to it.

Comment 7

[Eric Pollmann]

Yep, that seems to be the problem, if I give an absolute URL for the image
instead of a relative URL, the image is displayed...

Comment 8

[Eric Pollmann]

This relates to some work Vidur did with document.open (nsHTMLDocument) setting
the base URL to be that of the calling script.

In this case, we are calling document.clear not document.open.  This calls
nsHTMLDocument::Clear() which in turn calls nsHTMLDocument::Open(), but there
are two nsHTMLDocument::Open's, and this is the wrong one. (for non-script
cases) Thus the base URL gets set to about:blank instead of the calling script's
base URL as is needed here to load the image.

Attaching a reduced test case.

Comment 9

[Eric Pollmann]

Attachment: inner frame (for reduced test case)

Comment 10

[Eric Pollmann]

Attachment: Reduced test case

Comment 11

[Eric Pollmann]

Letting V pick the Milestone.  :)

Comment 12

[vidur (gone)]

Fixed the document.clear() issue on 1/2/2000. Did this fix the original problem 
reported? Pollmann thinks so, so I'm closing the bug.

Comment 13

[Chris Petersen]

Fixed in the Feb 18th build.