Closed Bug 210808 Opened 21 years ago Closed 21 years ago

Literal HTML image tags embedded in XBL anonymous content are not displayed.

Categories

(Core :: XBL, defect)

Product:
Core
Component:
XBL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jmueller, Assigned: hyatt)

Details

(Whiteboard: (py8ieh: file a generic bug for the relative stylesheet and dynamic relative src manipulation issues: should use xml:base)) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

When using XBL in an HTML page, any literal image tags embedded in the binding's
anonymous content are not displayed - the value of the image's ALT attribute is
displayed instead. After loading, programmatically changing the SRC attribute of
one of these images causes it to appear correctly. Tested on WinXP, OSX. This
behavior does not appear in Mozilla 1.3.1 or Netscape 7.02.

Reproducible: Always

Steps to Reproduce:
1. Create an XBL binding that includes one or more images in its anonymous content.
2. Bind it to an element on an HTML page (with a standards-compliant doctype).
3. Images are not shown, but any ALT attributes appear instead.
4. (Optional) After page load, programmatically alter the image's SRC attribute.
If the path is valid, the image will then display correctly.

Actual Results:  
Images are not displayed.

Expected Results:  
Mozilla should have displayed the images.

This bug should be easy to reproduce, but if not I can provide a test case.
Does it work if you give explicit absolute URIs in the src attributes?
The image is displayed correctly with an absolute URI. However, my application
requires relative URI's in this situation, which worked correctly in Mozilla
1.0.2 and 1.3.1.
Actually, relative URI's do work, but they now seem to be relative to the XBL
file, rather than relative to the page the element is part of. This change in
behavior, while logical in some ways, is going to make it difficult to support
both Mozilla 1.4 and earlier versions with the same code. In addition, the
behavior is inconsistent, because programmatically setting a URI that is
relative to the page still works, as does using a URI relative to the page in a
CSS @import statement inside anonymous content.
That would seem to be the expected behaviour. You get the same thing, for
example, using CSS. It has to be this way, otherwise how do you make publically
available bindings?

The reason relative URIs work after the binding is bound is that the node is
then in a different document, and so has a different base URI.

If you need to support both old and new builds of Mozilla, you can probably set
up persistent HTTP redirects from the old path to the new path.

cc'ing bz in case he disagrees.
So what if my anonymous content contains the following?

<html:style type="text/css">
    @import url(styles/foo.css);
</html:style>

Now my image tags are resolving relative to the binding, and my stylesheet is
resolving relative to the page, and I still can't have a publicly available
binding. I agree with the rationale for this change, but if it's not consistent,
all it does is create more work. In my case I have no control over where my
application will be set up, so I cannot rely on persistent HTTP redirects; I
guess I'll have to programmatically set the image src attributes as relative to
the page, and not embed any image URI's into anonymous content if I want to
support older builds.
> So what if my anonymous content contains the following?
> 
> <html:style type="text/css">
>    @import url(styles/foo.css);
> </html:style>

That _should_ be relative to the binding, I think. If it isn't, it seems like a
bug. In fact, the fact that when you set img elements' src attributes
dynamically the relative paths are relative to the document is IMHO a bug as
well, since we should be implementing this by making the anonymous nodes have
xml:base URIs equal to their binding documents'.

Note that the preferred way of introducing stylesheets is via the <stylesheet>
element in the binding's resource section.


> In my case I have no control over where my application will be set up, so I 
> cannot rely on persistent HTTP redirects; I guess I'll have to 
> programmatically set the image src attributes as relative to the page, and not
> embed any image URI's into anonymous content if I want to support older 
> builds.

I'm curious, what images is your binding using? I can't really think of any case
where a binding would want to refer to images relative to the document, since in
theory the binding has no control over the document's location.


Marking this INVALID; but I would quite like to see bz's and hyatt's comments.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Whiteboard: (py8ieh: file a generic bug for the relative stylesheet and dynamic relative src manipulation issues: should use xml:base)
> I'm curious, what images is your binding using? I can't really think of any 
> case where a binding would want to refer to images relative to the document, 
> since in theory the binding has no control over the document's location.

Oh no, I completely agree that it makes more sense to have everything resolve as
relative to the binding. Unfortunately, I'm not in a position to be able to
require Mozilla 1.4 - I have to support Netscape 7.02 with the same binding. For
what I'm doing, this is a pretty significant breaking change, because prior to
1.4, everything resolves as relative to the document. At the moment, my
workaround is to leave the image URI's relative to the document, since that's
what works in older browsers. To support Mozilla 1.4, I'm calling the following
function in the constructor, which touches all the image src attributes through
script, forcing them to be re-evaluated in the context of the document.

If dynamic src attributes are changed to also resolve as relative to the
binding, I suspect that my only alternative will be to sniff browser revisions,
and use one path for pre-1.4 browsers, and another for 1.4 and later. Ugh.

