Tips on solving 'DevTools was disconnected from the page' and Electron Helper dies
Asked Answered
T

15

48

I've a problem with Electron where the app goes blank. i.e. It becomes a white screen. If I open the dev tools it displays the following message.

enter image description here

In ActivityMonitor I can see the number of Electron Helper processes drops from 3 to 2 when this happens. Plus it seems I'm not the only person to come across it. e.g.

But I've yet to find an answer that helps. In scenarios where Electron crashes are there any good approaches to identifying the problem?

For context I'm loading an sdk into Electron. Originally I was using browserify to package it which worked fine. But I want to move to the SDKs npm release. This version seems to have introduced the problem (though the code should be the same).

Tine answered 6/3, 2019 at 21:12 Comment(4)
Check your terminal is there any error?Coldshoulder
There are none. I tried to catch uncaughtException and SIGTERM but those handlers are not being triggered.Tine
Can you provide some code or link for code?Coldshoulder
I've been unable to identify which part of the code is causing the problem. Hence I can't provide a cut down version of the code. Currently it's only a prototype on my local machine.Tine
T
21

A good bit of time has passed since I originally posted this question. I'll answer it myself in case my mistake can assist anyone.

I never got a "solution" to the original problem. At a much later date I switched across to the npm release of the sdk and it worked.

But before that time I'd hit this issue again. Luckily, by then, I'd added a logger that also wrote console to file. With it I noticed that a JavaScript syntax error caused the crash. e.g. Missing closing bracket, etc.

I suspect that's what caused my original problem. But the Chrome dev tools do the worst thing by blanking the console rather than preserve it when the tools crash.

Code I used to setup a logger

/*global window */
const winston = require('winston');
const prettyMs = require('pretty-ms');

/**
 * Proxy the standard 'console' object and redirect it toward a logger.
 */
class Logger {
  constructor() {
    // Retain a reference to the original console
    this.originalConsole = window.console;
    this.timers = new Map([]);

    // Configure a logger
    this.logger = winston.createLogger({
      level: 'info',
      format: winston.format.combine(
        winston.format.timestamp(),
        winston.format.printf(({ level, message, timestamp }) => {
          return `${timestamp} ${level}: ${message}`;
        })
      ),
      transports: [
        new winston.transports.File(
          {
            filename: `${require('electron').remote.app.getPath('userData')}/logs/downloader.log`, // Note: require('electron').remote is undefined when I include it in the normal imports
            handleExceptions: true, // Log unhandled exceptions
            maxsize: 1048576, // 10 MB
            maxFiles: 10
          }
        )
      ]
    });

    const _this = this;

    // Switch out the console with a proxied version
    window.console = new Proxy(this.originalConsole, {
      // Override the console functions
      get(target, property) {
        // Leverage the identical logger functions
        if (['debug', 'info', 'warn', 'error'].includes(property)) return (...parameters) => {
          _this.logger[property](parameters);
          // Simple approach to logging to console. Initially considered
          // using a custom logger. But this is much easier to implement.
          // Downside is that the format differs but I can live with that
          _this.originalConsole[property](...parameters);
        }
        // The log function differs in logger so map it to info
        if ('log' === property) return (...parameters) => {
          _this.logger.info(parameters);
          _this.originalConsole.info(...parameters);
        }
        // Re-implement the time and timeEnd functions
        if ('time' === property) return (label) => _this.timers.set(label, window.performance.now());
        if ('timeEnd' === property) return (label) => {
          const now = window.performance.now();
          if (!_this.timers.has(label)) {
            _this.logger.warn(`console.timeEnd('${label}') called without preceding console.time('${label}')! Or console.timeEnd('${label}') has been called more than once.`)
          }
          const timeTaken = prettyMs(now - _this.timers.get(label));
          _this.timers.delete(label);
          const message = `${label} ${timeTaken}`;
          _this.logger.info(message);
          _this.originalConsole.info(message);
        }

        // Any non-overriden functions are passed to console
        return target[property];
      }
    });
  }
}

/**
 * Calling this function switches the window.console for a proxied version.
 * The proxy allows us to redirect the call to a logger.
 */
function switchConsoleToLogger() { new Logger(); } // eslint-disable-line no-unused-vars

Then in index.html I load this script first

<script src="js/logger.js"></script>
<script>switchConsoleToLogger()</script>
Tine answered 13/5, 2019 at 11:40 Comment(0)
V
4

I had installed Google Chrome version 79.0.3945.130 (64 bit). My app was going to crash every time when I was in debug mode. I try all the solutions I found on the web but no one was useful. I downgrade to all the previous version:

  1. 78.x Crashed
  2. 77.x Crashed
  3. 75.x Not Crashed

I had to re-install the version 75.0.3770.80 (64 bit). Problem has been solved. It can be a new versions of Chrome problem. I sent feedback to Chrome assistence.

Varve answered 22/1, 2020 at 10:12 Comment(2)
Likewise for me: Google Chrome 80.0.3987.87 (64 bit) always crashing at the same point when debugging with breakpoints. Installed Google Chrome 75.0.3770.100 (64 bit) instead -> FIXED.Baeza
I update Chrome Canary. It works.Exploratory
A
3

My problem was that I was not loading a page such as index.html. Once I loaded problem went away.

  parentWindow = new BrowserWindow({
    title: 'parent'
  });
  parentWindow.loadURL(`file://${__dirname}/index.html`);
  parentWindow.webContents.openDevTools();
