JavaScript URL: Writing a frame does not bring up an image

RESOLVED DUPLICATE of bug 99689

Status

()

Core
Layout: HTML Frames
RESOLVED DUPLICATE of bug 99689
16 years ago
15 years ago

People

(Reporter: Fred Metcalf, Assigned: John Keiser (jkeiser))

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: INVALID?, URL)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310
BuildID:    2002031008

The example shows two frames.  The top frame uses an html file as the source,
while the lower frame creates the same HTML using the "javascript:" URL protocol.

Viewing the resulting frame sources shows the same HTML, however the lower frame
does not show the image called by an IMG tag, while the top frame does show the
image.

Reproducible: Always
Steps to Reproduce:
1.Generate an IMG tag via "javascript:"
2.
3.

Actual Results:  With width and height attributes provided, the space for the
image is set aside, but the image does not appear.

Expected Results:  Should have displayed the image.

This was tried in both strict and quirky modes.  Same results.
The javascript: version uses a relative URL to the image.  This is resolved
relative to the URL of the frame which is "javascript:....".  As a result, there
is no image (since there is no image at that url).  This seems like correct
behavior to me.

Netscape 4 on Linux shows the exact same behavior once the missing ">" after the
second "<frame" is added so that the page is actually valid.
Whiteboard: INVALID?

Comment 2

16 years ago
Confirming reported behavior with Mozilla trunk binary 20020330xx WinNT.
OS: Linux ---> All. Browser, not Engine. Reassigning to HTML Frames.

Here is the source of the problem frame:

<frame src='javascript:"<body>\nHere is a 30x20 printer image:\n<br><br>\n<img  
 src=\"Printer.gif\" width=\"30\" height=\"20\">\n</body>";'>


NOTE: Confirming what Boris said. If you replace \"Printer.gif\" with
an absolute URL, e.g. \"http://mozilla.org/images/mozilla-banner.gif\",
then it works fine -
Assignee: rogerl → jkeiser
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → HTMLFrames
Ever confirmed: true
OS: Linux → All
QA Contact: pschwartau → amar
(Reporter)

Comment 3

16 years ago
Some additional notes:

I reported this behavior as a bug since it worked correctly (both images
showing) on Navigator 4.79 (Linux).  Boris (bzbarsky@mit.edu) reported that it
did not show both images on Navigator 4.74 (Linux) - however, when I tried the
example page on Navigator 4.74 (Linux), both images showed.

Normally, one would expect a URL to be either absolute or relative, but not be
neither.  In this example, the source URL for the top frame is relative
(src="demoFrame0.html"), that is, it is located relative to the parent page
(http://math.ucr.edu/ftm/Mozilla_examples/demo.html).

In the lower frame, the "javascript:" URL is certainly not an absolute URL.  Not
being absolute, I believe most would assume it to be relative.  However, the
behavior in Mozilla is to assign the javascript: URL to a "neither" category -
and I am increasingly of the opinion that this is wrong.

Just as the contents of demoFrame0.html are interpreted relative to the parent
page, it seems that the "contents" of javascript:... should also be interpreted
relative to the parent page.

As the Mozilla JavaScript engine currently interprets a javascript: URL, there
seems to be no way of including relative URLs in the  content of the JavaScript
code.  However, if the engine interpreted the javascript: URL as was done in
Navigator, then the JavaScript code could use both relative and absolute URLs.
> In the lower frame, the "javascript:" URL is certainly not an absolute URL.  

Not that this has that much bearing on the discussion, but is is in fact an 
absolute URL.  Bug 22251, comment #4 has the RFC quote on the issue I suppose 
we could try to force javascript: urls down the "Due to a loophole in prior 
specifications path".

jst? Thoughts?

Comment 5

15 years ago

*** This bug has been marked as a duplicate of 99689 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.