I have this fiddle,
but can't make ti work in safari. In every other browser it works without flaws. I have read that safari supports data URI, so , I am missing something? Or is a bug?
I am using a simple
<img src="...">
Often, data in this manner cannot have line breaks, and it appears that your fiddle has them. I would recommend trying this without any line breaks, white-space, etc. I'm not sure why that would differ in Safari, but who knows.
Related
I was all excited over Polymer and starting developing a web app. I soon found out that Firefox fails loading the site correctly, see this SO post for details:
Polymer: Layout screwed up in Firefox, fine in Chrome
Then, I downloaded the latest version of Chrome on an iPhone 4 (iOS7) and the same thing for iPhone 6 (iOS8) and tried the website. I see the same errors as I see on Firefix (please see the link above).
In other words - going to my Polymer based website using Chrome for iOS fails just as bad as Firefox fails.
So, I'd just like to confirm that this is the case: Polymer does not work on iOS (no support in Safari, no support in Chrome for iOS). Correct?
As I also noted in my other SO question linked above, I was expecting it to work in all browser due to "polyfill", but that doesnt seem to help.
Am I missing something? =)
Note: Using Chrome for Android works fine, no errors there.
As I mentioned in the other thread, it's impossible to polyfill CSS scoping. Chrome on iOS is not actually Chrome, it's built using the iOS WebView (an old one at that), meaning there's no native Shadow DOM and no CSS scoping. The Shadow DOM polyfill does properly wrap DOM API methods like querySelector and getElementById, so you do get limited encapsulation, in that respect. But for CSS, the only thing the polyfill can do is rename your selectors, so :host .blah gets renamed to x-foo .blah and appended to a style tag in the head. It means you need to still write defensive CSS (as you do today) and avoid very loose selectors because they will be applied.
I experienced something very weird today and maybe it might help you.
My firefox was rendering as if polyfills didn't existed.So i went back to false on about:config dom.webcomponents.enabled and it came back to life.
Why? no clue.It worked, so, if you have dom.webcomponents.enabled true on firefox about:config might as well give it a try. IMHO looks like a polyfill bug on capable (yet buggy and poorly supported) web components browsers. worth a try.
I need to point one page to another and then scroll to a particular section. In Chrome and Firefox, using an URL like www.example.com#section1 does the trick. (#section1 can be an anchor or an element's id).
However, in Safari, the hash disappears when I click the link.
Why is this happening? Is it possible to do it on Safari? If not, how can I get around this problem?
When using hyperlinks that point to inside sections on other pages you must remember to add a slash (/) before the hashtag for cross browser compatibility.
Eg: www.example.com/#item-1
doing www.example.com#item-1 isn't accepted by all browsers (apparently by Chrome and Firefox it is)
Case: I have parameters after '#' like url#myParam=123, when I changed params like
url#myParam=789 Safari sometimes loaded previous page based on myParam=123,
although in Address bar it showed myParam=789
Solution : Use url?#myParam=123, then Safari will everytime load new page.
Using '?' before '#' solved my problem.
I had a related problem with Safari (on iPhone/iOS) seemingly stripping off the hash/fragment when doing a:
var newHash = ...;
window.location.replace("#" + newHash);
The actually problem was a javascript error that only appeared on Safari. Since I could not easily assess a javascript console for the iPhone, I chose to download an old version of Window's Safari (related post, download).
Then, I could replicate the problem from the iPhone on my Window's desktop using the old version of Safari. At that point, I found a javascript tag had a missing ']'. This was a legitimate bug, but it was somehow ignored by Chrome, Firefox, and IE.
The window.location.replace() was not even being called, because the code was breaking out on the javascript error. So the problem wasn't that Safari was stripping the hashtag, even though it appeared that way from multi-browser testing.
I just experienced an issue like this. I was using a URL re-write in the asp.net web.config. With Safari, the hash and everything after was removed. After trying some of the things mentioned above I was still having problems. The issue for me was that this was all happening under HTTPS. Once I specified the full URL in the redirect and included the https:// scheme the redirect worked correctly and preserved the hash. Note this wasn't an issue with Chrome or Firefox.
For me it was the exact same issue like mrbinky3000 has stated above: The server mod-rewrite was killing the hash in safari.
The solution was to use a full absolute link like:
http://www.example.com/path/#item-1
I just spend the last few hours debugging a huge problem, the problem being,
My external css style sheet were not loading when I used Firefox.
Using Firefoxes debugging tools I was able to conclude that the file was not been found, it had nothing to do with the MIME type or encoding as I checked.
I was using relative URL's to reference my style sheets to I decided to use absolute and it worked! after hours of nearly losing my mind.
However using absolute URL's on every page is just a pain and not practical if I am debugging on localhost all the time.
Could anyone tell me why I need to proved the absolute URL's? The CSS file is there and Firefox states the relative URL and when I go to it manually, it works, however Firefox will just not find it. Every other browser including Chrome and Safari Works with the relative URL's.
I could use php and define all these relative URL's and then reference these within my HTML making it easier to switch domains for debugging but still its a pain and I don't know why I have to do this.
My site here
Thanks in advance,
Jack.
Note : For testing reasons I am giving the link to my site which I am having problems with, nothing to do with advertising.
For your stylesheet problem: change the backslash to a forward slash in your <link> element.
<link rel="stylesheet" href="css/main.css">
There are a couple of images with a similar problem.
You have a number of other errors: <script> tags between <head> and <body>, and some loose </article> tags as well
If you're using Firefox, take a look at the page source and fix anything you see highlighted in red. Then try again.
We are having some annoying issues with BlackBerry phones. For some odd reason, our webpages aren't downloaded fully by some BB phones and I don't have clue what it could be.
If you have a BB, please try www.safarinow.com.
We are currently mainly experiencing this issue on the BB Curve 8520, but we don't have a lot of BB's around here to properly test. I have used the BB simulator for this BB and also for different models, but of course, on the simulators everything works fine. In order to browse the Internet on the BB simulator, it requires you to have the MDS service installed and I assume this works differently than the live server.
Something strange is that when you change the character encoding (BlackBerry browser menu -> Set encoding), it usually does load the full page...
Any clues? Please help :-)
Some articles I read
http://www.builtfromsource.com/2008/08/27/major-bug-with-blackberry-browser-and-multiple-cookies/
-> This doesn't seem to be the issue
http://www.blackberryforums.com.au/forums/general-bes-discussion/284-request-entity-too-large.html -> We are not getting an error, although page request size might be an issue
Maybe you should add an Encoding tag on your page's header.
Something like <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
This could be an issue specifically related to the browser rending engine. It's a long shot but make sure your HTML validates. The browser on certain Blackberries may be choking on improperly validated HTML.
Validate markup for your site: The W3C Markup Validation Service
The service found 41 errors and 9 warnings. It's worth eliminating as many errors as possible and re-testing.
Alison has some very good advice.
One other thing to look into is the amount of, and specifics of, javascript on the page. Before OS 6 and the Web Kit based browser, support for javascript on BlackBerry devices was intentionally limited.
It turns out that a lot of BlackBerries have Javascript turned off. And even if it's turned on, there is a checkbox for "Terminate slow running scripts" (something like that). We use jQuery Mobile, which is pretty heavy, so that was causing the issues. Ticking both checkboxes solved the issue.
I would be grateful for some pointers on how to troubleshoot this problem. Quick summary of the situation:
I have a large document (200K) divided into five main sections of inequal length, each of which corresponds to a jQuery UI tab.
The page works perfectly in Safari for Windows, Safari for Macintosh, Opera, Firefox, Chrome, and IE.
The page used to work on the iPad too but it no longer does, and it's the iPad that has changed, not the page.
On the iPad, the tab-content is now getting cut off. E.g. one of the pages is a glossary that runs from A-Z and the page cuts off at the letter -H-. It used to scroll all the way to -Z-. For some reason, iPad Safari is not giving each Tab the full amount of vertical space it needs for its content.
I've looked at the jQuery UI code for the show tabs and it appears to be changing CSS classes hide/show, but I'm no ninja javascript coder. How do I begin to figure out what's wrong on the iPad when my page works as expected on every other browser?
EDIT: The page seems to be working fine on the iPad2. It could be a caching issue and the page might stop working at some point even on the iPad2--I could only test at the Apple store. But I believe the markup and coding and jQuery ui are essentially OK, and it's a iPad Safari issue.
I can't trouble-shoot myself without the code, but the by far best way to trouble-shoot situations like this is to use a tool called Weinre. Obviously if one browser (the iPad's) is having trouble, you need to troubleshoot directly with it. That's difficult since the iPad doesn't have developer tools, but Weinre can actually give you (most of) that, over the network.
Follow the instructions here, but at the least you need to provide a ~/.weinre/server.properties that contains this:
boundHost: -all-
httpPort: 8081
reuseAddr: true
readTimeout: 1
deathTimeout: 5
That will tell weinre to listen on every IP on the port 8081. Start Weinre (via the OS X runner or with java -jar weinre.jar on the command line.
Then you add a special script tag in the main page:
<script src="http://YOUR_IP_NUMBER:8081/target/target-script-min.js"></script>
After this you start Safari or Chrome and go to http://localhost:8081/client/. If everything went as planned you will see the Weinre interface, which is a subset of the WebKit developer tools.
Now connect to your development machine with the iPad or simulator. If the script tag is correct Weinre makes a connection to the iPad and you have a fairly large subset of WebKit's developer tools at your disposal for trouble shooting. Good luck!
I'm sure this isn't the answer you're hoping for, but it sounds like a bug that should be reported to Apple.
You have a page that works perfectly on every other browser and I think its in Apple's best interest that it works on the iPad as well.
There might be other pages out there that used to work, but now don't, so I would consider this bug to be pretty high priority.