Android Webkit: Absolutely positioned elements don't respect z-index
Asked Answered
K

8

23

Nasty little bug, this one.

As illustrated in Android ticket 6721, the Android browser seems to not respect z-index when absolutely positioned elements are laid over the top of <a> or <input> tags. I am desperate for any sort of workaround. Has anybody conquered this one before?

Thanks in advance!

Kleptomania answered 1/4, 2010 at 17:10 Comment(4)
It would help to see a sample of your code where you can show us absolutely positioned elements above <a> and <input> tags.Coreen
I gave Paul de Vrieze the bounty, but the problem hasn't really been solved. If anybody has any other thoughts, I'd love to hear them!Acree
Tried mine? I don't see any comments of YoursBuchan
I don't understand all the downvoted (<0) answers below - all were on target and offered help; maybe they were not THE solution, but still. Voted back to 0...Porthole
S
11

This problem is probably related to controls and their being special for the browser. While looking at your problem (in chromium) I found a related problem that when you press the tab key you will still be able to focus the input elements. You probably don't want this either (regardless of bleedthrough). The solution is surprisingly simple, you write your script to add the disabled attribute to all input/button/etc. elements that are overlayed. A disabled input will not be able to receive focus (by keyboard or otherwise), and clicking it should be impossible.

As this also disables silly keyboard circumnavigation it is not even a workaround, but a better design that also works with keyboard based navigation as expected.

Scary answered 8/4, 2010 at 9:44 Comment(4)
This helps for <input> elements, but the problem still happens with <a> elements, unfortunately, which are a bigger problem child. Any ideas for that?Acree
Well, You could always replace the affected <a elements with <span elements that have the same attributes (maintaining the reference) and an extra class that styles them like anchors (make sure to disable tabindex attributes as well) or just "rename" the href attribute to xhref. Doing so will also fix the tab accessibility of the tag when overlayed (in other browsers). It is a bit of a hack though, but not much harder to pull off than adding a disabled attribute.Scary
Good thought, but that kills the experience for old BlackBerry users (Capitol Hill audience, so lots of them), unless you do it all with JavaScript, which is a real tax on devices with limited computing power. I'm going to give you the bounty for the effort—thanks!Acree
The javascript tax should be rather limited as you don't go and do it all the time. If you give all a elements involved a class, the searching for them should be easy (one command), and even a braindead java interpreter should be reasonably fast in changing some attributes on them. Note that you have to do this for the "enabled" attribute as wellScary
B
3

To answer the question properly it's important to read the bug page. The problem is not about visibility of the input below, but its "clickability".

I can't test it, but these are possible workarounds:

0 Forget absolute positioning and just put two divs there and toggle visibility.

If this doesn't satisfy You...

1 try setting CSS position to absolute or relative for all a and input tags (Yup, this might force You to rewrite CSS to keep the layout, but isn't it worth it?)

2 make a <a>-tag container:

 <div style="z-index:100 etc."><a style="width: 100%; height:100%; z-index:101">
     stuff here
 </a></div>

This will need some more CSS to make the content look ok. But I expect something like this would solve the problem.

if 1 and 2 aren't helping try them both at once ;)

3 if it still happens You might want to check in details what happens when You click. Bind click and mousedown events to: link on top, container on top, input in the bottom and log them. If You get any of those events for the top link You can try and stop the bubbling at some moment or prevent the event on the input in the bottom.

This would be difficult, but I can help a bit. jQuery would be quite necessary.

Buchan answered 9/4, 2010 at 18:11 Comment(1)
Ok, +1000 (is that possible?) Was pulling my hair out. Setting each item's z-index using css (had to do both elements and all containers) fixed it for me. Thanks for the tip. Thanks to you, I have held off baldness for another day.Velarium
H
2

Past fixes for this issue for IE include, but are probably not limited to the following list. These may help solve the problem in Android for you.

  1. Put an iframe behind the absolute content. The iframe may obscure those elements for you

  2. When you display your absolute content, hide all of the problem elements with JavaScript

  3. Define the div's in the opposite order

Point number 1 is deemed the most reliable fix for IE, but may not be the nicest fix for you.

Hock answered 7/4, 2010 at 8:39 Comment(0)
T
2

Add this to the CSS of every element that creates a problem:

 -webkit-backface-visibility: hidden;
Tuggle answered 12/8, 2014 at 21:49 Comment(0)
D
1

Simulate INPUT and A with DIVs.

[PSEUDO JQUERY CODE]

<div href="http://google.com" rel="a">Link</div>

<div class="field">
    <div></div>
    <input type="text" style="display: none" />
</div>

<script>
    $('div[rel=a]).click(function() {
        location.href = $(this).attr('href');
    });
    $('.field > div').click(function() {
        $(this).hide();
        $('.field > input').show();
    });
    $('.field > input').blur(function() {
        $(this).hide();
        $('.field > div').html($(this).val()).show();
    });
</script>
Danaides answered 6/4, 2010 at 20:46 Comment(0)
P
0

IE has this same problem and the solution there is to make sure that every element that is involved in the positioning and even their containers have a z-index applied to them. Basically if you add a z-index to 1 element in the dom then IE gets understands its z position but doesn't understand its z position relative to what its next to and/or over.

container - z-index 0
child (on top container) - z-index 1
child 2 (above all) - z-index 999

Of course this is all based on stupid IE but its worth a try in android also.


Second Try :)

I am not familiar with the android browser at all, but I hope to maybe lead you down a path to solve your issue. Superfish is a javascript menu that has implemented a solution for z-index menu items when they drop down over select boxes in browsers. BgIframe is the js that they use to achieve this. Your answer may lie there, hopefully.

http://users.tpg.com.au/j_birch/plugins/superfish/#sample2

Pinebrook answered 2/4, 2010 at 8:22 Comment(1)
It's a bit different than the IE problem; in IE, the elements are actually not displayed according to the spec. In Android Webkit they are, but the hit areas for <a> and <input> elements are not correct. Thanks for the thought, though!Acree
P
0

Put the under html in a div and set the display:none using javascript, so then the under content is gone, instead of being clickable and modal.

Plaid answered 8/1, 2012 at 22:38 Comment(0)
V
0

if you want to solve this problem, first of all you must add z-index to parent wrapper and clearly add z-index to your other elements, solution is that all elements will have a zero point for anderstanding z-index property correctly

Verret answered 16/5, 2014 at 13:58 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.