I have the below site:
http://kelseydelo.com/
When I click the main nav links in Safari the content slides properly. However in Chrome and Firefox nothing happens when I click these (no errors in Firebug either).
I believe it used to work in FF so it seems a recent upgrade has broken it.
Anyone know what the problem could be?
you use mootools 1.2.3 which is old. in 1.2.3, mootools utlised feature detection for browser detection - and in particular, it was a problem with firefox as it relied on the following code:
if (!document.getBoxObjectFor ...)
but that method got made obsolete by mozilla. subsequently, in 1.2.5 and 1.3 mootools detection was done so it does not rely on this any more (breaking change was FF 3.6.nn or something)
on your site in FF 4.0 you can run
console.log(Browser.Engine)
and it comes back as 'unknown' - which will make any browser-specific hooks and fixes fail.
In Chrome 13 Canary, it detected webkit fine but does not work either so there must be something else -- legacy here... in other words, UPGRADE to 1.3.2 (which uses ua-sniffing) - if noobslide supports it, else go 1.2.5.1
Related
There is an issue with the hover effect that only appears on Safari 10.0.
The web is this:
Manu Caballero
What is happening is that the effect is working radomly, or not working at all:
To see it working, you can use Chrome or Firefox.
The most strange thing is that, on Safari 10.0, if I try to use the inspector, the hover effect works...
On Safari 10.1 and other common browsers like Chrome, Firefox... is working perfectly.
Looking at this site it appears to be using jQuery 1.12.4 and jQuery Migrate 1.4.1 - this is adequate if you need to support IE6 but not something I'd expect to be sufficient for Safari 10 (released after these legacy libraries).
On top of this you appear to be using Isotope 3.0.1, which is also about a year out of date.
So, first I'd recommend:
Upgrading to a current version of jQuery and dropping Migrate - IE6 is dead and IE8 is marginal.
Upgrade Isotope to the current version.
In particular check their issue logs for similar issues before raising them on here.
If the problem persists after that then you may have an issue specific to your implementation. Isolate the code in a snippet in your question - it's much easier for us to help you with one specific issue without reverse engineering your entire site.
Delete this code https://yadi.sk/d/YmKdx2Rd3M2Fcj and your effect will be work fine
and look this video https://www.screenmailer.com/v/EEa7t15khxyLE9s
I have one of those issues that I have been staring at and researching, but can't figure out.
I am loading a listing page with a hash: (example URL)
service_page1.php?u=XX01-TR000016#000016
I have my anchors set: (Example Code)
<div class="b_list_normal_row_ws">
<a name="000013"></a>
<div class="b_list_row_item_But"><img example />
</div>
</div>
Currently I am testing within Safari (latest version) on a Mac. When I load the page, it scrolls to the proper spot for the anchor and then scrolls to the top. I have read other threads about stopping the auto-scroll to the top, but not found one (as of yet) that solves my problem.
Update: I have been working to figure out what could be causing this issue. I have since discovered that if I remove ALL included js files, then the anchors work just fine. However, if I include even the jquery file, then they stop working. The search continues...
Upon serious amounts of testing, it turns out that Safari (6.0.4) is the cause of the problem.
Tested with different browsers, Safari is the only one that is having the problem with the anchors.
With Safari, there is some form of conflict between javascript and the anchors, though it is out of my control. I have updated all my scripts to the latest versions also.
Browsers tested, all the latest possible versions:
Safari (Windows)
Firefox (Windows)
Chrome (Windows)
IE 9
Firefox (OS X Latest)
Chrome (OS X Latest)
Safari (iOS)
Chrome (iOS)
Safari (OS X Latest)* The problem child
UPDATE (June 11):
I have just tested the same site with the new version of OS X and Safari in the public preview and it seems that they fix this issue with the next release. Hopefully, they don't break it again before then.
Running into the following problem specifically in Safari 5.1.2 when attempting to use the javascript fullscreen api.
By copy and pasting the following lines into your browser on a loaded page, you can see the effect.
This works in Chrome 15 and Safari 5.1.2:
javascript:document.querySelector('body').webkitRequestFullScreen();
This works in Chrome 15 but fails silently in Safari 5.1.2:
javascript:document.querySelector('body').webkitRequestFullScreen(Element.ALLOW_KEYBOARD_INPUT);
ALLOW_KEYBOARD_INPUT seems like it should work in Safari, according to documentation here: http://developer.apple.com/library/safari/#documentation/WebKit/Reference/ElementClassRef/Element/Element.html
Any ideas why this isn't working?
This is known Safari bug. It can be sniffed during full screen switching:
someElement.webkitRequestFullScreen(Element.ALLOW_KEYBOARD_INPUT);
if (!document.webkitCurrentFullScreenElement) {
// Element.ALLOW_KEYBOARD_INPUT does not work, document is not in full screen mode
}
Use this real time sniffing and thus your code will support future fixing bug in Safari.
someElement.webkitRequestFullScreen(Element.ALLOW_KEYBOARD_INPUT) works in chrome.
And someElement.webkitRequestFullScreen() works in safari 5.1.7
All test base on windows 7.
I just ran into the same issue, and this is most definitely a bug.
This may be a case of the Undetectables. Guess we're gonna have to use good ol' browser sniffing.
...(/Safari/.test(navigator.userAgent) ? undefined : Element.ALLOW_KEYBOARD_INPUT)
[edit] ...in which case keyboard input isn't possible. So I guess it's best to cut out fullscreen mode in Safari for the time being [/edit]
Keep in mind that the fullscreen API is in a very early stage at the moment, and should not be used in production
After reading another StackOverflow question, I started using this javascript "plugin" across my websites. However recently a client told me that it isn't working in IE9. I use Windows XP so I can't test IE9 but I'm 99% sure he's telling the truth. Any ideas?
The code you suggested (copyrighted by a porn site) tests MSIE 8 and higher and uses window.external.AddToFavoritesBar which was introduced in IE8.
I have now successfully tested your suggested code it on >>THIS PAGE<< in the following browsers - all on windows XP except IE9 which I tested on vanilla default win7 installation (IE9 only runs on Win7 or an upgraded Vista)
IE9 - bookmarks
IE8 - bookmarks
Safari5 - shows ctrl-d
Chrome10 - shows ctrl-d
Fx4 - bookmarks in sidebar
Opera v11 - bookmarks
Mozilla 1.7 - does not show the link.
So the answer to your question is: The code you want to use should work and does work in a standard installation of windows 7 with IE9 default install.
For the readers of this question, here is something much simpler which will work on all browsers (except, for some weird reason, Chrome), simply do this:
Page bookmark (Please right-click to bookmark): <a title="Title of the bookmark (for Opera)"
href="http://fullyQualifiedUrlToYourSite.com/page.html">Title of the bookmark</a>
or if you insist:
Page bookmark (Please right-click to bookmark):
<a title="Title of the bookmark (for Opera)"
href="http://fullyQualifiedUrlToYourSite.com/page.html"
oncontextmenu="if (navigator.userAgent.indexOf('Chrome')!=-1)
alert('Click ctrl-d to bookmark, as you already know as a Chrome-using techie')"
>Title of the bookmark</a>
Im using jCrop http://deepliquid.com/content/Jcrop.html and there is a weird problem
it wont work while im in ie8
if I was on ie8 and select document mode ei7 from developers tools it works fine
what can I do ?
Are you using the latest version? Seems there is an IE8 fix:
http://deepliquid.com/blog/archives/142
Edit: Strangeness ahoy! It only works after i turn on compat. mode, then turn it off o_O. My IE8 window was open from an earlier test and I didn't notice.
can you test with the latest and greatest version on github? It has major MSIE updates. I am currently working on a blog post announcing this release.
The issue is dealt with here, which is a bit of a hack to hide the radio button