157445 - descendants of 'visibility:hidden' can't be 'visibility:visible' in Mozilla if the hidden frame has a widget

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P2)

Description

[tapio.markula]

According to David Baron (<[e-mail]>) descendants of visibility:hidden can have visibility:visible. 

Mozilla 1.1a has bug in this matter.

Concering the CSS2 spec. the behavior of MS IE follows the stricly CSS2 spec. because the spec. ALLOWS that descendants of visibility:visible can have descencants, which have visibility:hidden. IF 'visibility' is inherited property, it is logical that descendants can have different values as their anchestors. BUT the new CSS3 spec. could however tell, that descendants of
visibility:hidden can have visibility:visible and at this mean it differs essential from 'display:none'.

This bug can be seen on the page:
http://www.nic.fi/~tapio1/Sielu/future.php3

there was something wrong in this page because a CSS-file was corrupted. I fixed this matter.
RELOAD the page if it looks bad.

In principle it should have nice dynamic menus like in most of my pages, but some CSS is missing.
If you HIDE the menu by using links on the right, ONE arrow should 
remain visible.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 2

[Eli Friedman]

I believe from some tests I did that Mozilla has full support for visible
children of hidden parents.  If you could simplify the code, I might be able to
figure out why it isn't working.  Otherwise, I think this bug cannot be traced.

Comment 3

[Boris Zbarsky [:bzbarsky]]

to me to create a minimal-ish testcase.....

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase

This shows what the problem is... removing the "position: fixed" makes the bug
go away.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: same, but not dynamic

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: This is a problem for anything with a widget

Comment 7

[Boris Zbarsky [:bzbarsky]]

So the problem is that fixed-position elements have a widget.  Anything that has
a widget and "visibility:hidden" gets its view marked hidden (the comments say
"If it has a widget, hide the view because the widget can't deal with it").

The checkin that added the above lines (nsCSSFrameConstructor, nsBoxFrame,
nsContainerFrame, nsHTMLContainerFrame) was a very long time ago.... is that
comment still relevant?  What breaks if we allow something that has a widget to
not paint itself but paint the kids?

Over to views.

Comment 8

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

You're right. The "widget can't deal with it" comment and associated code is
very old, from before I ever started hacking on views. I honestly don't know why
it's in there. Try taking it out and see what happens :-).

Over time I have reduced the need for widgets to be attached to views (attaching
or removing a widget from a view shouldn't have any effect except for performance).

However, I don't know what shoud happen if you have a hidden scroll frame with a
visible child. That would be weird. I don't know what we'd do in that case
although it is possible we would do something reasonable :-).

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: patch to remove the widget witchery

This fixes the original page and the position:fixed testcases.	It does not fix
the overflow:scroll issue, since there is separate code checking for a
scrollframe there (and I don't think we want to change that).

This is for testing purposes only; if this were to land it should be in an
"alpha" milestone...

That said, I see no problems so far running with this.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Another HTML file to test on, just for kicks.

Comment 11

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

We really should merge all the view setup code into one place.

Comment 12

[Carine Held]

Reproduced on 12/16 Trunk, Win XP

Comment 13

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

Linux trunk actually works for me. Is this only a problem on Windows?

Comment 14

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

Ah, testcase 91737 does not work on Linux.

Comment 15

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

Attachment: fix

This patch does the job. We hide anything that doesn't have native scrollbars,
which means we *can* hide normal scroll frames. I'll attach an interesting test
in a moment, which this patch passes.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

What about similar code in nsBoxFrame, nsHTMLContainerFrame,
nsCSSFrameConstructor?

Comment 17

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

Attachment: Testcase

Yeah baby

Comment 18

[Boris Zbarsky [:bzbarsky]]

Also interesting... attachment 91718 [details] fails in the 2003-01-24-05 nightly, and in
my clean debug build (but not in my slightly-dirty opt build...)

Comment 19

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

I factored them all out into nsContainerFrame a while ago :-). One function to
rule them all ...

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

I knew there was a reason I thought you rocked.  ;)  That's likely when the
second of the three testcases got fixed too.

Comment 21

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

Fix checked in.