It appears to me that if the map container is placed anywhere but the top left corner of the page, pinch zoom is no longer centered properly. I have encountered this problem on iPad 2 (Safari 5.1), iPhone 5 (Safari 7.0), Sony Xperia tablet Z (Chrome 34.0).
If i have missed something obvious as comes to forcing this thing into expected behavior, I would be delighted to have this pointed out to me. Otherwise I'm inclined to call this a Here bug.
This simple fiddle replicates the issue when used with a touch screen device
http://jsfiddle.net/Thernys/E97rn/
And since apparently code is required with a fiddle link, I replicate the relevant parts of the super simple example.
HTML
<body>
<!-- add a number of <br/> if you like -->
<div id='mapContainer'></div>
</body>
CSS
#mapContainer {
width: 200px;
height: 200px;
float: right;
}
JS
var nMap = new nokia.maps.map.Display(
document.getElementById('mapContainer'), {
zoomLevel: 10,
center: [52.51, 13.4],
components: [
new nokia.maps.map.component.panning.Drag(),
new nokia.maps.map.component.zoom.Gesture()
],
}
);
I've faced this exactly same issue. After some research I realized that it's occurring because the map container wasn't placed in the cartesian origin of the document (top: 0, left:0). I don't know if this is a bug of the API or if there's any configuration that fixes it.
The workaround I found out was to create the map inside an iframe element and make sure it occupies the entire width.
Related
I am using bootstrap datepicker on a website, It is also styled to be sticky by giving its parent a fixed position, Its working fine normally but on testing it on Ipad and Iphone (not tested on andriod devices yet), when I scroll down and try to touch the datepicker to open it , it scrolls back to the top of the page, how can I fix this issue?
Similar problem arises when I am using a custom dropdown Selectric
I have created a simple striped down version of the problem here. Note that the problem wont replicate on emulator but on an actual mobile device or ipad.
I also faced same issue and resolved it as below solution , you can try it.
datepicker has beforeShow property where you have to set calendar position.
$("#EffectiveDateAccept").datepicker({
changeMonth: true,
changeYear: true,
// minDate: 0,
dateFormat: 'mm/dd/yy',
beforeShow: function (input, inst) {
var calendar = inst.dpDiv;
setTimeout(function () {
calendar.position({
my: 'center bottom',
at: 'top',
collision: 'none',
of: input
});
}, 1);
}
});
Try this
.dropdown-menu{
position: fixed!important
}
This issue is found unrelated to specific environment (not iOS only) and has a solution as follows:
You should find out which datepicker div class sets datepicker actually from hidden to visible (which of them change upon successful show and hide event).
Add to your css for that class (here modal-open) the missing show command:
body.modal-open {
overflow: visible;
}
Now the scroll should stay in place.
Example refers to html like:
<body>
<div class="modal-open">
Datepicker
</div>
</body>
Source:
Bootstrap modal: background jumps to top on toggle
PS. My source has also 18 other options, if this seems too hacky.
I have made this current one once, worked like charm and was not so tricky to do.
just add This CSS code to your site it will fix that issue.
.element{
position: sticky!important;
}
If you view it in Inspect Element, it's creating a separate DIV in HTML which has position absolute. Just change that position to sticky. That's why that happens. See in the image.
You can do this by adding this line of CSS code:
.dropdown-menu {
position: sticky;
}
Hope that will help you
As a start, have you looked thru the GH repo's issues for something matching your description?
This link specifically sounds promising:
https://github.com/uxsolutions/bootstrap-datepicker/issues/1866
I think what might be occurring is that your datepicker is set to absolute of the body, not the parent you are setting as "fixed".
So when you click to open the datepicker, your mobile device is scrolling you to the active element (in this case, the datepicker at the top, set to absolute on the parent).
Also there seems to be some default mobile behavior related to scrolling:
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
Perhaps setting the following will help:
-webkit-overflow-scrolling: auto; /* Stops scrolling immediately */
The following link provides more context on this scrolling behavior:
https://weblog.west-wind.com/posts/2015/Jun/05/IPad-Scroll-Issues-with-Fixed-Content
I'm trying to add a google maps autocomplete input to my ionic app. It works pretty well except when I scroll. As shown on the image:
So I tried different things like changing the position of .pac-container but it doesn't solve the problem.
When I inspect the page, it seems that the results container loads at the end of the page, so it's not easy to make the block stick to the input bar.
I already searched everywhere and didn't fidn any suitable solution ? Does someone have an idea how to do it ?
(It's actually just a simple code like this:
function initialize() {
var options = {componentRestrictions: {country: 'uk'}, types: ['geocode']}
new google.maps.places.Autocomplete(
(document.getElementById('autocomplete')),
options
);
}
initialize();
jsfiddle
Thanks
I have the same problem. My solution was:
$('#inputContainer').scroll(function(){
//Set new top to autocomplete dropdown
newTop = $('#autocompleteInput').offset().top + $('#autocompleteInput').outerHeight();
$('.pac-container').css('top', newTop + 'px');
});
This update the dropdown position when container scrolls.
I just encountered the same problem when I was implementing the Autocomplete on a form inside a scrollable modal. If you only have one Autocomplete object then the solution is relatively easy.
First make sure that your element's parent has a relative position.
Then you need to select the .pac-container and append it to the parent.
$("#autocomplete").parent()
.css({position: "relative"})
.append(".pac-container");
Finally set the .pac-container left and top position to be below your element. This needs to be done in a stylesheet with the !important declaration to ensure it overrides the inline styles set by Google's code.
// these values will need to be calculated based on your layout
.pac-container {
top: 40px !important;
left: 0px !important;
}
This obviously wont work if you have multiple Autocomplete objects on a single page. Luckily I figured out a way to handle that scenario and recently published it in a jQuery plugin designed to make autocompleting address forms a breeze.
I got the solution check the example no issue with position bug when scroll
function initAutocomplete() {
//....codes...
//....add this code just before close function...
setTimeout(function(){
$(".pac-container").prependTo("#mapMoveHere");
}, 300);
}
https://codepen.io/gmkhussain/pen/qPpryg
In my case, I had to set the css as html,body{overflow-x:visible;} to make the pac-container fixed to the input field.
I was now able to reproduce the problem, the solution is simply adding position: relative to your wrapper box and position: absolute to your #autocomplete input.
I got the solution checking the example provided by the Google team.
I've updated your fiddle to match the solution, but it goes like this:
Your updated CSS:
.box {
position: relative;
height: 200vh;
}
#autocomplete {
width:350px;
position: absolute;
}
Since my input field is inside "ion-content", I implemented Nicolas Pennesi
's answer with ion-content's method:
onScroll($event) {
// his code here
}
I have a video that the client wants to sit "seamlessly" in the website. The background HEX color of the video matches the HEX background color of the website, and renders as such in some browsers, some versions, some of the time?
What is most curious is Chrome renders the background of the video differently, until you open the color picker. Then they suddenly match. To be clear, it only fixes it once I open the color picker, not the debugger (read: this not a repainting issue).
Firefox renders differently when I first navigate to the site, but if I hit cmd+r, it becomes perfectly seamless.
Take a look at the screenshots - they say more than I can with words.
I'm in the process of convincing the client to change to white background for the video as that will certainly "fix" it, but I'm super curious as to what /why this is happening.
Any insights from you wizards out there?
Codepen: http://codepen.io/anon/pen/zrJVpX
<div class="background" style="background-color: #e1dcd8; width: 100%; height: 100%;">
<div class="video-container">
<video id="video" poster="" width="90%" height="auto" preload="" controls style="margin-left: 5%; margin-top: 5%;">
<source id="mp4" src="http://bigtomorrowdev.wpengine.com/wp-content/themes/bigtomorrow/images/videos/bt-process.mp4" type="video/mp4">
<source id="webm" src="http://bigtomorrowdev.wpengine.com/wp-content/themes/bigtomorrow/images/videos/bt-process.webm" type="video/webm">
<source id="ogg" src="http://bigtomorrowdev.wpengine.com/wp-content/themes/bigtomorrow/images/videos/bt-process.ogv" type="video/ogg">
We're sorry. This video is unable to be played on your browser.
</video>
</div>
</div>
The issue is not solely browser dependent but render dependent. As soon as the browser renders the video with hardware acceleration the GPU preferences affect the color.
For instance, if you are using an Nvidia graphics card, you can change the color preferences in the Nvidia Control Panel. Desktop monitors usually use the full RGB range from 0 to 255, but you can also configure the limited RGB range from 16 to 235. The limited range is generally used by TVs.
On the one hand graphic card drivers sometimes default the color range of desktop monitors to the limited RGB range. On the other hand users may change this value themselves.
Since you can't influence the user's browser settings nor the graphic card driver settings, there will always be differences for distinct users.
How are the colors affected:
Full RGB range -> limited RGB range
#000000 becomes #161616
#081F3C becomes #172A43
#FFFFFF becomes #EBEBEB
Here is my approach to solve this issue:
I've tested it with Chrome, Chrome on Smartphone, Edge, Firefox and Internet Explorer 11. Edit: the tests are from 2017, but as mentioned in the comments by
Jomal Johny, it doesn't work in IE11 anymore. After a test, I can confirm, that it doesn't work in IE11 in 2021.
As soon as the video is ready to be played or played back, check the first pixel of the video and change the background color of the surrounding container accordingly. This will work regardless of browser settings and rendering configuration.
This is the code:
<!doctype html>
<html>
<head>
<title>Video</title>
<script>
function isColorInRange(expectedColor, givenColor) {
const THRESHOLD = 40;
for (var i = 0; i < 3; i++) {
if (((expectedColor[i] - THRESHOLD) > givenColor[i])
|| ((expectedColor[i] + THRESHOLD) < givenColor[i])) {
return false;
}
}
return true;
}
function setVideoBgColor(vid, nativeColor) {
if (vid) {
var vidBg = vid.parentElement;
if (vidBg) {
// draw first pixel of video to a canvas
// then get pixel color from that canvas
var canvas = document.createElement("canvas");
canvas.width = 1;
canvas.height = 1;
var ctx = canvas.getContext("2d");
ctx.drawImage(vid, 0, 0, 1, 1);
var p = ctx.getImageData(0, 0, 1, 1).data;
//console.log("rgb(" + p[0] + "," + p[1] + "," + p[2] + ")");
if (isColorInRange(nativeColor, p)) {
vidBg.style.backgroundColor = "rgb(" + p[0] + "," + p[1] + "," + p[2] + ")";
}
}
}
}
function setVideoBgColorDelayed(vid, nativeColor) {
setTimeout(setVideoBgColor, 100, vid, nativeColor);
}
</script>
<style>
body {
margin: 0;
}
#my-video-bg {
height: 100vh;
display: flex;
align-items: center;
background-color: rgb(8,31,60);
}
#my-video {
max-width: 100%;
margin: 0 auto;
}
</style>
</head>
<body>
<div id="my-video-bg">
<video id="my-video" preload="metadata" onplay="setVideoBgColorDelayed(this,[8,31,60])" oncanplay="setVideoBgColorDelayed(this,[8,31,60])" controls>
<source src="video.mp4" type="video/mp4">
</video>
</div>
</body>
</html>
The play event and setVideoBgColorDelayed function are for browsers like Internet Explorer, which sometimes already fire the canplay event, although the video data is not yet available to the drawImage function of the canvas.
The function isColorInRange prevents harsh background changes, if the canplay or play events are fired before the canvas can get the pixel.
It is important, that the functions are defined before the video element.
If you load up the javascript at the end of the document, as it is often suggested because of page loading performance, then the approach won't work.
It seems like it might be fundamental to how the browsers render video, and not an easy CSS/HTML fix. Your question sounds similar to this question. I am betting the answer lies in some combination of rendering engines and colorspace differences, which may mean there is no good way to fix it across browsers.
On firefox, you could try fiddling with color management settings to see if that changes the behavior. This won't fix the problem, but it could help explain it. In the URL/search bar, enter "about:config". It should take you to an options page. Another search bar will appear rendered in the page, enter "gfx.color_management.mode". That option can take values 0,1,2. Try switching them up and reloading the page (may need to restart firefox) to see if you can get a consistent difference. It's possible it won't make any difference if the color is not being managed in the first place though.
Similarly, you could try disabling hardware-accelerated video decode in chrome. Enter "chrome://flags" in the chrome URL/search bar, then find the flag "Disable hardware-accelerated video decode". Change whatever value it is, restart chrome, and check the colors again.
Neither of these are solutions I realize, this may have been better served as a comment, but I don't have the rep for that yet.
Exporting videos and images in sRGB or Adobe RGB should resolve this problem. We had a video with collor profile HD (1-1-1), and that was causing video background to be slightly lighten in Safari than in Chrome. Tested on macOS
If your background is pure black or white you can simply increase the contrast slightly in your css and the issue will be fully solved:
filter: contrast(101%);
Original idea from Jack.
Export a second video but limit it only to the background color you have on your main video. So now you have your original video, and a second video which is 1 second in length and is just a flat color only.
That video tag should have the following css:
#bg-video {
position: fixed;
width: 100vw;
z-index: -1;
}
and the video tag can be at the top of your document.
<body>
<video id="bg-video" src="assets/bg.mp4" muted></video>
<div>your main site html here</div>
</body>
Since both videos are exported the same way, the colors should also be rendered the same on multiple browsers and/or operating systems.
*Note that your 'background video' should be more or less a square/rectangle so that when it scales, it will cover the browsers width and height.
I feel the proper solution here is to film using a green screen (which you probably already did) and use
Transparant webm video or
Replace green pixels with transparant ones using javascript canvas
An example of transparant video can be found here:
https://jakearchibald.com/scratch/alphavid/
Check this working demo.
Define background color for video container as #e1dcd8;
or replace your existing css with the following:
body, html {
height: 100%;
margin: 0;
padding: 0;
}
.background {
background-color: #e1dcd8;
width: 100%;
height: 100%;
}
.video-container{
background: #e1dcd8;
}
video {
margin-left: 5%;
margin-top: 5%;
}
When working with a web application after having installed it to 'home', it seems like a most recent update to iOS has caused the usual black status bar to go transparent and float above the web content below it.
Also, not pictured, is a horizontal bar at the footer of the app that pushes my fixed footer about 20px up.
I don't expect to always be serving this application via iPad (most clients would opt for the lesser expensive Android option), however it is very common for my associates to be demonstrating the application with their own iPads...
What options do I have here? Will I need to do some 'sniffing' and shift the application down just for this device/version? If so, what is the best way to do this without introducing more libraries? I'm currently using the latest Angular framework + .NET 4.5.1.
Thanks.
Well, since there was obviously a whole lot of interest in this question, I have since found an answer to the problems.
In the root of the application I created the test for modern iOS 8
var userAgent = navigator.userAgent;
$rootScope.isIOS = ( userAgent.match(/(iPad|iPhone|iPod)/g) && userAgent.match(/(OS 8_0_)/g) ? true : false );
In the primary wrapper before the navigation element I conditionally place a block
<div ng-if="isIOS" class="isIOS"> </div>
Then I have the sass class
.isIOS {
position: fixed;
z-index: 10000;
top:0;
width: 100%;
height: 23px;
background: $fooColor;
& + div {
margin-top: 25px;
}
}
and the TOP is taken care of...the status bar has a background that stays fixed and scrolling through any of the pages looks great.
The space I encountered at the bottom was a little different and required the following meta-data in the base layout.
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent"/>
Anyways...all is good now. If you came here and found this and it helps, awesome. If you never came here it all then it really doesn't matter a whole bunch, now does it?
Using css-transforms on a YouTube embed renders the video black in at least Safari 5 and Firefox 4. Chrome 11 handles it just fine.
I've made an example here: http://jsfiddle.net/oskarrough/4vRzd/4/
I need the css-transform in order to do some fancy layout positioning. Is there any way, css or js, to hack it to display the video?
I am tackling the same problem right now. I am not doing any fancy css transformations, just scaling.
Although not working perfectly, I got the video to display by using the wmode=transparent option.
i.e.
<iframe width='640' height='480' frameborder='0' src='http://www.youtube.com/embed/YOUTUBE_VIDEO_ID?wmode=transparent' type='text/html' class='youtube-player'></iframe>
Are you sure you can't use this instead:
iframe {
position: relative;
top: 100px
}
http://jsfiddle.net/4vRzd/5/
Or margin-top: 100px, or a negative margin on some other element?
Someone had to post this, because you didn't mention that they aren't viable options.
Upvote for lawrenceshen.
The wmode=transparent worked.
var player;
function onYouTubeIframeAPIReady() {
console.log("onYouTubeIframeAPIReady");
player = new YT.Player('gallery-youtube', {
height: '594',
width: '883',
videoId: 'u1zgFlCw8Aw',
playerVars: { "modestbranding":1, "wmode":"transparent" },
events: {
'onReady': onPlayerReady,
'onStateChange': onPlayerStateChange
}
});
}
For me, this problem only occurred in Firefox 4+ on Windows 7 and Windows 8. It didn't happen on any other browser or on OS X.
I spent hours stuck on this problem. I display YouTube videos in a modal which uses CSS3 translations to slide into view.
My solution was to remove the transform/transition classes once the modal has appeared.
Once I did that YouTube embeds appeared and no more empty black box.
More details: I use animate.css and add class="animated fadeInDownBig" to slide the modal down. Once it has reached its final destination, I remove those classes again.
It's a really strange problem which I hope Mozilla fix really soon.