I'm working on a site which is supposed to support both mobile and desktop devices. I'm using jquery-address plugin to make an image gallery which can use hash tags to be deep linkable.
But I'm noticing a problem in ipad simulator with iOS5 and iphone 5 where I have to click a category within the image gallery twice on the image gallery to get the event to work properly. It works fine on chrome/safari/firefox on OSX with one click.
So far I've only seen this on iphone/ipad. Any ideas about why desktop browsers work fine with one click, but iOS on ipad/iphone need two? I'm at a loss here. I can't tell if the problem is with my markup/javascript or an obscure bug in jquery-address/safari on iPad/iPhone.
I'm pretty sure this is due to your markup and having a hover state on .gallery-category:
.gallery-category:hover {
color: white;
cursor: pointer;
}
iOS doesn't support :hover in the normal way because there's no way to detect a hover state without a mouse. It usually sorts itself out on straight up a:hover states, but I'm guessing because your markup is a bit complicated (and there's a :hover state on the parent) it's causing it to break.
I think if you replace the above snippet to work on
.gallery-category a:hover {...
it will fix it (I haven't tried it on your code though)
Related
I've been developing a large single page application and in the process have run across a series of rendering artifacts, all of which are specific to chrome. My version of chrome is the most up to date as of this post: Version 39.0.2171.95 (64-bit). Both of these only happen on my macbook pro retina monitor, if I move the window either partially or fully to another monitor, the part that is on that monitor no longer shows the artifact (after chrome repaints) Such a first world problem I know...
My gut is telling me that if I tweak a certain CSS property or go about something slightly different, I can avoid these issues, but everything I've tried has failed. So I look to you wise members of the stack community, gather 'round and hearken to my tales:
First Artifact: Simple hide show fails hard in a seemingly random but highly reproducible way.
Check these three images, one is not like the other!
Each little icon at the top hides or shows a different div. They're all equivalent, just show a different number of those traffic related icons. The middle one will not show up only when i first click the left one (one with all the cars). I think it has to do with the fact that the one with all the cars has a scroll bar. If I then go into chrome inspector and like check or uncheck pretty much any property about it, chrome repaints it just fine. Again this all works on a different monitor/literally any other browser (including ie8) so it's not some dumb coding bug.
Second Artifact: When I scroll, a fixed div at the bottom of my page gets cut and moves with the page.
Notice that the blue bar gets cut! The blue bar has CSS as follows:
position: fixed;
bottom: 0px;
left: 0px;
right: 0px;
border: 1px solid #777777;
background-color: #e5f1f8;
z-index: 15;
It doesn't even get cut right where there is some sort of divider in the html. There is no element at at the line of the cut, the only nearby element is the white box (and there's no like padding or margin from that white box.. it's literally getting cut randomly in space)
Any help would be appreciated. This is a huge pain when all we have to demo is our retina screens.
Just had someone else on SO with issues getting elements to render correctly on Chrome with a Retina display too: How can I remove the single pixel space between these elements on retina displays?
It looks like Chrome on a Retina display may have some rendering engine issues when it comes to rendering page elements. You can confirm whether its an Engine issue by seeing if the same issue occurs in the latest version of Opera, as it uses the same Blink rendering engine as Chrome (separate fork from Webkit that Safari uses).
If its an engine issue, you may be limited in your options to fix the issue until Google releases a fix. Otherwise there may be a mad genius on here who can work around the problem.
Best of luck :)
As for the position fixed bar try editing the css to this
position: fixed;
bottom: 0px;
width:100%; /* or whatever your width is */
height:50px; /* or whatever your height is */
border: 1px solid #777777;
background-color: #e5f1f8;
z-index: 15;
As for the display problem, if it works fine on other webkit browsers that usually indicate that there is an issue with the browser itself and you can't do anything about it except maybe make a rule for the screen size that is having the display issue, to show the website or app in a different style or maybe zoom in or out?
Anyways best of luck with your problem
Unfortunately YouTube only counts views to videos when you click directly on the YouTube player itself. This is to prevent fraudulently high view counts. One technique if you don't want to show the YouTube player initially is to put an opaque overlay and graphic over the top with pointer-events: none. When the user clicks on your overlay they will actually be clicking on the YouTube video so the view is counted. You then capture the 'playing' event and hide the overlay exposing the player underneath.
I have a graphic on my homepage and when you click it plays a YouTube video. Before anyone cries 'clickjacking' I'm not trying to trick anyone - there's a play button in the graphic so you know it's a video.
This works completely fine for me for everything except FireFox on Mac OS. I am using the latest version - currently 34.0.5 in my tests.
Demo page : http://www.googledrive.com/host/0B3INRRYhLi7cVHNKTzhMdnRjT3M
If you run this in Chrome / FireFox Windows / Recent IE version and click on the green overlay the video will play and you will hear music.
Note: Of course in my real page I capture the isplaying event and hide the overlay.
Firefox is obviously doing some kind of clickjacking protection. If it thinks that you're trying to trick the user with an overlay over the video then it won't play it. However it is really bizarre to me that it doesn't also do this on Windows.
There are two ways to allow the video to play on Mac FireFox - both involve partially revealing the Youtube video underneath:
If you click 'Change opacity to 75%' it will show the video through underneath. If you then click it then it will play just fine.
If you click 'Make overlay smaller' it will make the overlay not completely cover the video. Clicking on it will then play just fine.
The most bizarre thing of all - when you view it in an iframe it works just fine (this is why I'm using a GoogleDrive link above that opens fullscreen) and not something like codepen/jsfiddle http://codepen.io/anon/pen/GgrZNN
I'm really looking for a workaround that doesn't involve if (firefox && mac). If this is documented somewhere in mozilla docs I haven't found it.
PS. Obviously browsers without pointer-events have to be treated differently with an on-click event. That is not shown in this example.
(I'm using Browserstack.com to test, but it does the same on a real mac.)
I get the same issue Firefox Mac (and have yet to upgrade to Yosemite), but it seems to me you have pretty much already solved your own problem. The simplest solution that I can see would be to add an extra overlay layer beneath your current one and set them both to opacity 0.98 (which seems to be the highest you can go and still have the click work — at least in my tests).
Obviously it will depend on what you hope to show on your overlay, but for my tests locally I set the under-overlay (sorry, ridiculous name) to black. This meant that the video underneath was imperceptible. You could probably even go a little lower with the opacity and still block everything out with two layers, just in case the opacity thresholds for the click blocking are different across versions of Firefox.
.x-overlay {
opacity: 0.98;
...
}
.x-under-overlay {
opacity: 0.98;
position: absolute;
background: rgba(0, 0, 0, 1);
width: 100%;
height: 100%;
overflow: hidden;
pointer-events: none;
}
NOTE: One downside to be aware of when using even slight opacity. For certain browsers (or at least versions of browsers) text that appears in a layer that has opacity can end up with buggy or missing anti-aliasing. But this mainly occurred in much older versions of Firefox and Chrome.
update
Ok this was driving me a bit round the wall, or up the bend, or which ever strange phrase that can be used to describe the experience of continually expecting one thing, but consistently getting another... which has eerie similarities to the definition of crazy.
Why on [insert home planet here] did this work for Codepen, but not in my own localhost-served iframe...??
After attempting a number of different things I spotted the sandbox attribute, which I really should have noticed before; especially considering all the strange trickery it can enable and disable with native browser processes. A quick trial and a few errorings later, and it seems what allows this to work for most of those online-code-fiddlers is the following:
<iframe src="index.html" sandbox="allow-scripts allow-same-origin"></iframe>
Still haven't found out exactly why, but if I enable the above on my localhost frame it starts working without the need for the opacity trick. I guess it must cause Firefox to route through a different process, or perhaps it just disables some kind of cross-origin clickjacking protection.
A very odd state of affairs... this is the kind of oddity I would expect from Chrome! Not good ol' Firefox.
I'm working on a web page design and Chrome is wigging out when I change a stylesheet. I'm trying to switch between light and dark themes.
I have this <link> to start:
<link rel="stylesheet" href="/css/dark.css" id="theme">
To change the theme, I'm doing this:
$('#theme').attr('href', "/css/light.css");
I have code to actually toggle (loads dark if light is loaded, and vice-versa). Whenever the stylesheet of the non-default theme is loaded, it likely -- but not always -- glitches after I move my mouse around. For instance, after I first toggle the theme to the light theme:
It actually does repaint the full page with the theme for a split second, but then it turns the screen black (but it does not revert back to the dark theme, as the dark theme is not black; it actually has a dark gradient).
When I move the mouse around some more:
The white area expands in blocks over where my mouse is moved, until I move it over most of the page it goes back to what I expect. Or, I can resize the window and Chrome fully repaints the page as expected.
Removing the fancy tooltip doesn't fix the problem:
I've tried invoking a window resize event. I've tried using jQuery to show/hide the html and body tags to try to trigger a repaint. I've also tried deleting the theme's <link> tag entirely and adding a whole new one to the DOM. Alas, I see the same effect.
Firefox and Safari don't behave this way. But I absolutely have to get this working on Chrome. Any ideas?
Update (March 2014): This page is part of the web UI of GoConvey. It still renders fine in Firefox, and the glitching in Chrome at this point is less frequent and slightly different in its nature, but it's still there. Anyone is welcome to take a look if you are feeling generous.
Wow. Here's the CSS hack to fix it:
-webkit-transform: translate3d(0, 0, 0);
This forces Chrome to use the GPU to render the element. I no longer see the glitching.
Update about a month later: Okay, well, I've continued to develop this web app and now the glitching is back. Still trying to work around it. Now sometimes the whole viewport goes blank and I have to resize the Chrome window in order to get it to re-appear.
If anyone would like to try this and see the glitch live, the page is GoConvey's web UI (Chrome on Mac).
I'm not a web developer, but I was dabbling with 3D CSS transformations and animations and found that they didn't interact with :hover the way I hoped or expected. I wasn't able to readily find any disclaimer that this is a known problem, so I'm wondering if I'm just doing something wrong.
To reproduce the problem simply, start from this demo 3D cube animation here:
http://cssdeck.com/labs/simple-css3-3d-cube
Add this to the bottom of the style section:
#cube div:hover {
background-color: white;
}
I'm looking at that, using Chrome. I was hoping that, as both the cube rotated and the cursor moved (or didn't) the front-facing side containing the cursor would have a white background. But in practice that doesn't happen properly. If I scroll the cursor over the animation it picks out the correct panel to highlight but then it often fails to update when it should. Most noticeably, if I stop moving the mouse it doesn't seem to detect any change in what element the cursor might be hovering over.
Is this a known shortcoming? Does anyone have a solution?
It appears there's a difference in Chrome's Webkit engine vs Firefox's Gecko engine. Firefox continually runs to check a hover status, while Chrome does not.
I tested it in Chrome and Safari (both run Webkit) and they have similar results. They do not update the hover state if you keep the mouse still. Firefox, on the other hand, continually checks the hover area when the mouse remains in the same place.
Working on an image heavy website, discovered a strange bug(?) in Firefox. Any CSS background properties are rendered onto transparent png's. It occurs after the initial render, during the cache refresh. This appears as a flicker if you're using broadband but becomes extremely noticeable as you scale down bandwidth.
General progression of the issue seems to be:
Page and images rendered from cache
Firefox removes the cached images.
Firefox begins to reload images but displays a box with the CSS properties of the background.
I've recreated a (hideously colorful) example, but you may need to use fiddler, or another program with bandwidth throttling/emulation to see anything more than a flicker. Obviously, you'll also have to load once and then refresh to experience the error. And again, it's only in Firefox.
I have tried a plethora of various suggestions, none worked. Just need a fix, hacks will work as long as they don't effect other browsers.
EDIT: Here's a video so you can see it in action.
Since I cannot recreate the issue on my Firefox (10.0.2) on my computer (Win 7) with my particular hardware (which may or may not be a part of this problem), I offer the following as a guess at a solution, though one I would have assumed you tried already.
Target your img tags (preferably with some css more specific than below) that you have the issue with and try setting one of the following:
Either:
img {background-color: transparent;}
Or:
img {background-color: transparent !important;}
Update: Another Possible Workaround
Have javascript make the relevant img tags invisible to start and also bind an event to them so that when they load, they become visible again (JQuery example):
$('img').css('visibility', 'hidden'); /*not using "display" keeps layout*/
$('img').bind('load', function() {
$('img').css('visibility', 'visible');
});
I cannot test the above, so no guarantee it will work, but is another idea.