I have a weird problem that I hope someone encountered, because I don't know if I can provide much detail about it (sorry).
I'm working with TiddlyWiki as a local HTML file. It's a wiki that is entirely in one HTML file. It has javascript plugins, also in the file. When it loads it sets them up as separate scripts in devtools.
I want to modify one of these on the fly. What I used to do was open the script (it opens in its own tab), edit it, save, and the changes would take effect until reload.
All of a sudden, this stopped working. Not only my changes don't take effect, but breakpoints in the script, which used to work fine no longer work. If I make the change while in a breakpoint, and save, the browser jumps to the script that calls the method in the changed script. The breakpoint no longer works and I can't step into any method in the modified script. The modifications don't take effect.
I tried using local overrides, adding, removing, resetting, deleting the files. Everything I could think of. Note that I didn't need these in the past (that is, until a few days ago).
Turns out this was probably due to something with encoding. I use vi to copy&paste the text and then save as ascii, then copied that to the wiki and everything started working as expected
Related
What I'm saying is I'm trying to see how everything is working in a particular file. My problem is even stepping over a particular line or stepping out of a function, it will still take me to a function in a separate javascript file I have (such as jQuery, particular APIs, etc) when I don't care how that works since I know the issue is with my Javascript. Is there some way I can disable jumping through those or ignore seeing them work? Like I kind of said, I only want to see how much code works in one specific file, not how the whole thing compiles and runs altogether.
Open Chrome Developer tools, click 'Settings' in top-right corner:
Then, select 'Blackboxing' from the menu on the left:
And add patterns of all 3rd party libs which you'd like the debugger to skip.
I have been developing a simple browser extension, and I have ran into a very strange behavior that happens on Chrome while it doesn't happen on Firefox. Basically, the extension runs much slower in Chrome than in Firefox, and it takes 3+ seconds to add a single class to a button, while it happens in milliseconds in Firefox.
This repo contains a demonstration of the issue. What is supposed to happen is, when the input box is not empty, the button should change color, this is almost instantaneous in Firefox, but it takes seconds to update in Chrome.
I have noticed that:
Further observations:
The problem goes away if I remove the TailwindCSS import in App.vue file.
The problem goes away if I remove the background script from the manifest.json file.
The problem goes away if I run performance profiling in Chrome Performance tab on the inspect window.
If I visit the extension page directly in the browser, like chrome-extension://extension-id/popup/popup.html#/ it is totally fine, there is no lag or anything.
For the first two, Webpack seems to be including a lot of extra code into the bundle, and removing any of these seems to be reduce the bundle size significantly.
For the third one, I imagine Chrome is prioritizing the extension execution when the performance profiling is enabled, therefore it is fast back again. This is probably the case for the last one as well because the page is in focus and it is probably the most important page to run for Chrome at that point. I believe this problem has something to do with the way Chrome runs Javascript in extensions or the way it redraws the UI.
This seems to be a very weird behavior, and I couldn't find any prior reports regarding this behavior. Any help is appreciated, I cannot think of anything else to add but I can add more details as requested.
I am building a web based JS REPL (similar to http://jsfiddle.net/), but I find it really annoying to have to switch between the Chrome Developer Console and my own code to debug. I have a text area on the left (using the wonderful Ace Editor) and clicking a preview button loads another window into an iframe on the right with the code I was editing. It made me wonder, what if I was able to add breakpoints to my code editor in the browser window and when it hits the breakpoint I could see the state of variables, step through the code, and remove breakpoints all while still editing the code in the editor. Very similar to real debugging, but in the browser instead of an editor like Eclipse.
I think a Chrome Extension is the right way to go. I can make calls to the debugger using the debugger API, then add breakpoints, step over, step out, etc. using this protocol. This works great and I can even get the current state of variables when the breakpoint is hit using Runtime.getProperties.
The problem is... that once I pause the code to debug, everything on the entire page freezes (of course, because I'm debugging). Can anyone think of a way to get around this? The ideal solution would allow me to freeze and debug the result on the right in the iframe and still manipulate the code on the left.
Hi I know that there's a question about this already, but all of the answers don't seem to be working for me.I'm trying to make the JS console not reset on navigation.I know there's the "Preserve log upon navigation" checkbox/button, but it's not working for me.Whatever I entered is cleared and the page is loaded as default. How can I make it save what I changed, like a kind of add-on? (preferably without installing any additional tools)..Or am I misunderstanding the use of the preserve log upon navigation thing? Anyway, how can I achieve what I'm hoping to?Thanks in advance!
The "Preserve log upon navigation" setting doesn't store any changes you've made to the DOM using the console, it only preserves the log of what has been output to the console.
As far as I know there is no way to preserve the changes you've made via the console across links/refreshes since you are always loading/reloading the page. I doubt there are even add-ons to preserve that kind of thing.
As winterblood stated in his answer, there's no way to preserve the changes made to any js file or the dom after a page refresh.
What you CAN preserve however are the breakpoints in the code. So if you need to place a change very early on, you can search the first script to be loaded, put a breakpoint in it, and refresh the page. When the page refreshes, then you can make any changes on it that you wish.
Another solution is to use a proxy like charles or fiddler, and do a "map local" of a local js file with your changes in it. See this link for that. I do this a lot in my work. It's dead easy to copy/paste a file from the chrome console into a local file, then use charles to do a map local of the request for that file and reload the page. If everything goes well, you will be able to do any changes you want to that file without modifying anything else in the page.
What is changed, from the point of view of running AJAX application, when the IE Developers Tools are opened?
I'm tracing now some Schrödinger bug. It's about dropdown lists from PrimeFaces in IE. They are sometimes not opening after click, and they got 'unblocked' after one maximizes browser or unzooms the content. Because those dropdowns are realized on the basic of normal input, with attached div, I supposed it's something with wrongly calculating the place to show that dropdown popup. I've also supposed AJAX errors.
But after opening IE Developers Tools it's hardly possible to reproduce the error. No error is showed in console, no AJAX request hangs, and, what's more, everything seems to function more.
The error is only for IE, so the developers tools are the only way to debug it. However, when they are opened, it seems that the observation changes the state somehow, like in quantum mechanics...
So, I need to know, what could be changed by opening those developers tools, that prevents the bug from showing up?
--edit--
It has nothing to do with console.log. It is the problem with calculating the size of invisible elements. The problem was solved by adding scroll to the body. However, the question is open, how the IE Developers Tools were influencing those calculations.
If you really want to always include using console, I suggest using a polyfill for it:
(function(b){
var a=0;
var c=function(){};
var d=["log","assert","clear","count","debug","dir","dirxml","error","exception","group","groupCollapsed","groupEnd","info","profile","profileEnd","table","time","timeEnd","timeStamp","trace","warn"];
b.console=b.console||{};
for(;a<d.length;a++){
b.console[d[a]]=b.console[d[a]]||b.console["log"]||c;
}
})(window);
This a minified example that I tried to make readable. It's something I found awhile ago and modified some. I think the main thing I modified is that if you call a method that wasn't originally implemented by the browser's native console, it will call console.log. If console.log wasn't natively implemented, it just calls an empty function. The original version of this code didn't include this fallback to console.log.
This will "guarantee" that console calls will not fail. You can change the d variable to only include calls you are sure you will use, otherwise there's some extra unnecessary processing.