The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
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.
ReplyDeleteAs 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.
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.
ReplyDeletePut an iframe behind the absolute content. The iframe may obscure those elements for you
When you display your absolute content, hide all of the problem elements with JavaScript
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.
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".
ReplyDeleteI 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.
Simulate INPUT and A with DIVs.
ReplyDelete[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>
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.
ReplyDeletecontainer - 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
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.
ReplyDelete