Closed Bug 281429 Opened 20 years ago Closed 19 years ago

background images do not respect <base href=...> element in <body>

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED EXPIRED

People

(Reporter: kenseehof, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

<img src="..."> tags work fine, but <table background="..."> fails in the same
context, when the base tag should modify the image location.

Opera 7.54 and IE 6.0 display the page correctly.

Note that a trailing "/" in the url eliminates the problem:
  http://www.neuralintegrator.com/northbayaikido   -> background fails
  http://www.neuralintegrator.com/northbayaikido/  -> works


Reproducible: Always

Steps to Reproduce:
1. Make a web site that contains a <base> tag.
2. Add an <img> tag that is affected by the <base> tag.
3. Add a <table> tag with a background field similar to the <img> tag.
4. Verify that the <img> tag works, but the background fails.

Actual Results:  
In Firefox, the img tag displays correctly, but no background is shown.


Expected Results:  
The img tag and the background should be displayed.
I can confirm the visual appearance.

Your page has 29 mark-up errors. Do you have a shorter test case?

Having said that, other things being equal, Firefox's error recovery
could perhaps be adjusted to cope with merely omitting a trailing slash
on a directory.
Okay, I've made a simple demo page.

http://www.neuralintegrator.com/bug_demo  : doesn't work
http://www.neuralintegrator.com/bug_demo/ : works

Note that the problem only occurs when the trailing slash is omitted.
The url gets mapped to http://www.neuralintegrator.com/bug_demo/index_html

In any case, the <img> tag works fine, so I think that the background field in
the table should have the same behaviour.

This bug is not as big as I had initially thought.  When I make a subdirectory
that makes the <base> tag actually /do/ anything, the problem goes away.  I've
reduced the severity to "minor".

http://www.neuralintegrator.com/bug_demo/foobar  : works
http://www.neuralintegrator.com/bug_demo/foobar/ : works
URL: http://www.neuralintegrator.com/north... → http://www.neuralintegrator.com/bug_demo
Severity: normal → minor
Thank you. 

I am certainly seeing what you are. If I understand correctly, then extracting
the  base URL that will be used, often means converting a file to a directory, 
that is, trimming the last segment.

Page Info shows that in the non working cases, your server is being
asked for http://www.neuralintegrator.com/images/tatami.jpg and
not http://www.neuralintegrator.com/bug_demo/images/tatami.jpg .

The same occurs if I save the working version to a local file.

I am not sure whether this behaviour is faulty without checking the
specs, but it is certainly surprising.
The problem is not (exactly) what you think, and may or may not be intentional:
the HTML spec says that base href may only appear between <head> and </head>. If
you put it there, then the <table background=""> works properly. If you
mistakenly put it in the <body>, then it looks like we add a _base_href property
to elements that come after it, but that doesn't seem to affect the resolution
of the URI for background. Me, I'm not sure whether that's bugwards
compatibility or an oversight, and I'm also not sure whether that's Parser, or
DOM, or someone else.
Assignee: firefox → parser
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → mrbkap
Summary: background images do not respect <base href=...> element → background images do not respect <base href=...> element in <body>
Version: unspecified → Trunk
(In reply to comment #4)
> The problem is not (exactly) what you think, ...

FWIW, I will put my hand up and admit that I was wrong about this. Not
only is "element “<base>” not permitted in content of element “<body>”,
but "attribute “background” is not permitted within element “<table>”.

I would venture that using the background attribute on a table should
invoke undefined behaviour, but it might be better to do in this
case, what the OP wanted.

However, this report shows that invalid HTML is not always rendered
as the author intended.




See
http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsGenericHTMLElement.cpp#2894
-- we have a bug already filed on that, I'm pretty sure.
Whiteboard: DUPEME
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.