In Safari 5.1.2 on OSX
Tech.li is completely broken.
Some people mentioned an extra div tag being the cause, but that still didn't fix the issue.
Any help would be greatly appreciated!
Pretty basic: fix your xhtml errors [Invalid] Markup Validation of tech.li - W3C Markup Validator (scroll down in the validation report to see line numbers and source code). And use Firebug with Firefox, or in Chrome or Safari or IE8, use the developer tools to find and fix the javascript errors.
Related
I'm getting a TypeError: elem.dispatchEvent is not a function using select2 in jquery using the wrapbootsrap pixel-admin theme.
It can be reproduced in firebug on the demo site via http://radiant-ocean-4606.herokuapp.com/forms-advanced.html
Firefox Version: 29.0.1
Firebug Version: 1.12.8
It's a similar error message to this question:
"element.dispatchEvent is not a function" js error caught in firebug of FF3.0
But the answer there doesn't help me as my site is all jquery (well as far as I know - I did somewhat accept the theme bundle as it came for the time being until I have time to really rip it apart and modify it in detail).
This was caused by changes to the browser, the solution was to stop using firebug. The features firebug offered are ubiquitous now!
Using Selenium, with an earlier combo of the webdriver (2.28.0) and Firefox (pre-19), the following code worked.
driver.get("http://www.haemonetics.com/en");
driver.findElement(By.linkText("LOGIN")).click();
driver.findElement(By.linkText("Haemonetics")).click();
With webdriver 2.31.0 and Firefox 19.0.2 the code does not work and I receive a NoSuchElementException for the second findElement.
I tried using xpath which doesn't work for Firefox but does work for Chrome and IE, which are part of the same test suite.
Any thoughts or another way to accomplish the same thing? I would prefer to use the same code for the mentioned browsers.
Not sure if it was a typo on your part, but it should be "find_element" instead of "findelement", at least it's so in 2.31 to my knowledge.
Try
driver.find_element_by_link_text("LOGIN")
if that doesn't work, post your HTML code so we can possibly construct a working Xpath.
So I'm going to start using data-uri's and mhtml to embed images in my stylesheets and i'm thinking of using Jammit to help me out there because it claims that it can generate data-uri and mhtml code for you
I know about the IE7 Vista||Win7 bug and that the fix is to close off the buondaries with a two dashes
If you look at the example mhtml file provided in the jammit docs you might notice that they do not use the fix detailed above for the IE7 bug.
Does Jammit handle the IE7 bug for you? I have no way of testing IE7 so I'd just like to be sure of this before I got off and spend hours trying to get it to work
I don't think it's an IE7 bug. the Multipart MIME RFC (1341 and its successors) clearly calls for the extra "--" at the end of the last boundary. I would consider it a Jammit bug.
Update: I checked the source, and it looks like they've fixed that bug. The example was generated before the fix.
Here's my JS insert:
<script type="text/javascript" src="include/profile.js"></script>
In IE8 with "Compatibility View," the file never loads. The first line in the file is a simple alert() call, so that I know it loaded. Change the browser to Standards View, and it loads fine.
Also, if I add:
<meta http-equiv="X-UA-Compatible" content="IE=100" >
It forces to Standards View and it loads fine.
Any idea why this would be the case? I've not been able to test against IE7, but I know the JS file also does not load in IE6.
Right now the tag is in the section of the file.
It would seem that IE8, Safari, Firefox, et al will tolerate certain JavaScript syntax errors. IE7 and IE6 (and IE8 in 'compatibility view') will not, and they will also not throw a parse error or any other kind of clue.
Pasting my code into http://www.jslint.com/ revealed a couple of syntax errors that weren't affecting the code's operation in other browsers. So boo on me.
Okay. Had the same problem on IE8 and safari 5 on windows and finally got this working. This one is really beauty...
I had a function with a parameter named 'class' which was causing the issue. Renaming to clsname fixed the problem. Apparently FF and chrome were lenient about this.
Turn on script debugging and see if you are getting a javascript error in compatibility mode. The presence of an error would keep the javascript from executing even if it is loaded. You might also want to use the developer tools in IE8 to debug the javascript and/or verify if the file is loaded or not.
just spent couple of hours on this - IE7 & 8 suffers from "return" identificator
I had:
m["return"] = 123;
var x = m.return; // SILENT ERROR!
Obviously, renamaing identificator solves this
I have a problem concerning dojox.charting, after updating to the new version of dojo IE 8 doesn't show the labels of my charts anymore. Seems to be a dojox.gfx text problem.
See with IE8:
http://download.dojotoolkit.org/release-1.4.0/dojo-release-1.4.0/dojox/gfx/tests/test_text.html
Any idea how to fix that?
Cheers
-jstr
It looks like some IE8 fix pushed by MS broke it because we didn't modify this code for a long time.
In any case there is a ticket for this problem (reported as a charting ticket): http://bugs.dojotoolkit.org/ticket/10491
One simple fix for now is to force IE7 mode:
<meta http-equiv=“X-UA-Compatible” content=“IE=7” />
More info can be found in Understanding Compatibility Modes in Internet Explorer 8.