Chromium sometimes shows that my angularjs application is busy, although it isn't:
Instead of the favicon, it shows a spinner.
Instead of the reload circular arrow, it shows a cross.
The application is idle, reacts quickly, and I can't see any activity in the devtools: There's no outstanding request and the timeline has zero events. The computed is idle.
Clicking on the cross (which stops loading), does nothing at all (and the cross does not change to a circular arrow). Nor does clicking on the stop icon in the source code debugger do anything.
Any chance to find out what's causing this?
Related
I am in the process of developing a data visualization; however, I have run in to a problem that appears (seemingly randomly). When the page is first loaded, sometimes chrome will 'lock up'; The chrome toolbar will disable all command keys (ie copy, paste, select all...) and events will be incorrectly triggered (mouseover events get triggered on click, click events are triggered on double click, etc...)
I have already tried opening and closing the inspector window, searching for a memory leak, and trying to identify any infinite loops in my code.
I'm running a local http server via python 3, accessing the page via google chrome on macOSX, but I'm not sure if any of that may be related.
Edit: I found that clicking on another application other than chrome and then clicking back on chrome fixes the issue; however, I'd ideally want our user to not have to do that.
I have a problem when I am trying to check the source of an interesting page which keeps refreshing automatically every 3-5 seconds (presumably due to some js script) which resets my Inspect Element Inspector window every time the page is refreshed.
Is there any other way other to stop that page from refreshing or perhaps the Inspector window from resetting itself other than turning on NoScript to stop the page from refreshing automatically?
Usually I just open DevTools, switch to the appropriate panel if necessary, and hit pause.
Opening DevTools: Via menus, or by press F12, Ctrl+Shift+I, or Cmd+Shift+I depending on browser and OS.
Switching panels: Pick the panel from the tabs at the top of DevTools. It'll be called "Debugger" (Firefox, IE) or "Sources" (Chrome) or similar.
Pausing: In the Debugger/Sources panel, click the pause button (usually looks like the pause button on a television remote control, ||) or press the keyboard equivalent. Keyboard equivalents are
Firefox & Chrome: F8
IE: Ctrl+Shift+B
(Updated 2020-03-30)
In Firefox 74 this option is in Options -> Privacy & Security -> Permissions
(Original reply)
Firefox has the option to prevent refresh natively, the option is in Advanced->General->Warn me when websites try to redirect or reload the page
The most popular solution for this problem is to trap the beforeunload event. The browser will ask the user for confirmation to leave the page. The code, in its simplest form, looks like this:
window.onbeforeunload = function() { return true }
You can enter this code in console. Alternately, you can simply paste the following URL in the browser address bar (console not required). You can even bookmark it.
javascript:window.onbeforeunload = function() { return true }
Be advised that modern browsers might chop off the javascript: part when you paste it inside the address bar; make sure you type it back.
To determine the cause of redirect in Firefox, try the following:
Open Web Developer Tools (CTRL + SHIFT + I), open "Toolbox Options" and check the "Enable persistent logs" option. This makes the logs persist across page loads (logs are cleared otherwise).
Now switch to "Network Monitor" tab.
Open the URL and let it refresh.
Inside the Network Monitor > Cause column you will find out why the page reloads.
The cause column is pretty ambiguous (Chrome does a much better job). However, if JavaScript was used to trigger page (re)load then it at least shows you the filename and line number of that script.
When the page is still loading, you can press the Esc key. While the page is still white, press it. When you stop the page from loading at this point, this usually stops all the auto loaded javascript. Any scripts that run on actions are usually not effected. Each page is different, try different timings.
When I use a site called NovelUpdates there is javascript that can make certain elements hidden, and when I press Esc on page load all the elements that would be hidden after page load are visible. Then when I click a button that would execute javascript that operates with no problems. NoScript isn't going to solve your issue I believe.
Another example of this are those websites with annoying boxes that pop out after 10 seconds that says you aren't a member and can't view any more of this site without logging in, like some news article websites.
What you could do is use the command exit(), which is the equivalent to die in php and simply stops the script.
If you don't know what's causing it and you don't want to look for the "bad boy", then you might as well stop the entire script at the very bottom of the page.
I'm seeing some strange behavior in Chrome that I'm trying to verify is intended (or possibly a bug?). Here are the steps I took:
First I opened the Chrome task manager, right-clicked and selected "JavaScript memory"
Next I navigated to a test page that has a link that opens a new popup window when clicked
The popup window loads a page that includes a lot of large third-party JavaScript libraries
I checked the Chrome task manager and the JavaScript ram had increased significantly for the test page after opening the popup
Finally, I closed the popup window and waited, but the memory usage basically stayed where it was at.
If I clicked the link on the test page multiple times to open multiple popup windows, closing them doesn't seem to lower the memory usage.
I tried this test in IE and Firefox, and when closing the popups in those browsers the memory usage goes down as expected.
First off, it's great that you identified an action that you think is causing the leak! This is the first step in tracking down your problem, since it gives you a specific scenario to test before / after.
Since you already confirmed with the Task Manager that the memory is not being released, the next step is to do a Timeline recording:
Open your application on the page where the leak occurs and start the DevTools
Go to the Timeline tab in the DevTools and click Start Recording; Also, press the "Garbage" icon right now, to make sure Garbage Collection is triggered before you do your recording
In the application, open the dialog and then close it; you can also do this multiple times
Back to the DevConsole, click the "Garbage" icon again and then stop the recording
What do you see? Do you see in the Memory lane that it is never going doing? Or is the memory at the end the same as when you started?
Make sure to check the official DevTools documentation for more info on using the Timeline and other tools to find common memory leaks.
I was inspecting my page and I got this warning:
Deferred long-running timer task(s) to improve scrolling smoothness. See crbug.com/574343
I've also seen:
Blink deferred a task in order to make scrolling smoother. Your timer tasks should take less than 50ms to run to avoid this. Please see https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail and https://crbug.com/574343#c40 for more information.
What is this?
This occurs when Blink (Chrome's rendering engine) decides to delay executing a timer (like a function passed to requestAnimationFrame, setTimeout, or setInterval) because those functions are generally taking >50ms to execute and there is user touch input. It's done to prioritize handling user input (like scrolls and taps) above what the site is doing.
If you've encountered this message, then its likely your users will get similar behavior. Here's how to reproduce this scenario:
Have long-running javascript that is triggered via timers
Be on mobile (or emulating it with DevTools device mode)
Have touch input, scrolling with finger down on the screen is the most reliable. Tapping or flinging the page may also trigger it, but it is less likely and harder to reproduce.
The devtools' experimental CPU throttling will make the JS take longer and give you a better chance of seeing it.
The method for how to solve this is directly from the referenced issue in the console message down in comment 40:
Record a timeline on the page that is triggering the console message about deferral.
Select the entire timeline and open the "Event Log" pane near the bottom of the window.
Enter "Timer Fired" into the filter text field. (See image at bottom)
Look for timers in the list whose "Total Time" exceeds 50 milliseconds. These are the problematic ones. (Note that timers that exceed 10 milliseconds can also trigger this message in some cases where the browser is processing a user gesture. )
You want these functions to execute faster or less frequently.
I've got a page that shows real-time statistics. It runs a lot of javascript, makes a lot of HTTP requests, renders SVG charts every few seconds using D3.js, has a lot of CSS animations, and rearranges the DOM frequently.
As long as the page is focused, it runs smoothly. If I switch to another tab and come back later, there's often a short pause where the page seems to be frozen before the view suddenly seems to rerender and the page becomes usable again. The longer the tab has been backgrounded, the longer this pause is. If the tab has been in the background for a very long time (hours) and I switch back to it, it will be frozen for a long time then crash.
All these behaviors are observed in Chrome. I haven't tested much in other browsers.
What isn't Chrome doing while the tab is in the background, and what is it doing during that pause when I first switch back to the tab?
UPDATE:
I'm also doing some jQuery animating. This answer and this one may be relevant.
According to that first answer:
"Inactive browser tabs buffer some of the setInterval or setTimeout functions."
stop(true,true) will stop all buffered events and execute immediatly only the last animation.
I've added a call to .stop(true, true) in my code, and at least for short trips away from the tab, I'm not detecting a hiccup. I need to leave it in the background for a long time and test it before I can tell if it made significant difference.
We had a similar issue with SVG graphs and managed to solve it using Page Visibility API introduced with HTML5. If anyone stumbles upon such an issue please refer to the following article Using the Page Visibility API
What we managed to do was to suspend all SVG rendering activities when the browser window is not visible. This managed to stop the tab from crashing.
Yes, it's typical behavior of Chrome browser.
I guess that while your tab is in background, Chrome places all tab data on "back shelf" to clear "front shelf" that works much faster. I know, it sounds unprofessionally, but i hope that you understood.
I think it is very hard to solve this problem in your case (because you are using a lot of manipulations with graphic).. but maybe this method will save you (i had never tested it before):
Every time you update your statistics (or do some highload calculations), you can save a timestamp. Then, when you update your statistics again, you can substract that old timestamp of the new timestamp. And, if you see that the difference between timestamps is very big, use setTimeout() function before next update. Maybe, it will prevent Chrome's chash.