Closed Bug 19185 Opened 21 years ago Closed 20 years ago

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

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: stephe, Assigned: vidur)

References

()

Details

Attachments

(3 files)

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
Assignee: troy → pollmann
Component: Layout → HTMLFrames
Status: NEW → ASSIGNED
Target Milestone: M14
The extra scrollbar is due to bug 14827.  I'll look in to onmouseout and onclick
not working as they are supposed to.
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.
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.
Summary: JavaScript and frames have problems in M11 → document.write of table/image/text doesn't show image
Thanks for the update!  Updating summary...
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.
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...
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.
Assignee: pollmann → vidur
Status: ASSIGNED → NEW
Component: HTMLFrames → DOM Level 1
Summary: document.write of table/image/text doesn't show image → document.clear() sets base URL to about:blank, not calling script's URL
Attached file Reduced test case
Letting V pick the Milestone.  :)
OS: Linux → All
Hardware: PC → All
Target Milestone: M14
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Fixed in the Feb 18th build.
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.