182107 - A div with a z-index of -1 causes the text of form elements it sits behind to become transparent

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P2)

Description

[Ben Darlow]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021026
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021026

In the page http://oldpeculiar.org/etc/mozilla_z-index_bug.html, the text in the
form input elements (input type="text" and textarea) should be of the colour
#3C3E3C (as set in the stylesheet) but instead the text is invisible, even when
selected with the cursor. Moving the div with ID background to above the form
elements in the source shows how the page should appear, as does setting the
z-index of that div to a value greater than or equal to zero.

Reproducible: Always

Steps to Reproduce:
1. View the source for http://oldpeculiar.org/etc/mozilla_z-index_bug.html; this
URL has effectively the most barebones markup required to generate this bug.

Actual Results:  
The text in the form input elements is invisible, as described in the details.

Expected Results:  
The text should instead be the colour #3C3E3C.

Comment 1

[Boris Zbarsky [:bzbarsky]]

views.  Happens on current Linux trunk too.

Comment 2

[F Harvell]

It appears that if there are any hidden divisions within the page with a z-index
of -1, the text in a text input, textarea, or password field within the visible
division (z-index of 0, 1, or 2) is "invisible".

This is true for version 1.2, 1.2.1, and 1.3a on both Linux and Mac OS X platforms.

The offending CSS style in my pages is:

popupFeedback { position: absolute; visibility: hidden; z-index: -1; top: 0px;
left: 0px; background: #EEEEEE; layer-background-color: #EEEEEE; }

If I change the z-index to 0, everything seems to work ok.

The "-1" used to work in 1.2a and all prior versions and it works in IE and
Netscape.

Comment 3

[Carine Held]

Reproduced in 1/08/03 Linux Trunk. Testcase keyword added.

Comment 4

[Ruslan Ismailov]

*** Bug 188550 has been marked as a duplicate of this bug. ***

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: really reduced testcase

Here's a really small and simple testcase.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

The problem was that the view for the scrolled document was being put on top of
the view for the INPUT contents.

The reason for that is that CreateDisplayList was trying to be clever and put
the "draw me here" display list instruction for the scrolled document view in
the "right place" in the z-tree --- between any negative z-index views and
before any non-negative z-index views. But this assumed that all the negative
z-index views would be before any non-negative z-index views in document order,
and that is not necessarily so.

Since the z-index sorter handles z-index now, CreateDisplayList only has to
make sure that document order (i.e. view order) is preserved. So we put all the
child views together after their parent's drawing instruction in the z-tree.

(Note that the z-tree is actually built in reverse document order which is why
you see the child views being added before the parent's drawing instruction.)

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 112494 [details] [diff] [review]
fix

I believe this is a regression actually (since we stopped inserting views
according to their z-index), so we may wish to consider this for 1.3final.

Comment 8

[Kevin McCluskey (gone)]

Comment on attachment 112494 [details] [diff] [review]
fix

r=[e-mail]

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

*** Bug 185514 has been marked as a duplicate of this bug. ***

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Happens on MSN, we should definitely try to get this into 1.3.

Comment 11

[Ruslan Ismailov]

*** Bug 191137 has been marked as a duplicate of this bug. ***

Comment 12

[Hixie (not reading bugmail)]

From bug 186754:
   http://www.hixie.ch/tests/adhoc/css/box/absolute/overflow/010.html

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

*** Bug 192622 has been marked as a duplicate of this bug. ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 112494 [details] [diff] [review]
fix

roc, the comment at
http://lxr.mozilla.org/seamonkey/source/view/src/nsViewManager.cpp#115 deserves
a medal.  Can we comment all our code like that?  ;)

Sorry it took me so long to look; I wish I'd known that I wouldn't have to
figure the code out completely on my own to review this....  I've been too
beaten down by layout.	:(

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Actually this part of the comment is now wrong and should be deleted:

> (Actually CreateDisplayList ensures that the tree is created to have elements in 
> the order "<children-with-negative-z-index> <this-view>
> <children-with-nonnegative-z-index>".
> This makes sure that this-view gets processed in the right place.)

I'll do that when I check in.

Comment 16

[Asa Dotzler [:asa]]

High-visibility site. We should get this for 1.3.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked in.

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 191635 has been marked as a duplicate of this bug. ***

Comment 19

[lɛʁi לערי ריינהארט]

Hallo! using
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

This bug is marked FIXED since 2003-02-13 11:29:18 PST.

a) Please see bug 191635 comment 7
Bug [Bugzilla] 191635 == Text of text box not showing up
refering to
http://bugzilla.wikimedia.org/show_bug.cgi?id=4332
Bug [MediaZilla] 4332 == RTL characters disappear in the Search edit box at Special:Search

Is that the same bug or not? If not is it reported already? Where?

b) Please resize your browser window to a width of about 20 cm and go to 
http://yi.wiktionary.org/wiki/user:Gangleri/tests/bugzilla?action=edit
The "startup" text in the form is larger then the form.

You will see that the scroll bar aligns automatically left. I assume it should align right.

Is that the same bug or not? If not is it reported already? Where?

c) The "startup" text in the form at
http://yi.wiktionary.org/wiki/user:Gangleri/tests/bugzilla?action=edit
is so "big" that any keystoke you make will bring you back to the top of the form:
- tray to go at the buttom of the text;
- a) press a <Cariage Return>; you will go back to the top
- b) select and copy a line from somewhere in the midle of the text
- c) paste that line one line below; you will go back to the top

Is that the same bug or not? If not is it reported already? Where?

To experiment with your own text you can go to RTL form's as
http://fa.wiktionary.org/wiki/special:Emailuser/Gangleri
http://yi.wiktionary.org/wiki/special:Emailuser/Gangleri
*note* You need to login to the wiki first to access these forms.

If the page code can be changed in order to avoid some of these behaviours I would be happy to get your feedback. Thanks for your help in advance!

best regards reinhardt [[user:gangleri]]

Comment 20

[lɛʁi לערי ריינהארט]

(In reply to comment #19)
> b) Please resize your browser window to a width of about 20 cm and go to

http://yi.wiktionary.org/w/index.php?title=user:Gangleri/tests/bugzilla&action=edit&section=0

testing with nightly trunk
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051230 Firefox/1.6a1

The end (the right end as the text is using Latin characters) of most of the lines of the source code are "aligned" but you will see a very long line which is "misaligned".