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.
Related
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
I'm using an iPhone 11 Pro with iOS 15.3.1.
I'm trying to figure out why when visiting my website, Safari is freezing most of the time when the page loads. Sometimes the page loads the first time I visit it, but on reload it basically freezes with no interaction.
When I connect the iPhone to a Mac and use the Safari inspector to connect to the webpage on the iPhone, the inspector is basically blank on all screens. If I go to the "Elements" tab, nothing shows. If I go to the "Console" tab and try to execute some Javascript, nothing happens when I press enter.
On OSX, I can see similar behavior, except I can actually open the inspector before I visit the page. In this case, when it freezes I can see a few elements in the "Elements" tab, but that's about it. Any sort of interaction I try to do in the inspector results in nothing happening.
I'm at kind of a loss. How can the development experience for such a popular OS/Browser be so terrible, and how do I work around the inspector itself not working? I can't replicate this freezing on anything besides Safari.
To be absolutely clear on my question:
What is your process to debug a webpage in Safari when it is in a state where the inspector no longer interacts with the webpage?
I did a broad divide and conquer of my app, commenting out top level code and working my way down uncommenting until I found the exact line that causes the freeze.
It seems calling HTMLInputElement.setSelectionRange() inside an onfocus event handler function caused an infinite synchronous loop in Safari, perhaps Safari synchronously blurs the input and refocuses for some reason when that function is called. And on page reload Safari was trying to focus on an input with that code automatically. That is my guess at least, removing the setSelectionRange() resolves the freezing problem.
Luckily, the freezing was fairly consistent so the divide and conquer approach worked. Unluckily, the inspector really should have done its job and picked up on the fact that the page was hanging and told me which function code execution broke at when Javascript was forced to stop, like Chrome or Firefox would.
If anyone has any better ideas for debugging these kinds of issues in Safari besides the programming equivalent of a short circuit test, I'll gladly accept the answer.
I'm seeing an odd bug in IE that I'm not seeing in Chrome. Specifically, this involves some JS code not firing when a (Telerik) wizard is navigated back to it's first step.
When the user clicks their "Previous" button, some data isn't being properly loaded. Hitting F12 and bringing up the developer console has shown me the following Warning:
DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337
Ok, so I go to the link provided and I noticed the documentation states:
In order to be cached, webpages must meet these conditions:
...
- The F12 Developer tools window isn't open
This is a problem, because when I use the navigation buttons within my wizard WHILE the dev window is open, it behaves properly, just as it does in Chrome.
How can I debug my related Javascript so I can figure out what's going on? Also, I understand what caching is but I'm not exactly sure what this is about and I have no idea why Chrome behaves differently. Is there a way that I can force IE to behave like chrome and cut on (or off) whatever features that are causing this issue?
Yuck. Back to old school debugging for you.
Short of putting the whole browser into a Windows debugger, you can pretty much forget about setting breakpoints. All you can do is log.
If you are lucky and your problem isn't too deep, you can use a sprinkling of simple alert() statements to let you know the state of things at various stages in your code. One nice thing is that you can serialize objects now pretty nicely; for example, you can do JSON.stringify(this), which will probably give you a giant output, which you can copy and paste into your IDE and unpack. A major upside to doing this is that the alert will block, so you can take your time studying the output. A major downside to this is that race conditions are now much more likely.
Alternatively, you can add a <textarea> to the page and throw your JSON.stringify(this) results into that. Because this means extra DOM mutations, it also increases the odds of race conditions, but not by much. (If race conditions are a possibility, you can do this:
(function () {
var currentState = JSON.stringify(this);
setTimeout(function () {
document.querySelector('textarea').value = currentState;
}, 1000);
})()
Even though these are now asynchronous, if you use this multiple times in sequence, these will execute in that same sequence (unless you change the timeout period).
If you are doing actual page navigations (and not just changing the URL with pushState()), then actually reading those logs is going to be a problem. The solution is to put the page in a frame and write the content out to a sibling frame. As long as both frames are running on the same domain, you will have no problem pushing the data into the sibling frame. If you can't put them on the same domain, you are kind of screwed.
I have a php page that hangs for 3-10 seconds after the page loads, you can't even scroll up or down, or close the tab when this happens. (the chrome loading gif still loops tho) Happens in Chrome and IE.
Chrome Timeline: http://imgur.com/wF5Pioz,KRbnxIm#0
Shows ContentVeil.js repeating over and over. I think it is client side(?), I did a grepWIN to search for ContentVeil, with no luck, and it doesn't show up in Chrome Network tab.
Chrome Profile: Second image, from above link.
I think this shows the issue at the anonymous function from meta-boxes.min.js, ln 1.
meta-boxes.min.js: http://pastebin.com/yqtJyqB1
Unfortunately line one is a function that encapsulates the whole script. I don't know js very well, I tried to just remove each function one by one but that just created more errors.
Any ideas on how I could find the source of the problem would be much appreciated.
It's part of the Evernote web clipping extension, and it's hooks DOM events, causing massive slowdowns if you are doing large amount of dom changes.
I am troubleshooting some slow jquery code on a drupal module. After the page loads on a configuration form, you click on an area to expand out a fieldform. However, this expansion takes forever, and most browser give a warning "The script has become unresponsive, do you want to stop it?"
I'm looking for a profiler that will give output like that from xdebug, where I can see the statistics of the entire execution path, just for that one javascript event.
The debugger in firebug will drop me in on the exact line where firefox decides that the script is taking too long; but there is no single line that is the problem (at least I don't think so at this point). I believe that the slowdown comes from some poorly-architectured looping or iteration that spans multiple lines, which is why I want the profiler stats to show me in what parts of the code its spending most of the time.
The Firebug add-on has a profiler built into it. I don't have Firebug installed on the machine I'm using right now, but if I recall it's accessed from a pull-down menu in the "Console" view. (I could be wrong; it's there somewhere.) I can't say that I'm super-fond of it, but you might want to give it a try.
Chrome's developer tools also has a profiler, which is a little fancier.
For IE, there's a product called dynaTrace AJAX edition, which has a really fancy profiler. Of course it only works with IE, but you're going to have to test in IE anyway — if you've got a page that's slow in other browsers, it's going to be even worse in IE :-)