Is There a Workaround for The Android Browser Bug with CSS-Position and Clickable Areas

Is there a workaround for the Android browser bug with CSS-Position and clickable areas?

Actually I've managed to avoid it by moving the objects below to let them be not visible.
But in cases similar to yours the only workaround that actually works is to manage all the clicks in jquery (especially the ones on the background) and to bind/unbind the clicks events on needs.
there are also some things that could help on some version/mobiles (but do not solve the problem)

• the above item has background:rgba(0,0,0,0.1);
• you should put a gif or png as background of the above element (as well as the background color as point 1)
• using thouchstart instead of click as bind event sometimes helps.

the actual version of android/browser are not affected with this bug (or at least it never happen to me) but it could be nice to know the affected versions. If someone has a list.

GlanceAppWidget with clickable row: inner elements steal focus and clicks

It's a known bug in Glance 1.0.0-alpha04. You can downgrade to 1.0.0-alpha03 for now, and it should hopefully be fixed in the next release

Update:
Here's a link to my post on the issue tracker, but there are a few others. And't it currently marked as "fixed", so it'll hopefully be working again in 1.0.0-alpha06

Mozilla Android AddressBar Conflict with Sticky Button on Bottom

Investigations using Firefox remote debugging

TL;DR: With high probability a bug in the Firefox mobile app

So I've linked up my phone to the computer and started a remote debugging session on the page you provided.

When inspecting the button element <button class="ocs-trigger ocs-toggle ocs-toggle-posts-toc-mobile">Περιεχόμενα</button> we can see the exact box position highlighted in the viewport: screenshot

And now it gets interesting. Apparently, the DOM box of the element gets shifted as soon as the bottom bar disappears. Or rather: The initial viewport (when the bottom bar is visible) doesn't change, because the box is still located at the same position.

So you can in fact still click/touch the button but in an area above it.

You can see this behavior in the screen recording below:

Cookie banner is repositioned as expected

Interestingly, the behavior of the cookie banner (hidden in the screen recording because already confirmed) looks as expected though. So what's the difference to the button?

Workaround and working solution: move the button above the #ocs-site element

Apparently, after quite a lot of experiments, I realized the only difference between the button (incorrect behavior) and cookie banner (correct behavior) is the fact, that the cookie banner is in a rather top level of the DOM, whereas the button is nested quite deep in the tree.

Finally, I could find a working solution that makes the button behave as expected. Here you can see the correct scrolling behavior:

The solution I've come up with is to move the .ocs-trigger button above the #ocs-site div element. This fixes the incorrect scrolling behavior when the bottom bar disappears/appears.

Also, apply some styles on the .ocs-trigger element for the correct positioning.

position: fixed;
bottom: 10px;
z-index: 11;
left: 0;
right: 0;

Here you see the final DOM in a screenshot:

Please note, that you probably have to apply additional styling changes. This solution's major aspect was to get rid of the incorrect scrolling behavior.

Follow-up: Firefox Bug? Seems to me.

As it still appears to me at this moment, I would say this is a bug in the mobile Firefox implementation. My guess is, that the viewport calculations are somehow incorrect for nested elements.

In order to get some attention on this topic, I would recommend you to share these investigations and documentation with the Mozilla team at https://github.com/mozilla-mobile/fenix/issues. Let me know if I can help you with this.

Webkit Browser 535 (Android native/ios5 safari) HTML5 Canvas Click bug

Ok, i've fixed this issue, but I think it's pretty case specific.

if(webKitVer < 535) {
     document.body.style.paddingTop = pos.top + "px";
    if(canSeeWholeOfCanvas) {
        canwrap.style.transform = 'translateX('+pos.left+'px)';
        canwrap.style.left = 'auto';
    } else {
        canwrap.style.left = pos.left + "px";
        canwrap.style.transform  = 'none';
    }
} 
else 
{
    //standard all browsers
    canwrap.style.transform = 'translate('+pos.left+'px, '+pos.top+'px)';
}

feels hacky, case specific and hard to explain. but it works

---

in old webkit browsers (generally Android native browsers and IOS5 safari there are two bugs

if the canvas is positioned with css top and left, then a duplicate GPU rendered canvas (generated for GPU hardware acceleration) will be rendered ignoring them properties so they're not aligned correctly.

if the canvas is positioned with css transform then the GPU duplicate canvas is correctly aligned, BUT when the canvas is positioned at minus X position then the only the part of the canvas that would be visible without the css is clickable

so changing between the two depending on visibility of the canvas is needed

Position fixed not working in mobile browser

position: fixed doesn't work in most of the older versions of iOS and Blackberry. I have tried this fix in most of the mobile browsers and it worked smoothly without any JavaScript plugins.

Use -webkit-backface-visibility: hidden;

.fixed {  position: fixed;  top: 0px;  left: 0px;  width: 320px;  height: 50px;  background: red;  -webkit-backface-visibility: hidden;  /*--^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Most Important*/}

<div class="fixed">  Hi I m Position Fixed</div><div>  sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>sample text  <br/>
</div>

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

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.

---

Related Topics