function fixImageUrls(baseNode)
{
	var images = baseNode.getElementsByTagNameNS(baseNode.namespaceURI, "img");
	
	for (var i=0; i < images.length; i++)
	{
		images[i].src = images[i].src;
	}
}
>		images[i].src = images[i].src;

That really shouldn't have any effect. That it does is definitely a bug, IMHO!

If you know the paths of binding and documents, can you make relative paths that
are always the same relative to both?

e.g. if your bindings are in ".../documents/foo.xml" and your bindings in
".../bindings/foo.xbl", you could use "../bindings/image.png" as your path,
since that would always work.
> If you know the paths of binding and documents, can you make relative paths 
> that are always the same relative to both?

Well, my structure is this:

documents
documents/images
documents/bindings

The documents directory might be the web server root, or a subdirectory, or even
a subdirectory of a subdirectory; I have no control over this.

Given that structure, I can't think of any single relative path (pointing to an
image from a binding) that will work in both circumstances. If, in the binding,
there were a way for me to find out the current base path used for calculating
relative URI's then I could handle this without version sniffing, but short of
that...

Can't you use a doc-root-relative URL (one beginning with a single slash)?

It would be good to understand the incompatible change, when and why it was made.

/be
joel: yeah, that's a problem. I take it there's no way for you to create a
symlink or equivalent from bindings to images? (as in, .../bindings/images ->
.../images)

I'll bear your needs in mind when I next edit the XBL spec. I think the DOM Core
interfaces should have a way of getting the xml:base of an element, although we
probably don't support that yet.
> Can't you use a doc-root-relative URL (one beginning with a single slash)?

No, I can't, because I don't know where my documents are in relation to the web
server root. If my application were installed directly into the web server root,
I'd want to use "/images/foo.png". If my application were installed into a
subdirectory, I'd need to use "/someunknownsubdirectory/images/foo.png". It gets
even worse if my application were installed into a subdirectory of a subdirectory.

> I take it there's no way for you to create a symlink or equivalent 
> from bindings to images?

That would be nice, but at this point I think it would be simpler to sniff
browser revisions and change the path than to further complicate our installer.
Maybe I'll get lucky and Netscape 7.1 will come out in time for me to make that
the minimum requirement, but I'm not holding my breath. A DOM way of getting the
xml:base would be very nice, eventually.
> >		images[i].src = images[i].src;

> That really shouldn't have any effect. That it does is definitely a bug, IMHO!

Well... It should at the very least file a mutation event, since setting .src is
equivalent to calling setAttribute("src", ..) per spec, while getting .src is
NOT equivalent to getAttribute("src", ...)  -- the value returned by
getAttribute may be a relative URL while the .src property is always an absolute
URL per spec.

> It would be good to understand the incompatible change, when and why it was
> made.

The change was made when I changed image loading to be kicked off from content
model construction (which happens when the XBL document is parsed) as opposed to
layout model construction (which happens after binding attachment).  The images
continued using their document for the base URL, but what that document was
changed in the process.

I do think that the new behavior is more correct (and as far as I know the code,
the behavior for stylesheets should also be to load them relative to the
binding; if it is not, please file a bug on me).  I apologize for not catching
this behavior change earlier, though...

> I think the DOM Core interfaces should have a way of getting the xml:base of
> an element, although we probably don't support that yet.

DOM3 Core has a readonly "baseURI" attribute on the Node interface. We've
supported this since 29 Mar 2001 (in particular, Netscape 7.x should support it
just fine).  It doesn't take into account some edge cases with malformed HTML
documents with multiple <base> tags quite yet (hence will not in 1.4), but it's
perfectly serviceable otherwise.
Ok if baseURI is already supported then: For any anonymous nodes it should be
set to the base URI of the nodes in the XBL binding, not of the place in which
they are inserted in the HTML one. URIs in <html:style> nodes, <html:img> nodes,
etc,  that are inserted into the document should all be relative to the binding.
This (based on comments above) is not currently the case. Should we file a bug
about it, or is this known, or...?
> Ok if baseURI is already supported then: For any anonymous nodes it should be
> set to the base URI of the nodes in the XBL binding

baseURI is readonly in the DOM.  Did you mean that we should set xml:base on all
"root" nodes in the binding's content section?  I agree with that....
bz: I'm not sure what what you just said means! :-)

I'm basically saying that any anonymous nodes should have, as their baseURI (aka 
xml:base value) the path of their binding (of course, if a node in the binding 
itself uses xml:base, that would override it).

Shouldn't cloning the node from the binding mean that happens automatically?
> Shouldn't cloning the node from the binding mean that happens automatically?

No.

Bug 211128 filed on the xml:base suggestion.
You need to log in before you can comment on or make changes to this bug.