I'm using the jGrowl jQuery status-message plugin to display a sticky message on page load, and it works perfectly on all browsers except Internet Explorer 8. In this browser, there remains a small block, about 2 lines high but with no text, even after closing the sticky message. It does not have a close button, or anything, for that matter. Here is my code, which is placed in the document.onload function for IE:
$.jGrowl("Hi! Welcome to the site!", { sticky: true });
All other jGrowl settings are set to default, which is a floating message at the top right of the page.
Has anyone encountered this problem before, and perhaps know how to fix it?
This seems to be a bug in jGrowl, perhaps as a result of incompatibility with later releases of jQuery (the last update was in March 2008).
Maybe you can try NMS Message?
Related
We're using the javascript plugin Simple-ajax-uploader to upload files on your web site and it suddenly stopped working today (09/05/2019).
The upload div/button can't be clicked on anymore.
This is happening on our site and even on the official plugin site.
This is only happening on Chrome and only on computers where Chrome has been closed and restarted today.
We found out this article indicating that Chrome Dev tools have just been updated today but our version of Chrome hasn't changed since the restart (76.0.3809.132). However the restart definitely triggered the bug so something happened there. But what?
Same problem here found this morning.
Quick jQuery fix...
$('input[type=file]').css('position','relative');
UPDATE: Issue has been fixed with version 2.6.5 of the plugin. Ignore the below.
Plugin maintainer here. A short term fix is to remove or comment out line 2002:
'position' : 'absolute',
Alternatively: the issue does not appear to be present in Firefox. At any rate, I'll try to have a fix pushed soon.
I've just checked on Chrome and you're right about the button not working. It is a problem with the Stacking Context, unfortunately each browser has its own implementation.
Basically the outer div is preventing the click events from reaching the inner input.
My suggestion would be to use a custom button or to restyle the current one (I've found that if you remove the position property from the outer div it will work again. Consider that many properties can cause stacking context problems: position, transform, opacity, z-index. Try adding/removing/modifying some of them, in the outer div and in the inner input).
Anyway, it is guaranteed to be a style problem and not a JavaScript problem.
I'm having a bit of trouble with an if statement.
I've got a little lightbox popup error message running on the site. It works fine across everything except my windows phone where the popup load at the top of the screen (apparently ie mobile doens't like absolute positioning).
My solution is to simply scroll to the top of the page to display this (but only on ie-mobile.
Here's my code:
function checkiemob()
{
if (navigator.userAgent.match(/iemobile/i))
{
window.scrollTo(0,0);
}
}
If I remove the if statement this works fine. I've also tested the if statement with simply inserting text and that works too.
Cheers
I've been working some time on Hybrid applications, and i can tell that it's not worth it if you're not CSS professional and know everything about differences in browsers.
Don't know about absolute, but maybe it will give you a hint:
position:fixed - attaches element to the specified position on the page. ( HTML standart ). Works fine in Safari and Google Chrome.
But in IEmobile this position fixes the element to the display!
I think there might be same problem with you'r absloute
That means if i try to move whole page - in google and safari this fixed element will move along with the page, remaining on the same place, but in IEmobile it will stay on the same place
Problem: A div with visibility:visible inside a parent div with position:fixed and visibility:hidden causes rendering problems in Google Chrome. Images and examples can be found here.
A week ago you could just add the -webkit-transform:translateZ(0) to the parent div and bug solved. But it isn't working anymore:
Without -webkit-transform
With the hack.
Both are bugged.
So, is there any solution? When you resize the window, it repaints the divs, also when you open the developer tools the bug disappears.
So I've been trying to force a repaint with javascript (jQuery):
jQuery(window).scroll( function() {
jQuery("#parentDiv").addClass("nothing");
jQuery("#parentDiv").removeClass("nothing");
});
And it sometimes works (when a textfield is displayed inside the inner div). Really weird. Also tried hiding and displaying the div, adding css properties (fixed, bottom:0...)
But nothing works fine.
Any ideas?
EDIT2: Seems like it only happens to me: 2 friends, using windows and the latest version (17.0.963.79) don't see the bug in the second link. But I still see it. I've reinstalled chrome under windows, and the bug is still there.
I also have cleared the cache, but nothing changes. Am I the only one????
from my own experience when working with scroll(), all form-elements behave strangely, or do not function anymore.
You solution -webkit-transform:translateZ(0) will fix it for webkit browsers, but all others browsers will trow a translated layer above all form-elements, result is that form-element are not accessible anymore.
scroll() is a great solution for just plain info (text- images), not for forms.
I am building a site that has an image map menu with a popup box that is supposed to pop at the mouse when the mouse is hovering over a particular area. It works great in firefox and IE but when I load the page in chrome the boxes appear as if the page were not scrolled. it works fine if the page is scrolled all the way to the top, but as soon as the user scrolls down, the boxes are to high on the page.
I am using a script i got from http://www.dhtmlgoodies.com/index.html?whichScript=bubble_tooltip www(dot)dramanotebook(dot)com/menu/ (i can only put one hyperlink in)
Thanks in advance for Your help
Thats a bug in this script that also shows up on the example page. Maybe its enough to delete this line:
if(navigator.userAgent.toLowerCase().indexOf('safari')>=0)st=0;
I was about to ask 'have you tried this in Safari?', since Chrome and Safari both use the webkit engine.
Take a look at the .js file.
function showToolTip(e,text){
/* blah blah*/
var st = Math.max(document.body.scrollTop,document.documentElement.scrollTop);
if(navigator.userAgent.toLowerCase().indexOf('safari')>=0)st=0; /**** THIS ****/
var leftPos = e.clientX - 100;
/*etc.*/
}
It has a fix applied specifically to Safari, using the userAgent string. Chrome sends 'Safari' in the user agent string, too, so it will apply that to Chrome also. This is generally considered a poor practice. In general, I'd say the scripts from dhtmlgoodies are very outdated. Is this fix still needed for newer webkit renderers? Who knows. You might try commenting it out and seeing if that fixes it.
This problem occurs in Firefox and Chrome, but Safari is fine. IE8, however, in compatability mode or not, doesn't load the overlay over the top (it just sits at the top, scrolling the content down - although I guess this is because the overlay is at the top of the markup).
It also doesn't show the image I'm attempting to show, but shrinks the overlay loading image to nothing in the top left of the screen. I am using the standard colorbox-min and the CSS that goes with that.
Inspecting the markup in the IE8 dev tools seems to hint that the content is not actually loaded into the cboxLoadedContent div.
$(document).ready(function() {
$('a[rel="preview"]').colorbox(
{
photo: true
, maxWidth: '95%'
, maxHeight: '95%'
, photoScaling: true
}
);
});
basically the page is a list of media images and when you click one it gives you the preview and allows you to scroll through ones on the page
well at least it does in FF took a little screenshot as it was shrinking the overlay thingy http://dumpt.com/img/viewer.php?file=7s2zwoxozzf7666h0fzc.png
Anyone have any ideas?
I expect my explanation is not great, so maybe I could take a movie of it or something if needed.
Is your code wrapped in a ready function? I've seen instances where code that works in FF/Safari fails in IE because IE seems to load the DOM more slowly. In those cases it almost always turns out that I've failed to wrap the code in a ready function.
$(function() { // the important bit
$('.colorbox').load('...').colorbox();
});
Try an XHTML strict doctype...?
I've experienced the exact same symptoms - but in my case it extended to all browsers.
One cause was that I didn't include the CSS file that I use for pages that use colorbox.
Another cause was I updated to the newest version of jQuery, but didn't upgrade colorbox. (Also, if you update your jquery include, make sure that you also update your jquery vs doc - if you're even using it).
Hope that helps.
Search through your colorbox files for this:
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader
There will be several instances of it, each pointing to a png. Make sure the path to that png is correct, then test it again.
I'm pretty sure I had this exact problem at one point, and fixing the paths was all I needed to do. However, it's been a while so my memory is a little fuzzy.
I had the same issue. I also had a problem with the image being only 10px wide due to IE not liking CSS max-width being set to 100%. To alleviate the problem I add the following to my CSS.
.cboxIE img
{
max-width:none;
_max-width:none;
}