In previous versions of Mozilla Firefox, I had a button on the toolbar that shows the JavaScript / CSS errors and warning. A click on this button - open the console, which display the page code and errors places. In the new version of Firefox (V.25), I can not get this button on the toolbar header. Who knows how to place the button on the top panel? Or maybe you know a plugin that can show the JS / CSS errors on the toolbar? Look at the screenshot, where I want to see the JS / CSS errors
Thanks.
Firebug, when turned on, can give you notifications like so:
I got bugged months before for the same problem i.e v25 of Mozilla. what i did was moved back to v20 which is quite easy to understand.
By the way you can use Ctrl + Shift + J. Always helps.
Refer this Link i think this post is in the same context.
Firefox - enable reporting of Javascript errors
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.
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.
X-Editable (bootstrap 2 version) is not working Chrome properly. When I click buttons, nothing changes (both save and discard changes). Looks like x-editable didn't respond to click event. What's more, console is not logging any errors. Works in firefox 25 and IE 10.
Tried to use normal and minified version.
For anyone else having this issue, the !this.tip().is(':visible') was also failing for me. It turns out I had forgotten to include the bootstrap-editable.css file which has a display: inline-block; rule. Without this CSS Chrome reports the span as not being visible.
Copied from enter link description here
I've found solution. It's related to this question. It turned out, that "if" with "is(':visible')" statement returns different values in Chrome and FF, so x-editable form is not hidding.
My Firefox automatically updated today to version 15. There is now a built in javascript debugger.
Can somebody point me to a useful page that explains how to get to it and optionally how to use it?
I have firebug installed - does that override it?
I have found something that says CTRL-SHIFT-S is the short cut key for it, but this seemingly does nothing.
If, like firebug, I need to set a breakpoint, how do I do this?
look here at the bottom of the page at the unresolved issues... Page reload does not start the debugger...
You can go to Tools / Web Developer and the Debugger for example.
Yes firebug seems to remove the source editor, try disabling it shortly then view the source and you should be able to add breakpoints.
I am building a site that has an image map menu with a popup box that is supposed to pop at the mouse when the mouse is hovering over a particular area. It works great in firefox and IE but when I load the page in chrome the boxes appear as if the page were not scrolled. it works fine if the page is scrolled all the way to the top, but as soon as the user scrolls down, the boxes are to high on the page.
I am using a script i got from http://www.dhtmlgoodies.com/index.html?whichScript=bubble_tooltip www(dot)dramanotebook(dot)com/menu/ (i can only put one hyperlink in)
Thanks in advance for Your help
Thats a bug in this script that also shows up on the example page. Maybe its enough to delete this line:
if(navigator.userAgent.toLowerCase().indexOf('safari')>=0)st=0;
I was about to ask 'have you tried this in Safari?', since Chrome and Safari both use the webkit engine.
Take a look at the .js file.
function showToolTip(e,text){
/* blah blah*/
var st = Math.max(document.body.scrollTop,document.documentElement.scrollTop);
if(navigator.userAgent.toLowerCase().indexOf('safari')>=0)st=0; /**** THIS ****/
var leftPos = e.clientX - 100;
/*etc.*/
}
It has a fix applied specifically to Safari, using the userAgent string. Chrome sends 'Safari' in the user agent string, too, so it will apply that to Chrome also. This is generally considered a poor practice. In general, I'd say the scripts from dhtmlgoodies are very outdated. Is this fix still needed for newer webkit renderers? Who knows. You might try commenting it out and seeing if that fixes it.