I have 5 users (3 locations) using the pages that have Tiny_MCE text areas.
I receive No Errors and it works Perfectly on the other 4 machines running IE7 This would indicate there is No JavaScript Errors.
One user only is seeing the raw html code and no buttons at all.
I suspect it must be some IE setting that is wrong.
It does not appear that Javascript is disabled, as other Javascript functions work on that same site on the same machine in IE.
This user is running XP Pro, and IE 7.
When I installed FireFox on his machine, the Tiny_MCE works perfectly. This would Also indicate there is No JavaScript Errors.
I'm at a loss to explain it.
Any Ideas would be appreciated.
Thanks
Once I ran into same issue and the fix was to remove a comma at the end of the script. So check whether the error pattern is present in your code.
For example, the following code contains a bug which will prevent it from running in IE7.
tinyMCE.init({
// General options
mode: "textareas",
theme: "advanced",
...
template_replace_values: {
username: "Some User",
staffid: "991234"
}, // <<< BUG - Additional comma here
});
If you can enable javascript debugging in IE7 then post the js error here.
Funny thing. The problem fixed itself with no human assistance. No Reboot, No Nothing. after being AFU for 2 weeks, it just started working again.
Got to Love Windows!
I've encountered this before and it has always been a caching issue. Use Ctrl-F5 in IE to force a full refresh of the page and all its files (*.css, *.js) in the browser and the browser cache. My guess is the IE 7 computer that was bad had a 14 day setting for checking if files were up to date.
Sometimes it's been worse - the web server (tomcat 5.5) would cache the file too and not notice the file was updated. Restarting the web server fixed that.
We are experiencing the same problem with our software last few months.
I found this forum topic on developer's website:
http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=66594
In short words, he is recommending to set strict_loading_mode to true when initializing tinymce. I've done that, and since that i had no problems.
Related
I have a strange issue regarding a Typo3-Installation (version 6.1). The frontend works fine, but the backend-login is blank (white screen). When I look into the source of the blank page, there is everything there, compared with a working 6.1-instance.
I know, a blank backend comes mostly from some PHP-Errors, but in this case I can't find any. The install-tool says, that everything is fine.
There are no javascript-errors in the blank login and I deleted the typo3-caches. I also tried with different browsers on different machines - still a blank page, but source is there.
Do you have any hints or ideas?
Updating to the latest version (6.2.17) solved that problem.
I am doing pentest for some company and about to use IE public exploit to take over a client. I need to run html including IE exploit , with an iFrame, but I can’t run the iFrame in windows 7 properly. the exploit dosen’t properly works, even it didn’t crash in windows 7 with iFrame. I dont know what’s the problem. for example in this code
"test.html" is IE public exploit(CVE-2014-1770) including javascript code & Heapspray.
the exploit link is: https://github.com/wchen-r7/metasploit-framework/commit/49551013cce106a4bd6a3477319e1d3466c615bb .
the exact code works without Iframe but when I load it from an iframe, it doesn’t work as it should in windows 7 & crashing in windows xp. I change this for windows 7 manually.
Curious if you had similar experience with IE exploits and iframe and any idea why this happen and how to fix the issue ?
I've created a fresh install of Moodle 2.5. I installed successfully, I thought. I have not customized the theme, so it can NOT be theme-based.
TinyMCE's file picker is not loading...whether trying to upload a file or creating/editing a course under the Course summary files section...all I get is the "Loader" star. I did some research and found no solutions that worked. Quite a few said "custom themes," but I have no custom themes yet. Now, in checking the console, I got this:
- Uncaught SyntaxError: Unexpected Identifier /lib/editor/tinymce/tinymce/3.5.8/tiny_mce.js:2
- Uncaught ReferenceError: tinymce is not defined module.js:1
- Uncaught ReferenceError: tinyMCE is not defined yui_combo.php?moodle/1374671241/editor_tinymce/collapse/collapse-min.js:1
Digging further, I found the error on tiny_mce.js with the "uncaught syntax error" is around this area (I beautified the JavaScript for better readability and it ended up on line 3344):
pi: function(h, i) {
if (i) {
c.push("")
} else {
c.push("")
}
if (a) {
c.push("\n")
}
}
I also have no clue why the page is not seeing TinyMCE as defined.
In my browsing of multiple sites, one person mentioned being able to open the file picker in Moodle 2.5 when logged in as a regular non-Moodle user. They, too, have no answer to the problem, but I tried that and the file picker did, indeed, open.
Update
I've found it's not quite just the file picker. This whole thing is tying in to TinyMCE not loading properly...with the editing toolbar capability (whether collapsed or not.) It acts as if it's a simple text editor.
I fought with it and ended up causing more problems than solutions, so I uninstalled everything, and started from scratch. I have no plugin add-ons, no fancy themes (it's the basic one it installs with), and no customization, and it's still buggy.
The console continues to say:
- Uncaught SyntaxError: Unexpected Identifier /lib/editor/tinymce/tinymce/3.5.8/tiny_mce.js:2
- Uncaught ReferenceError: tinymce is not defined module.js:1
- Uncaught ReferenceError: tinyMCE is not defined yui_combo.php?
And it pauses the debugger on practically every page with this. It's telling me that there's a problem with how TinyMCE is called in.
I've submitted a bug report, but haven't gotten the answer yet. What I'm hoping for is someone else to have had the same problem and come up with the solution, remembering there is no theme customization, no add-ons...so they can't be at fault.
As a matter of fact I also banged to this issue after upgrading to Moodle 2.5.1+, and after digging it for hours came up with a solution that made things work smooth again, I have disabled Cache JavaScript from:
Home / ► Site administration / ► Appearance / ► AJAX and Javascript
After saving the settings the file picker started working as normal. I am not sure how bad this will affect overall moodle performance and how bad it will increase the load on server and website loading overhead, but at the moment that was the only solution that I came up with.
Hope this will help...
version 2.5.1+
The FilePicker doesn't load when editing is turned on.
If you have this issue where the FilePicker hangs while loading, click on the following:
Administration | Course Administration | Turn editing off
Then refresh the page with the FilePicker that you need to use.
I'm putting this as an answer, because I received one, and I want everyone who ends up with a similar problem to know the way to solve it.
The problem was with the admin user profile settings. The Moodle team responded, and told me what to do.
It's as simple as:
Change the admin's user profile and set not to use html editor by default.
Purge all caches both in moodle and in your browser.
Make sure that in "Site administration ► Development ► Debugging" you have "debug messages = developers" and "display debug = yes"
Thanks!
I have applications which are displayed as tabs in Facebook pages which have been working fine. They suddenly started displaying this output in the tab:
/1336720089,176820405/
if (window.CavalryLogger) { CavalryLogger.start_js(["EgxV3"]); }
__d("UFIUpdate",
Any ideas what is going on???
Here is a link to one of them: http://www.facebook.com/TweakShoes/app_132692060112327
A temporary solution is to add https:// to facebook itself. This doesn't solve the problem, but it'll allow you to see your page on a per client basis.
The best fix in the longer term until facebook fixes this issue is to go to your account settings > Security > Enable secure browsing. This will enforce HTTPS wherever it can and should resolve the issue for a lot of pages you're trying to access.
Good Luck!
After encountering this issue yesterday, I tracked it down to an apparent conflict with the JS log wrapper included as part of HTML5 Boilerplate's script.js file. In particular, the "make it safe to use console.log always" snippet. After commenting it out, the FB lib error went away and my app displayed properly.
I didn't dig into what the conflict was, but here is the snippet. If you use something similar on your page, then it may be worth investigating.
/* make it safe to use console.log always */
(function(b){function c(){}for(var d="assert,count,debug,dir,dirxml,error,exception,group,groupCollapsed,groupEnd,info,log,timeStamp,profile,profileEnd,time,timeEnd,trace,warn".split(","),a;a=d.pop();){b[a]=b[a]||c}})((function(){try
{console.log();return window.console;}catch(err){return window.console={};}})());
It's probably not a coincidence that FB's own logger bugs out with this.
Facebook has opened a bug for this issue and recently triaged it to medium priority - no word on when it will be addressed.
First off, I apologize if it's considered poor etiquette to cross-post on stackexchange sites, but this seemed appropriate for both the webmasters site and here, as it's a common issue for webmaster, but may be able to be solved by coders. In any case, here goes...
OK, so this seems like a really simple problem, but I have yet to find a solution that accomplishes the following:
Opens the link in a new window
Tracks the event in GA when using the asynchronous code
Doesn't trigger pop-up blockers (uses target="_blank" instead of window.open)
Most of the code I've seen, including Google's, doesn't take into account the case of opening in a new window - they just use window location.href.
Even GAAddons (http://gaaddons.com/), which charges for commercial use, seems to not manage opening in new windows properly.
Perhaps, I'm missing something simple - I'd be relieved if so and would thank profusely whoever points it out to me!
If no one is able to provide an example, I'll post some of the test cases I've created to illustrate the problem.
Thanks.
[EDIT] I've since tested the GAAddons code more throughly and have found it to work. I'm guessing the problem that was being reported earlier by a client using Chrome 7 on Windows was more likely a configuration issue than something related to the GAAddons library itself.
You put it in the link's onclick attribute:
some link
The method I've found to satisfy all the requirements I've mentioned is the one found here:
http://cutfromthenorth.com/add-external-link-tracking-with-jquery-and-google-analytics/
It's actually quite simple, leading me to think that there was some other reason why other code wasn't working in earlier tests.
However, I can confirm that the method that's mentioned in the comments on this Google page - http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55527 - does not meet the above requirements (new windows trigger popup warning on Chrome and IE).
The Google code does work for tracking external links not opened in a new window.
here's the snippet:
$('a[target=_blank]').click(function(){
try{
_gaq.push(['_trackEvent', 'External Links', 'Click', $(this).attr('href')]);
} catch(err) {}
return true;
});
I've tested on the following browsers:
PC:
IE 6 - 9
Firefox 3.6, 4.0
Chrome 9, 10
Safari 5
Opera 11
Mac:
Safari 5
Chrome 10
Firefox 3.6, 4.0
Also tested on iPhone 4 and the native Android browser on Gingerbread