301661 - Firefox Places Background with background-position: bottom right; Nowhere Near The Bottom Right

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Ty Williams]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

If a webpage has a CSS rule asigning an image to the body at a fixed position,
the image will not appear where it's expected to.  For example:

body {background-image: url(/path/to/foo.jpg); background-position: bottom
right; background-repeat: no-repeat; }

should result in the image being placed in the lower right corner of the browser
window regardless of window sizing.  For an example of this working correctly,
see Firefox 1.0.6  However, in Deer Park Alpha 2, the image will appear on the
right side of the browser window but nowhere near the bottom.  Using the DOM
Inspector, you can see the the body element is not taking up the whole window,
it's height is the minimum height necessary to contain the elements inside of
it.  However, the background-color assigned to the body element will fill the
entire browser window.

Reproducible: Always

Steps to Reproduce:
1. Load a page where a CSS rule is used to set a background image to a specific
position like "bottom right"
2. Become confused when the image appears midway up the page
3. Use the DOM Inspector to determine that the image is at the bottom right of
the body element, but that the body element does not fill the browser window

Actual Results:  
Background image appears part way up the page

Expected Results:  
Background image should appear in the bottom right of the window (see Firefox
1.0.6 for correct behaviour)

Regression from Firefox 1.0.6,

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This looks invalid to me.  It's in the bottom right corner of the body element.
 To get the effect you want you either need a fixed background attachment or
html,body { min-height: 100%; } .  In particular, CSS 2.1 says:

# The background of the root element becomes the background of the canvas
# and covers the entire canvas, anchored at the same point as it would be if
# it was painted only for the root element itself. The root element does not
# paint this background again.

and:

# For HTML documents whose root HTML element has computed values of
# 'transparent' for 'background-color' and 'none' for 'background-image',
# user agents must instead use the computed value of those properties from
# that HTML element's first BODY element child when painting backgrounds for
# the canvas, and must not paint a background for that BODY element.

Also, nominating for blocking1.0.7 is *completely ridiculous*.  The bug clearly
states that the bug is *not present* in 1.0.6, and spurious nominations
(especially those that clearly don't fit the goals of a security release to
begin with) just waste drivers' time.

Comment 2

[Ty Williams]

(In reply to comment #1)
> This looks invalid to me.  It's in the bottom right corner of the body element.
>  To get the effect you want you either need a fixed background attachment or
> html,body { min-height: 100%; } .  In particular, CSS 2.1 says:
> 
> # The background of the root element becomes the background of the canvas
> # and covers the entire canvas, anchored at the same point as it would be if
> # it was painted only for the root element itself. The root element does not
> # paint this background again.
> 
> and:
> 
> # For HTML documents whose root HTML element has computed values of
> # 'transparent' for 'background-color' and 'none' for 'background-image',
> # user agents must instead use the computed value of those properties from
> # that HTML element's first BODY element child when painting backgrounds for
> # the canvas, and must not paint a background for that BODY element.

By the very sections of text you quoted, this is an obvious bug.  The first
paragraph of quoted text implies that the body element should be the full size
of the canvas (browser window).  The DOM Inspector clearly shows that this is
not the case.

Even if the vertical behaviour is, for some odd reason, read as correct, then it
is NOT CONSISTENT with the horizontal behavior.  The horizontal behavior causes
the body element to be the full width of the window, which is directly opposite
to the vertical behavior.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Document layout uses widths as input and heights as output, so of course they're
inconsistent.  And the part I quoted doesn't say anything about the body element
filling the canvas; this section specifically explains that its background
covers the canvas regardless of its height.  If the element were actually
larger, it would be in chapter 10 of the spec.

Comment 4

[Ty Williams]

(In reply to comment #3)
> Document layout uses widths as input and heights as output, so of course they're
> inconsistent.  And the part I quoted doesn't say anything about the body element
> filling the canvas; this section specifically explains that its background
> covers the canvas regardless of its height.  If the element were actually
> larger, it would be in chapter 10 of the spec.

I'm completly baffled as to what you mean with the input/output bit, but I'll
assume you know more about it than I do.

Deer Park will not respect adding a min-height: 100% to the CSS rule either.

At this point, Deer Park is the only browser that chokes on this page.  Previous
Firefox builds render it correctly, Opera renders it correctly, Safari renders
it correctly, even IE renders it correctly.

Since previous versions of Firefox, and all other current browsers, render this
page correctly, how can this not be seen as a bug in Deer Park.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Opera 8.01 does the same thing as Mozilla trunk.