378851 - background-position style modifier is ignored or is displayed improperly

Status: UNCONFIRMED

(Core :: CSS Parsing and Computation, defect)

Description

[Doug]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: 20070326 version 2.0.0.0

When adding a background image in the compose window, if adding an inline style of "background-position" that has a value of anything other than top-left, the image either gets put at the top left position anyway, or is placed at some incorrect position -- usually partially off-screen at the top of the window.  This seems to be a rendering problem as well, because I can code the same document (using styles in the header) in frontpage and it will open properly in other email readers including Outlook Express and Incredimail.  For background images at the bottom right, Thunderbird usually places them either at top left, or somewhere at the top but half off-screen.  

In the inline styles form of the compose window, it shows the background-position bottom right as translated to:
-x-background-x-position right
-x-background-y-position bottom
I don't know if this translation is okay or not, but
but it doesn't actually place the image there.

Reproducible: Always

Steps to Reproduce:
1.See description above
2.Open compose window
3.click format/page colors and background/<add an image>/click advanced edit/click inline styles/enter "background-position value:bottom right/enter bacground-repeat no-repeat/click okay/okay
4. The image will not be place in the correct position
Actual Results:  
See problem description

Expected Results:  
The background image should be displayed at the location indicated by the background-position value

Stationery and templates is about the only area that Thunderbird is lagging behind Outlook Express.  It's about time this gap was also filled.  Please raise the priority of html editing enhancements in Thunderbird to meet this need.  I consider this a major broken feature for the reason just mentioned -- it is a feature that would encourage many more people to switch to Thunderbird from Outlook Express and Incredimail, and it is the one major area where Thunderbird is currently weak.

Comment 1

[Magnus Melin [:mkmelin]]

That works fine for me, though you misspelled background-repeat...

Comment 2

[Doug]

Magnus,

What do you mean, "that works fine for me"?  Do you mean you don't see this bug, or you agree with the report?  It was very repeatable for me.  I am using the Windows version of Thunderbird.

Comment 3

[Magnus Melin [:mkmelin]]

I don't see the bug:) I'm on linux though...

Comment 4

[Doug]

I just tested this feature in Ubuntu and it has the same problem.  When setting background-position to anything other than top left, Thunderbird lists the correct setting in the settings list, but then ignores it when it displays the image and just puts the image in the top left. This looks like a rendering problem as well, since incoming emails don't render properly either (they display fine in Outlook Express and Incredimail).  This problem appears with both the background image and a regular image added to the body of the email; i.e., body images always display in the top left regardless of background-position setting also.

Comment 5

[Doug]

After some more testing I discovered, that it is only the vertical values, top center bottom, that disply incorrectly.  The horizontal values, left center right, do display correctly.  The vertical location seems both inverted and out of range.

Comment 6

[Doug]

Some of the background image code works in Internet Explorer but doesn't work in Firefox, but here is an example of code that works in Firefox, but doesn't work in Thunderbird (just substitute your image name and location).  This code was inserted using Thunderbird's Insert/HTML tool, but Thunderbird just throws the code away.

<STYLE>
BODY { 
font-size: 14pt;
color: 000000;
  background-image: url("images/tulip2.jpg");
  background-attachment: fixed;
  background-position: 100% 100%;
  background-repeat: no-repeat;
} 
</STYLE>

Comment 7

[Doug]

All right, I've been reading numerous reports of background image problems in lots of areas.  I've discovered that even Firefox doesn't display background images properly.  More and more people want email stationery that works.  It has been the number one reason I held off using Thunderbord for over a year.  It's time Mozilla pays more attention to this problem, so I up-ed the severity to "critical" to get their attention (if that even helps).

Comment 8

[Phil Ringnalda (:philor)]

If you click the linked word "Severity" next to the severity dropdown, you can see a description of the meaning of the various levels. Note that the description of "critical" doesn't include "I really really want to you to fix this" or even "if you don't fix this, I won't use your program."

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html is also a useful read.

Comment 9

[me]

+1, confirmed on Thunderbird 31

http://i.imgur.com/EnD9Cvk.png

Comment 10

[Howard Chu]

This bug also affects Firefox and Seamonkey. Demonstration in https://monerodirect.com/position-bug.html

The background image is a square PNG. The image is supposed to be centered regardless of your display aspect ratio. Works fine on Chrome, you can resize the window any way you like and the image stays centered. If you use Firefox or Seamonkey, the image Y position is completely wrong.

Comment 11

[Howard Chu]

The bug appears to be due to some oddity in the construction of the canvas. Commenting out this block of code fixes the positioning problem, but causes other dialog boxes to be rendered incorrectly:

 hg diff
diff --git a/layout/base/nsCSSRendering.cpp b/layout/base/nsCSSRendering.cpp
--- a/layout/base/nsCSSRendering.cpp
+++ b/layout/base/nsCSSRendering.cpp
@@ -3318,26 +3318,29 @@ nsCSSRendering::ComputeImageLayerPositio
       bgPositioningArea.Deflate(padding);
       NS_ASSERTION(aLayer.mOrigin == NS_STYLE_IMAGELAYER_ORIGIN_CONTENT,
                    "unknown background-origin value");
     }
     *aAttachedToFrame = aForFrame;
     return bgPositioningArea;
   }
 
+#if 0
   if (MOZ_UNLIKELY(frameType == nsGkAtoms::canvasFrame)) {
     geometryFrame = aForFrame->PrincipalChildList().FirstChild();
     // geometryFrame might be null if this canvas is a page created
     // as an overflow container (e.g. the in-flow content has already
     // finished and this page only displays the continuations of
     // absolutely positioned content).
     if (geometryFrame) {
       bgPositioningArea = geometryFrame->GetRect();
     }
-  } else {
+  } else
+#endif
+  {
     bgPositioningArea = nsRect(nsPoint(0,0), aBorderArea.Size());
   }
 
   // Background images are tiled over the 'background-clip' area
   // but the origin of the tiling is based on the 'background-origin' area
   if (aLayer.mOrigin != NS_STYLE_IMAGELAYER_ORIGIN_BORDER && geometryFrame) {
     nsMargin border = geometryFrame->GetUsedBorder();
     if (aLayer.mOrigin != NS_STYLE_IMAGELAYER_ORIGIN_PADDING) {


The problem is that the canvas' firstChild is always a blockFrame with a height of 480 when the background image is being drawn, so all of the succeeding height/Y calculations are wrong. The actual canvas object's height is correct, which is why commenting out the FirstChild() bit fixes the scaling problem. But apparently a lot of other code is depending on this phantom frame, because e.g. the dialog at startup asking "do you want to make this your default browser" has its vertical offset and size squashed when this code is commented out.

I don't know enough about the history of these changes to know why this phantom frame exists or what depends on it. Would be nice to get this sorted out though.