Closed Bug 29057 Opened 25 years ago Closed 25 years ago

Layers/Positioned CSS: "visibility"/"display" style interference

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: pierre)

References

()

Details

visibility of styles in mozilla behaves differently than in navigator/ie in the following way: invisible layers in mozilla are in fact invisible, but still layer on top of the background. This way an invisible box covers the under- laying content, and thus the elements in the actual page cannot be accessed (links etc). netscape4 / ie4/5 simply take away the layer making it not only invisible but also not sensitive. I tried to compensate for this by using the display style on a layer which only sort of works: when a layer must be initialy hidden (drop down menus) and thus the display initially is set to 'none' the contents of the layer (images) do not get preloaded and drop down menus become "wait and watch it slowly load menus". In the end both behaviours are annoying. Maybe it is correct to not process "display: none" boxes at all. But then there should be a way to remove invisible boxes from the sensitive scope of underlaying elements. Steps to Reproduce: 1. goto the given url 2. move mouse over the "agentur/persönliches" logo until mouse becomes finger 3. leave the mouse in the finger state and wait. 4. watch the dropdown menu behavour using "display" 1a. goto http://schmidtundweber.de/visi.html 2a. the "Agentur/Persönliches" logo is not sensitive at first because the layer from "Projekte/Referenzen" (thou not visible) is laying over it. (this is the "visibility" style behaviour) What mozilla should have done: it should be possible to simulate the old navigator/ie behaviour. I dont mind which styles must be used for it. I nevertheless have to use a cross browser library.
LAYER tags are not supported in Mozilla. See http://sites.netscape.net/ekrock/standards.html Feedback sent. Marking INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Whiteboard: [LAYER]
This Bug reprort *never refers to using the layer tag*. What I am talking about is *absolutely positioned CSS* (commonly known as layers) Please reread the report.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Oops, sorry about that. I looked at the page in the wrong browser. Changing status to NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [LAYER]
Assigning to Waqar: 1/3 of Pierre's NEW bugs to help reduce his doomage factor
Assignee: pierre → waqar
Reassigned back to me these bugs that shouldn't have left my list.
Assignee: waqar → pierre
I was looking to see if my bug has been reported and it seems to be a variation of this one. Another example never hurts... Here's my example of similar layer (DIV) behaviour: http://design.myersinternet.com/kcook/mozbug/2000.htm In this example, URL links on the hidden, higher layers are being wrongly superimposed on links on the visible lower layer. So, when you click, you get a link other than what should be.
This one is similar, but perhaps another example will be helpful, as the coding is a little different. It uses an anchor to turn layers (using <DIV> tags) on and off. The code is generated by Dreamweaver 3.0. It works in NS4 and IE5, not in the NS6 preview release. URL: http://www.nscorp.com/nscorp/html/layer_test.html
robin, the reason why your example doesn't work is because MM_findObj uses document.layers and document.all. See http://sites.netscape.net/ekrock/standards.html
*** Bug 35474 has been marked as a duplicate of this bug. ***
The underlying bug described here seems to be a duplicate of bug 12232 / bug 21304, which have been fixed. What else is wrong?
Yes, things seem to work fine now. The page at http://schmidtundweber.de/visi.html is displayed perfectly as of m16 2000041409 (the first time i realized it works now). What can i do to remove the bug from bugzilla?
A bug can't be removed from Bugzilla but it can be marked FIXED.
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Verified fixed on Linux using 9/14 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.