91789 - background-image CSS1 property not working in form textfield

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, defect, P3)

Description

[daniel vena]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.0)
BuildID:    2001062815

background-image: and background: are defined in CSS1 to apply to all 
elements.  mozilla is not displaying the background image in textfield form 
elements.

Reproducible: Always
Steps to Reproduce:
1. Define background-image CSS value
2. Apply to textfield form element
3. Ta-da

Actual Results:  background-image fails to render.

Expected Results:  rendered the background-image

Comment 1

[Boris Zbarsky [:bzbarsky]]

Over to HTML form controls.

Comment 2

[daniel vena]

update:

"background:" seems to work.  "background-image:" does not.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

Confirming as NEW. OS and Platform to ALL.
Adding CSS1, correctness keywords.
Nominating for Mozilla 0.9.4.

Comment 4

[rods (gone)]

->>

Comment 5

[kinmoz]

Attachment: Test Case

Comment 6

[kinmoz]

I just attatched a test case that shows this is working now. Marking this 
WORKSFORME. If you have a specific test case where it is not working, please 
attatch it to this bug and reopen it.

Comment 7

[Madhur Bhatia]

the testcase attached by Kin does work.

But if I make some more modifications and additions to the style, I am able to 
reproduce the bug.

1. see  the attached testcase 1 :- 
<style type="text/css">
<!--
input, textarea {
   color : white;
   background-image : url(http://www.mozilla.org/images/mozilla-banner.gif);
   background-color : #ffffff;
   background-attachment : fixed;
   background-repeat : repeat-x;
}
-->
</style>

u will notice that the textarea control does not display the background image - 
just a thin dark line at the starting of the control.

I noticed that the "background-repeat" is causing this problem. If I eliminate 
this line from the code, the testcase works like the one given by Kin.

2. see attached testcase 2 :-
<style type="text/css">
<!--
input, textarea {
  color : white;  
  background-image: url(http://www.mozilla.org/images/mozilla-banner.gif);
  background-color 	: #ffffff;
  background-attachment 	: fixed;
  background-repeat 	: repeat-x;
  background-position 	: 100% 50%;
}
-->
</style>

Here is where I can reproduce the problem. It is the "background-position" 
causing the bug.

Reopening bug.

Comment 8

[Madhur Bhatia]

Attachment: testcase 1

Comment 9

[Madhur Bhatia]

Attachment: testcase 2

Comment 10

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

Mozilla is displaying all of the testcases in this bug correctly. 
'background-attachment: fixed' means the background image should be fixed and
positioned relative to the viewport.

IIRC, MSIE doesn't support 'background-attachment: fixed' on any elements other
than the root element.  I think this bug is INVALID.

Comment 11

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

See also http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/bgafixed.html for a
demonstration of how 'background-attachment: fixed' should work.

Comment 12

[kinmoz]

FYI, MSIE seems to treat each div and textwidget as if they have their own
viewport, so in Madhur's test cases each widget has it's own image, positioned
relative it's upper left corner ... whereas in Mozilla, you will only see one
image (the 3 images are actually drawn on top of each other) positioned relative
to the window's view port. For testcase 2 you will see the image appear if you
resize the window so that it is small enough to push the image into the drawing
area of the text widgets.

So do we want to wait for Hixie to weigh in on this or just close it as INVALID?

Comment 13

[Hixie (not reading bugmail)]

dbaron is correct, although this could change in CSS3 (overflow:scroll might be 
defined as creating a new origin context for background-attachment: fixed).

Comment 14

[kinmoz]

Based on dbaron and hixie's comments, I'm going to mark this WONTFIX. If this 
should change as the result of CSS3, as hixie mentions, we can file a new bug 
regarding that issue at that time.