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.
Related
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 have a simple html page that displays some monitoring results, it reloads every 2 minutes and makes noise when those results are not acceptable. I keep this page open 24/7, so new Chrome started freezing and suspending it, as I found out via chrome://discards/ .. So the page stopped making noise and catching my attention, mostly cause the tab gets frozen by Chrome. That happens if I forget to leave the tab with this page active, "on top". Is there a rather simple way to prevent Chrome from freezing the tab, even if it is not active? I could involve some Javascript, if needed..
I am aware that there is a simple solution of opening new window with this page and leaving it alone. On the other hand, I made the page, so I can make changes to HTML in order to ensure that page remains unfrozen. I tried updating title with current time on every reload, this visibly helped, page seemingly always has fresh time in the title, but it still doesn't make noise. And if I switch into it when noise is supposed to happen, - it starts the sound half way like it was trying to all alone.. it's even funny..
Is there any simple solution to this? Thanks for your help.
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.
So, I am in a conundrum with my JS failing after a certain amount of time through the menu navigation. Since it works with the console debugger open, I assumed it was a console.log error, but I have removed those functions.
If you open up this page, http://behrent.com/test/Industry.html, in internet explorer, then use either your arrow keys or the menu headers to scroll many times right or left in a row it will break. It currently works in Chrome and FF.
It's almost as though the js crashes or something.
Any ideas on what might be occurring? My JS doesn't have any console.log.
On another page using same css and js, but different html it is also producing scary behavior. http://www.behrent.com/test/Services.html. Basically if you go to that site you can navigate through them if you go slowly, but if you go very quick it will then break in the same fashion as the first page.
Just hope I don't have to move to another layout.
Chad
Figured it out. IE was expecting background images in the various sections, but I didn't indicate that any existed. IE got confused because it was expecting them as I indicated, but they didn't exist in the css, so it just broke.
Calling not existent sections with js makes things break. The more you know...
The following trick for getting page's HTML content after javascript has been rendered works pretty well, when placed in the onNewPicture() of a WebView's PictureListener:
browser.loadUrl("javascript:window.HTMLOUT.showHTML('<head>'+document.getElementsByTagName('html')[0].innerHTML+'</head>');");
However, for some reason it works only the first time the page is loaded. That is, the application's first such WebView.loadUrl() call gets a completely rendered version of the page.
Thereafter, if I reload/refresh the page (same exact URL), the output of HTMLOUT.showHTML() appears to be the original HTML+javascript before the page was rendered.
The strange thing is that visually, on the WebView itself, all content is there! (albeit after a significant delay... I can see the WebView's hourglass spinning, perhaps it takes too long for Javascript to be re-processed?)
This seems to suggest either an initialization problem (in my code), a bug in WebView, or some caching principle that is well known to experienced web programmers but with which I am not familiar with yet.
But then it gets even more interesting: Subsequent calls to WebView.loadUrl() result in the aforementioned failure multiple (3-10) times until... the page is miraculously fully rendered again! (and then multiple failures again, and so on)
Which may suggest timing problem?
Any suggestion on how to debug or troubleshoot this?
you have to inject the javascript after the page loads! Took me forever to figure it out