This is weird. I say weird because on IE 8 and above (as well as FF) my urls generated by Html.ActionLink() creates an url in the correct form -> http://mydomain.com/myapp/mycontroller/myaction but on IE 7 and IE8 running in compatibility mode the urls are generated as -> http:///myapp/mycontroller/myaction . This is also affecting anything that uses Url.Content().
This is a concern because I have users still holding on to IE 7 for dear life (I don't get it either). Plus our Active Directory policy has things set for some (not all) users so that IE 8 is forced into compatibility mode and cannot be turned off. It also overrides the compatibility meta tag.
What should I check for here within MVC? Is there a web.config setting I need to look at?
Code:
Action links:
#Html.ActionLink("My Text", "Action", "Controller", new { Param1 = Model.Param1 }, new { #class = "linkButton" })
Url.Content:
Url.Content("~/Content/openHS.png")
Update:
I found a similar item dealing with this issue in PHP: Why can't I use relative URLs with IE7?
A couple of other articles around the web mentioned using the <base> header tag.. trying this now. used the search "relative urls" "Internet explorer 7"
This works. I tested in WinXP mode with IE 8 in compatibility mode as well as in Internet Explorer 8 IE 7 mode, IE 9, IE9 Compat, FF 11. No harm to my existing JavaScript
For Razor:
#{
string baseHref;
if(this.Request.Browser.Type == "IE7" && !this.Request.UserAgent.Contains("Trident/5.0"))
{
baseHref = this.Request.Url.Scheme + "://" + this.Request.Url.Authority + Url.Content("~");
}
else
{
baseHref = Url.Content("~");
}
}
Then in the top of the <head>:
<meta http-equiv="X-UA-Compatible" content="IE=9;IE=8;" />
<meta charset="utf-8" />
<base href="#(baseHref)"/>
One explanation on the above: Trident/5.0 is IE 9's compatibility engine and seems to allow IE9 to interpret relative links according to the page domain instead of base. I'm sure you can remove the Razor code if you so choose. This was a compatibility patch for me.
Related
I am trying to make a playground like plunker. I just noticed a very odd behavior on production (with active mode in Cloudflare), whereas it works well in localhost.
By iframe, the playground previews index_internal.html which may contain links to other files (eg, .html, .js, .css). iframe is able to interpret external links such as <script src="script.js"></script>.
So each time a user modifies their file (eg, script.js) on the editor, my program saves the new file into a temporary folder on the server, then refresh the iframe by iframe.src = iframe.src, it works well on localhost.
However, I realized that, in production, the browser always keeps loading the initial script.js, even though users modify it in the editor and a new version is written in the folder in the server. For example, what I see in Dev Tools ==> Network is always the initial version of script.js, whereas I can check the new version of script.js saved in the server by less on the left hand.
Does anyone know why it is like this? And how to fix it?
Edit 1:
I tried the following, which did not work with script.js:
var iframe = document.getElementById('myiframe');
iframe.contentWindow.location.reload(true);
iframe.contentDocument.location.reload(true);
iframe.contentWindow.location.href = iframe.contentWindow.location.href
iframe.contentWindow.src = iframe.contentWindow.src
iframe.contentWindow.location.replace(iframe.contentWindow.location.href)
I tried to add a version, it worked with index_internal.html, but did not reload script.js:
var newSrc = iframe.src.split('?')[0]
iframe.src = newSrc + "?uid=" + Math.floor((Math.random() * 100000) + 1);
If I turn Cloudflare to development mode, script.js is reloaded, but I do want to keep Cloudflare in active mode.
I found it.
We can create a custom rule for caching in CloudFlare:
https://support.cloudflare.com/hc/en-us/articles/200168306-Is-there-a-tutorial-for-Page-Rules-#cache
For example, I could set Bypass as Cache Level for the folder www.mysite.com/tmp/*.
I want to show a warning on a particular page I have if and only if the user is using IE 7.
I am currently seeing an issue where if the user is using IE 8 in compatibility mode they are seeing this warning message, the logic is as follows:
Please note: Some customers using Internet Explorer 7 web browser may not be able to use parts of this site. You may wish to upgrade.
How can I fix the page so that the customer is only shown this warning if they are really using IE7?
The specifics depends on the web framework in use (asp.net etc), but you can check the browser version by checking the user agent submitted by the browser. Each browser will have a unique user agent that includes the version number as well. The user agent will be in the http request.
Here's a link with a few options if you're using asp.net
http://msdn.microsoft.com/en-us/library/ms537509(v=vs.85).aspx
<script type="text/javascript">
var $buoop = {vs:{i:7,f:5,o:12,s:5,n:9}};
$buoop.ol = window.onload;
window.onload=function(){
try {if ($buoop.ol) $buoop.ol();}catch (e) {}
var e = document.createElement("script");
e.setAttribute("type", "text/javascript");
e.setAttribute("src", "//browser-update.org/update.js");
document.body.appendChild(e);
}
</script>
I would like to write a Qt application which uses Webkit as its gui to get data from a server and display it. I got it working unter Linux and OS X without problems but under windows the XMLHttpRequest always returns status 0 and I don't know why. Here is the pyqt code I use:
import sys, os
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *
app = QApplication(sys.argv)
web = QWebView()
web.page().settings().setAttribute(QWebSettings.LocalContentCanAccessRemoteUrls, True)
path = os.path.abspath(os.path.join(os.path.dirname(__file__), 'index.html'))
url = "file://localhost/" + path
web.load(QUrl(url))
web.show()
sys.exit(app.exec_())
and here is html HTML/JS I use to test it:
<!DOCTYPE html>
<title>TEST</title>
<h1>TEST</h1>
<div id="test"></div>
<script type="text/javascript">
function t(text) { document.getElementById("test").innerHTML = text }
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(this.status != 0)
t(this.responseText)
else
t("Status is 0")
}
xhr.open("GET", "https://jeena.net/")
xhr.send()
</script>
On Linux it opens a new Window with a WebKit view in it, loads html local index.html file into it and renders it which shows the TEST headline. After that it runs the XMLHttpRequest code to get a websites content and set it with innerHTML into the prepared div.
On windows it loads and shows the title but then when it runs the xhr code the status is always just 0 and it never changes, no matter what I do.
As far as I understand LocalContentCanAccessRemoteUrls should make it possible for the xhr to get that content from the remote website even on windows, any idea why this is not working? I am using Qt version 4.9.6 on my windows machine and python v2.7.
I think there are two simple attempts to solve this problem.
My first thinking is that it can be due to cross domain request.
Seems that there is no easy way to disable cross domain protection in QWebkit.
I got the information from this stackoverflow question:
QtWebkit Same-Origin-policy
As stated in the accepted answer:
"By default, Qt doesn't expose method to disable / whitelist the same origin policy. Extended the same (qwebsecurityorigin.cpp) and able to get it working."
But since you've got everything working on linux and mac, the above may not be the cause.
Another possibility is you don't have openssl enabled with your Qt on windows. Since I noticed you have requested to a https page, which should require openssl. You can change the page to a http one to quick test this possibility.
I have a phonegap app that uses jqm that works fine in android and ios.
Porting to WP7 i have an issue with the history, specifically history.back() (but also .go(-1) etc). This refers to going back in history where the previous 'page' was in the same physical html file, just a different data-role=page div.
using a jwm site in a regular browser is fine (with separate 'pages' in the same html file). Also, using history.back() when we go from one html file to another in the app is fine. It's the specific combination of WP7.5, jqm and PG.
Has anyone come across a solution for this? it's driving me crazy, and has been as issue since PG 1.4.1 and jwm 1.0.
EDIT 1: It's possible that the phonegap process of initialising the webview on WP7.5 somehow overrides the jqm history overrides, after they've loaded.
EDIT 2: definitely something to do with jqm not being able to modify the history. each time there is a 'page' change, history.length is still 0.
EDIT 3: When i inspect the 'history' object, i found there is no function for replaceState or pushState - i know jqm uses this for history nav, maybe that's the problem.
ok - this isn't perfect, but here's a solution (read: hack) that works for me. It only works for page hash changes, not actual url changes (but you could add a regex check for that). Put this somewhere in the code that runs on ondeviceready:
if (device.platform == 'WinCE') {
window.history.back = function () {
var p = $.mobile.urlHistory.getPrev();
if (p) {
$.mobile.changePage("#" + p.pageUrl, { reverse: true });
$.mobile.urlHistory.stack.splice(-2, 2);
$.mobile.urlHistory.activeIndex -= 2;
}
}
}
I have the Drupal Quicktabs module installed at:
http://ar.sacherokeedev.com/auction-directory
I've also installed the wibiya toolbar, http://www.wibiya.com.
Everything works fine in Firefox and Chrome, but in IE7, with the toolbar enabled, it breaks the ajax tab loading. With the toolbar disabled, IE7 works fine. Wibya has a "Javascript Conflict" mode, and I've tried that as well as changing my DocType, as they suggest.
I've narrowed it down to a couple of things. First, quicktabs behavior is based on the "type" of the tab:
if (tab.tabObj.type != 'view') {
// construct the ajax path to retrieve the content, depending on type
var qtAjaxPath = Drupal.settings.basePath + 'quicktabs/ajax/' + tab.tabObj.type + '/';
switch (tab.tabObj.type) {
case 'node':
qtAjaxPath += tab.tabObj.nid + '/' + tab.tabObj.teaser + '/' + tab.tabObj.hide_title;
break;
case 'block':
qtAjaxPath += tab.qtid + '/' + tab.tabObj.bid + '/' + tab.tabObj.hide_title;
break;
case 'qtabs':
qtAjaxPath += tab.tabObj.qtid;
break;
}
In my case, when using the toolbar in IE, tab.tabObj.type is "undefined". So, I'm thinking that wibiya is hijacking my objects or something.
I also get a runtime error, "Object does not support this property or method" in the following block:
if (!Drupal.quicktabs.scripts[files[i]] && !files[i].match(/^\/misc\/jquery\.js.*$/)) {
Drupal.quicktabs.scripts[files[i]] = files[i];
html += '<script type="text/javascript" src="' + files[i] + '"></script>';
}
Has anyone seen this before, or have any suggestions?
Update: I did console.log(tab.tabObj) and in Firefox and Chrome, I get something that makes sense, an Object with a block id, a type, etc... But in i.e. I get this:
function(fn,thisObj){var scope=thisObj|window;for(vari=0,len=this.length;i<len;++i){fn.call(scope,this[i],i,this);}}
Anyone have any ideas?
UPDATE: I am currently using the Drupal specific wibya module, and the toolbar itself works fine on my site whether one is using IE, Firefox or Chrome. The issue is that the ajax tabs on that page are prevented from functioning by the wibiya toolbar. I'm inclined to agree with #clive that it's a jQuery/javascript conflict, but I'm not sure what I can do about it.
As for running Drupal 6, I inherited the system, and as of now, can't upgrade.
UPDATE: I just tried loading jQuery 1.4 using the instructions at http://drupal.org/node/1058168. That caused IE to work properly, but now Chrome and Firefox don't like it.
UPDATE: This is a conflict between jQuery 1.3 which runs on Drupal 6 and the Wibiya toolbar which uses at least 1.4. I'm accepting #clive's answer, mainly because he's right about the fact that this is just something that I'm going to have to live with if I have to keep using Drupal 6.
My best guess would be that you're using Drupal 6 which ships with jQuery 1.2.6 (or 1.3.2 with the jQuery update module. The Wibiya baar conversely uses jQuery 1.4.2 upwards.
According to a page on the Wibiya support forums (which I'm sure you've already seen):
if page loads another version of jQuery like 1.2.6 or 1.3.2 previously, Wibiya bar's loading of its own jQ 1.4.2 does not work. No bars, nothing.
But if you load your own jQ 1.4.2 in the first place, then your bar works, despite all other Drupal functions suck like polls, votes, hierarchical select tags, nice menus, some collapsibles, etc.
There a lots of these types of problems with Drupal which is why the community comes up with workarounds and solutions: The Drupal specific Wibiya module will probably save you a lot of headaches.
UPDATE
There's a JS error on your site:
Unsafe JavaScript attempt to access frame with URL http://ar.sacherokeedev.com/auction-directory from frame with URL http://ad.doubleclick.net/adi/N1727.autoremarketing.com/B5111890.6;sz=728x90;click=http://adclick.g.doubleclick.net/aclk?sa=L&ai=B6dLCjz5qTqvUGIfN0AXN67WqBa-C-usBAAAAEAEg7ZqAFjgAWK_Q_80gYLu2moPQCrIBFGFyLnNhY2hlcm9rZWVkZXYuY29tugEJZ2ZwX2ltYWdlyAEJ2gEtaHR0cDovL2FyLnNhY2hlcm9rZWVkZXYuY29tL2F1Y3Rpb24tZGlyZWN0b3J5mAKgjQbAAgLgAgDqAhNBUl9Ib21lX0xlYWRlcmJvYXJk-ALw0R6QA4wGmAPgA6gDAeAEAaAGFg&num=0&sig=AOD64_1Xi82LSwUc1kKF0RL_orTztOMfxg&client=ca-pub-2649455708539916&adurl=;ord=1670303729?. Domains, protocols and ports must match.
Is it possible that unsafe frame attempt is stopping IE7 from processing the rest of the JS, thereby making your tabs not work?