42139 - background-position misinterpreted with fixed backgrounds

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[chuckie]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m16) Gecko/20000609
BuildID:    2000060908



Reproducible: Always
Steps to Reproduce:
1.Open the URL http://www.jay-livermore-lf.org/
2.Look at the background on the right frame.
3.Click on "Our Activities" on the left.
	

Actual Results:  The background is not shown completely.

Expected Results:  The background should be shown completely and not scroll with
the documents contents.

Comment 1

[chuckie]

Attachment: Fixed background

Comment 2

[chuckie]

Attachment: Not a fixed background

Comment 3

[Hixie (not reading bugmail)]

I cannot reproduce this. (Win2000)

Comment 4

[Jeffrey Baker]

I can reproduce on Linux build 2000060908 (M17).  The background image is
shifted to the right so that half of its width is out of view.  This is not
consistent with the specified behavior of the background-position property of
CSS2.

Marking bug as confirmed and changing platform/opsys.

Comment 5

[Hixie (not reading bugmail)]

This is a very recent regression then. With a build from last weekend I'm pretty
sure this bug did not occur. I can confirm that it does now, though.

Here is another test case:
 http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/fixedpos-bg-pos2.html

It looks like background-position is being interpreted as only deciding the 
origin on the graphic itself, and this origin is always placed at the top left
instead of being placed in the equivalent position in the viewport.

For example, background-position: center center; with background-attachement:
fixed;, seems to place the center of the background graphic at the top left
instead of placing the center of the graphic in the center of the viewport.

It all seems to work fine with 'scroll' instead of 'fixed'.

Pierre: this could easily be compositing/layout rather than style system.

Netscape PDT: Nominating nsbeta2, since this is a CSS1 compliance issue. This 
feature is used a lot in pages that wish to show off standards compliance, so 
is likely to be met a lot by content developers working with PR2.

Comment 6

[leger]

Marking nsbeta2+.  Will become - on 6/22

Comment 7

[chuckie]

This seems to have been magically fixed in 061311

Comment 8

[Jeffrey Baker]

That's only because 061311 is M16.  The bug is in the M17 branch.

Comment 9

[Pierre Saslawsky]

This bug was introduced by Marc and Kevin in nsCSSRendering.cpp (v3.116 on 06/07) 
when trying to fix a crash described in bug 40118. I'm going to attach a patch 
mostly based on the old code.

Marc, Kevin: could you carefully review the patch? I could not reproduce the 
crash in bug 40118, even with nsCSSRendering.cpp v3.115, so I can't really tell 
whether what I'm proposing causes a regression.

Comment 10

[Pierre Saslawsky]

Attachment: patch

Comment 11

[Marc Attinasi]

Pierre, it looks like your patch puts back in the code that I mistakenly removed 
when I fexed the crasher. We need to handle the case where there is no scroll 
frame and we need to use the root's scroll frame. Your change looks good - I am 
running with it now. 1000 apologies for the regression.

Comment 12

[Pierre Saslawsky]

fixed

Comment 13

[ckritzer (gone)]

Marking VERIFIED FIXED on:
- MacOS9 2000-07-12-15-M17 Commercial
- Linux6 2000-07-12-21-M17 Commercial
- Win98  2000-07-12-21-M17 Commercial