Antrorse answered 10/8, 2021 at 3:14 Comment(0)
L
2

The trick to debugging a crash like this, is to enable logging, which is apparently disabled by default. This is done by setting the environment variable ELECTRON_ENABLE_LOGGING=1, as mentioned in this GitHub issue.

With that enabled, you should see something along the lines of this in the console:

enter image description here

Loaded answered 3/9, 2020 at 20:20 Comment(0)
U
1

You can download Google Chrome Canary. I was facing this problem on Google Chrome where DevTools was crashing every time on the same spot. On Chrome Canary the debugger doesn't crash.

Underact answered 4/3, 2020 at 23:15 Comment(0)
E
1

I also faced the exact same problem

I was trying to require sqlite3 module from renderer side which was causing a problem but once i removed the request it was working just fine

const {app , BrowserWindow , ipcMain, ipcRenderer } = require('electron')
const { event } = require('jquery')
const sqlite3 = require('sqlite3').verbose(); // <<== problem

I think the best way to solve this (if your code is really really small) just try to remove functions and run it over and over again eventually you can narrow it down to the core problem

It is a really tedious , dumb and not a smart way of doing it , but hey it worked

Eli answered 24/9, 2021 at 12:12 Comment(2)
I am too having issues with sqlite3 but it should work on the renderer side shouldn't it?Atomics
Moving the require('sqlite3') inside a function and exposing that function to the window to be called from the HTML seems to have worked. Not sure if that's the preferred way. You can see the issue here: github.com/mapbox/node-sqlite3/issues/1504Atomics
R
0

I encountered this issue, and couldn't figure out why the the DevTool was constantly disconnecting. So on a whim I launched Firefox Developer edition and identified the cause as an undefined variable with a string length property.

if ( args.length > 1 ) {
    $( this ).find( "option" ).each(function () {
        $( $( this ).attr( "s-group" ) ).hide();
    });
    $( args ).show();
}

TL;DR Firefox Developer edition can identify these kinds of problems when Chrome's DevTool fails.

Raye answered 16/1, 2020 at 20:0 Comment(1)
But Electron does not use Firefox.Neurogram
R
0

Open your google dev console (Ctrl + shift + i). Then press (fn + F1) or just F1, then scroll down and click on the Restore defaults and reload.

Risibility answered 25/1, 2021 at 4:48 Comment(0)
F
0

After reading the comments above it is clear to me that there is a problem at least in Chrome that consists of not showing any indication of what the fault comes from. In Firefox, the program works but with a long delay.

But, as Shane Gannon said, the origin of the problem is certainly not in a browser but it is in the code: in my case, I had opened a while loop without adding the corresponding incremental, which made the loop infinite. As in the example below:

var a = 0;
while (a < 10) {

  ...

  a ++               // this is the part I was missing;
}

Once this was corrected, the problem disappeared.

Feuilleton answered 13/2, 2021 at 0:30 Comment(2)
"But the origin of the problem is certainly not in a browser, as Shane Gannon said". I did not say the problem was with a browser. I said it was a syntax error. Which is unlikely to be a browser problem.Tine
You're right, that's what I wanted to say actually. I have edited the sentence to make it clear.Clavicytherium
L
0

I found that upgrading to

  • react 17.0.2
  • react-dom 17.0.2
  • react-scripts 4.0.3

but also as react-scripts start is being used to run electron maybe its just react scripts that needs updating.

Laurice answered 28/6, 2021 at 8:27 Comment(0)
C
0

Well I nearly went crazy but with electron the main problem I realized I commented out the code to fetch (index.html)

// and load the index.html of the app. mainWindow.loadFile('index.html');

check this side and make sure you have included it. without this the page will go black or wont load. so check your index.js to see if there's something to load your index.html file :) feel free to mail : [email protected] if you need additional help

Clothe answered 8/9, 2021 at 16:28 Comment(0)
P
0

Downgrade from Electron 11 to Electron 8.2 worked for me in Angular 11 - Electron - Typeorm -sqlite3 app.

Pilgarlic answered 17/1, 2022 at 6:4 Comment(0)
P
0

It is not a solution as such, but it is an assumption of why the problem. In the angular 'ngOnInit' lifecycle I put too many 'for' and 'while' loops, one inside the other, after cleaning the code and making it more compact, the problem disappeared, I think maybe because it didn't finish the processes within a time limit I hope someone finds this comment helpful. :)

Plusch answered 1/6, 2022 at 22:33 Comment(1)
You should offer your contribution as a comment since you've stated that it is more a diagnostic than a solution :)Indivisible
R
0

I have stumbled upon the similar problem, My approach is comment out some line that I just added to see if it works. And if that is the case, those problem is at those lines of code.

  for(var i = 0;i<objLen;   i+3   ){
    input_data.push(jsonObj[i].reading2);
    input_label.push(jsonObj[i].dateTime);
  }

The console works fine after i change the code to like this.

  for(var i = 0;i<objLen;   i=i+space   ){
    input_data.push(jsonObj[i].reading2);
    input_label.push(jsonObj[i].dateTime);
  }
Radix answered 29/9, 2022 at 4:3 Comment(0)
D
0

I had the same problem. It happened on a website I was developing. First, I removed every <script> from the page but the dev console kept crashing.

Then I started to remove stylesheet-files and the dev console didn't crash anymore.

In the end it was this (false) rule that caused the crash:

@font-feature-values {
  font-display: fallback;
}
Diphenyl answered 26/4, 2023 at 11:41 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.