I've just realized that tinyMCE is not working when you use firefox 5.0
First I thought that's my fault with some script , but then I went straight to TinyMCE demo page http://www.tinymce.com/tryit/full.php and there was the same result.
In normal way you open page, see editor, see text inside editor.
With firefox you see editor, but nothing is inside textarea. It is empy, blank. And what's more strange there is no mouse cursor inside of it. You cannot set it there, thus you cannot write there.
Later on I made one notice.
I've started to refresh the page fast, many times so the browser cannot work fast.
And I saw that it writes textarea, then converts it into tinyMCE editor with all text inside of textarera, and then on the final step it hides or removes all the data from textarea, leaving empty editor with all buttons visible.
Any idea what's going on?
Of course I've posted this on TinyMCE forum, and bugreported it also, but things there run very slow, and on StackOverflow I've got used to fast answers :)
So if anyone has any idea about how can I fix it please tell me.
UPDATE
I think something is wrong with my computer.
I've just tested cuteEditors demo and it acts the same way
http://cutesoft.net/example/general.aspx
So I think problem is inside my computer.
Is it Firefox or what?
SOLVED
Plugins were the problem. I disabled all the plugins and everything works fine!
SOLVED Plugins were the problem. I disabled all the plugins and everything works fine!
Related
Every other snippet is working, but !+tab is not.
! snippet is not working
other snippet is working
I am using Visual Studio Code. I'm using 1.69.0. It was working before, but I wanted to add net html file, named that new.html, because I had index.html already. After that this script stopped working on every html file, but other scripts like "a", "div" etc. is working.
The v1.69.2 recovery release is out now. Emmet in html is working as it should for me now.
Looks like it will be in the Recovery Release, see https://github.com/issues?q=is%3Aissue+label%3Acandidate+repo%3Amicrosoft%2Fvscode+repo%3Amicrosoft%2Fvscode-internalbacklog+repo%3Amicrosoft%2Fvscode-remote-release+milestone%3A%22June+2022+Recovery+2%22+.
Don't know when the recovery release to Stable - presumably v1.69.2 - will be released. The .1 release is out and the fix is not in it.
It has been fixed though, see https://github.com/microsoft/vscode/issues/154375, and should be in the Insiders Build tomorrow (07/13/2022).
Testing the latest Insiders: ! is working. As is ul>li*3 type expansions (although that never stopped working for me - but it has been reported elsewhere). Should be in the v1.69.2 release out soon.
It is a known issue with the v1.69 release, see html emmet suggestion not automatically display or https://github.com/microsoft/vscode/issues/154517 for example. Lots of issues on github on ! and * not working.
So the emmet snippet will not appear automatically when you type !, but you can press Ctrl/Cmd+Space (which is the command Trigger Suggest) to make it appear and select normally.
Try Ctrl/Cmd+Space for anything emmet-related nnnnnot working in vscode v1.69.
You could also go back to v1.68 to solve the issue.
Try to write "doc" instead of "!". "doc" works for me.
On Windows 10, this worked for me:
Go to "Settings" and type "emmet.trigger" in the search
A checkbox for "Emmet: Trigger Expansion On Tab" will appear
Check the checkbox for allowing Emmet to trigger expansion on tab
After I did that, it worked just fine for !+TAB and any type of mulitpliers (i.e. li*4+TAB).
You need to check this option or put "emmet.triggerExpansionOnTab": true in settings.json to use the emmet abbreviation pressing TAB. I realized this ones what is not working:
!, lorem, >, and .
Examples of use: ul>li, li3, ul>li*3
None of them shows the preview of the emmet, and you can't use them pressing TAB without enabling the option that I sayed above, and even checking the option you won't be able to see the previews, you'll need to know them by yourself and press the TAB even though nothing showing that it's a emmet abbreviation.
You can use CTRL + SPACE too.
Edition Windows 11 Pro
Version 21H2
VSCODE Version 1.69.0
I had the same issue with the ! not working. I found another shortcut that does the same thing: type html:5, and press enter.
Looks like a bug, I have the same problem with 1.69.1, the VSC team is aware and fixing it. Should be fixed with the next release soon.
Meanwhile, you can use either HTML:5 or doc
meanwhile use "HTML:5"
enter image description here
or use "doc"
enter image description here
While #Mark's answer works, another work around would be to use the html:5 snippet which still works as expected in v1.69
Yes, I am facing this issue too since the latest update.
Somehow the solution I have got is :
You can check the box “Emmet: Use Inline Completions”
In settings by typing “emmet” in the setting’s search.
You can see the suggestion now and choose it by pressing the tab.
This is the solution I have got till now but hoping that we could have the previous version back.
Here in the image you see the code is greyed out. Before I put in the <script> tag everything was not greyed out. Once I put in the tag is greys out the rest of the code. I might be missing a file needed to run the script tags?
I have been working with code for a while, but I am still a little stuck on how to get the code set up. I am wanting to use html/css and JavaScript to make a couple websites. I am not sure how to set everything up to make it work. I also am using github, and trying to figure out how to use github-pages.
A simple solution that works:
Just close the file being edited
Click "File->Reopen Last Item" to re-open it
This is an issue with Atom, it does not detect the tag when it auto completes, it works fine in VSCode, so it's not really a problem with your code, it's the IDE
enter image description here
As i recognize, the Atom text editor makes this error.
The best solution i tried:
IN ATOM TEXT EDITOR
Windows:
Ctrl + ,
MAC:
Cmd + ,
In settings:
1. Scroll to the bottom,
2. Uncheck "Use Tree Sitter Parsers",
3. Restart Atom IDE.
That works fine for me!
This is a known bug, but it seems no fix have been done yet, you can report your case here, I guess: HTML Syntax Colour Bug
But you may have solution in that StackOverflow subject, if so, it would be a duplicate: Atom Code Editor. Why is my code not in color?
I just introduced tinyMCE into my rails 4.2.8 site to let manage formatted text in articles. Everything works fine actually but now and then a warning message produced by tinyMCE comes up such as "failed to load content css: http://myurl/assets/tinymce/skins/lightgray/content.min.css" but if a look at the debug console in firefox I see that url has perfectly found and loaded content.min.css.
When the warning message is there I can't enter anything in the textarea but the situation is fixed by reloading the page, then the rich text can be nicely entered and the relevant data is loaded correctly into the backend DB via relevant input form.
I don't understand the reason why tinyMCE is signalling such a warning despite the fact that the css file was actually found.
Any idea? Thanks and kind regards
Vincenzo
**** update on June 8th 2017 ****
Now I can better explain what's actually going on.
1) the problem shows up in Firefox v.53, if I use Chrome everything works fine
2) I am using tinyMCE in three distinct forms: one for new articles, one for editing, one for comments.
3) If I insert a few new articles no problem appears, the problem shows up just chenging the form in use: i.e. after insertion an article I try editing it or another one or else I try to insert a comment after havine inserted a new article. After the error message has shown I can always recover by reloading the page and no error appears eventually.
I guess there is some caching problem specifically in Firefox since all works fine in Chrome. I will try Windows Edge too..
2017/06/10
Tried Windows Edge on Win10: it works fine too.
2017/06/14
In the meantime I opened bug 1371910 at https://bugzilla.mozilla.org/show_bug.cgi?id=1371910#c5 a few days ago and the result was:
QUOTE
Hi Vincenzo,
Thanks for sending us the link. Unfortunately this seems to be a problem with tinyMCE rather than Firefox.
The initial load of content.min.css works correctly, and no other attempts to reload it seem to be made.
If it works in other browsers it is probably due to the developers doing things differently.
If you still think this is a bug in Firefox, please reopen this bug, and send us a smaller test case.
PS. Others seem to be having the same problem as you: https://community.tinymce.com/communityQuestion?id=90661000000Qct9AAC
I hope you find a way to fix it.
UNQUOTE
What the Firefox support says makes sense since I too whatched the content.min.css file was actually loaded by the browser so in must be tinyMCE to misinterpret something. Anyway I am still in the soup...
Whoever might have some interest at this issue please hava a look at:
http://vinloren-learn-rails.herokuapp.com/articles accessing this endpoint with Firefox v52..v54 the click show any article then going back via the 'back' link at the end of the article's content.
I"m wondering if anyone can give me some insight into a really strange IE9 issue I've been struggling with.
I'm finishing up production of a site for work - it works well in ff/chrome/ie7/ie8 with no script errors.
On IE9 the last step of the application causes the entire tab to whitescreen with no script errors or warnings. (changing the document mode to ie8 will fix the problem but is obviously unsuitable for production)
Unfortunately the site pretty complex with a ton of ajax, and in-page scripts so I can't really post the relevant code easily. I'm more trying to figure out how to diagnose this.
I've checked the IE error logs and they are empty. Web developer tools tells me nothing. The site is not using any plugins (Flash/Silverlight, Ect. ) just javascript w/jQuery.
There is a PDF being displayed in an iframe around the step where it fails - but a nearly identical pdf is displayed in the previous step (using the same method) without problem. The code fails around a call to the jquery UI window but I can't seem to get the exact line.
If anyone has a clue how to try to diagnose this further I'd really appreciate it. I can keep hunting for the bug but I've never seen this kind of behavior before and just am not sure what I am looking for.
Thanks for all the input on this. Sorry I got completely overwhelmed by a few projects at once so I wasn't able to post updates on the debugging steps.
It took forever but I finally realized that everything was crashing when I closed the dialog containing the first PDF.
One of my helper functions was opening the dialog and automatically destroying the contents on close. Normally this works fine as I'm either removing a div containing the page fragment, or the iframe.
In this situation I had a page fragment loaded into the dialog which contained some buttons and the pdf iframe. I called the .remove() method on the parent element containing the iframe rather than the iframe itself. For some reason this seems to work fine in every other browser - but in IE9 it pretty much kills the page rendering without any warning or message.
I strongly suspect that the culprit is the adobe plugin but I'm not entirely sure.
Here is the fix-
Html:
<div id="container">
<iframe src="loremipsum.pdf"></iframe>
</div>
Javascript:
//Ruins my entire week
$("#container").remove();
//Works as the pdf is removed directly
$("#container").find("iframe").remove().end().remove();
I ran into the same issue on IE11 while trying to remove an iframe in a div with AngularJS. Removing the iframe first would just cause the same issue, so I navigated the iframe src to a new page (about:blank) first, then removed the div which worked. Hopefully this helps someone with a similar problem.
Pseudo-code below:
$ctrl.iframeUrl = 'about:blank'; // change the iframe url here
$timeout(function(){
$ctrl.removeIframe(); // remove the iframe here
});
As a thing to try - see what's in the IE9 DOM viewer after it whitescreens. There's a decent chance that most of the stuff is there and just not rendering properly (or having something else rendered over it). At the very least, knowing whether it's losing a ton of stuff out of the DOM or not should give you some useful data.
I am unable to replicate the problem when I want to but it seems like every now and then, my site using FCKeditor will load the interface but not the content (Clicking the buttons don't do anything). No javascript errors show and once it starts doing it, it usually is tough to get back to normal. The way I found to work best is to click the refresh button multiple times in a row, then the FCKeditor loads correctly. I have only seen this in Firefox
Has anyone else run into this problem or know a solution. It is a little annoying for me but I am afraid my client would be really confused
I have experienced the phenomenon you describe in FCKEditor's successor, CKEditor. Somehow, the IFRAME that contains the WYSIWYG content doesn't get loaded. What always helps is switching to source code view and back, but that's no solution.
I have seen the problem described on the Internet but with no solution.
Caching is not the problem, I think. Sometimes, if you press "reload" 20 times, it will break at the 21th time, and work again on the 22nd time.
What minimized the number of occurrences for me was to activate the thingy to the editor's bottom that shows the element path (body > p > span, I forgot it's name). I don't now why but since I turned it on, it very rarely breaks any more.
I have had this problem. I solved it by pre-loading FCKeditor in a hidden iframe during the login process so that when it got to the pages where it was used it was already in the cache.
i would strongly advise to upgrade to CKEditor which can not only be spelled out verbally without offending anyone, but also optimizes the loading time to minimal. I find it much more responsive than his F- friend.
I encountered this problem with firefox (not reproducible) and chrome (reproducible).
The solution that worked quite well in both cases was to wait for some milliseconds before initializing CKE :
setTimeout(function() {textarea.ckeditor({customConfig : 'custom/schnonfig.js'})} , 100);