Open maxbarry opened 8 years ago
I also just posted in #4121, which is closed, but still exhibiting a similar crashing bug for me.
The root cause is that NW crashes when trying to opening a new window in a tab, which was the behavior of Chrome browser. It will happen in following scenarios:
Fixed in git and will be available in the next nightly build.
Just checked back in and this is still happening in RC4:
package.json:
{
"name": "sample",
"main": "index.html"
}
index.html:
<!DOCTYPE html>
<html>
<head>
<title>Hello World!</title>
</head>
<body>
<h1>Hello World!</h1>
<script src="myModule.js"></script>
</body>
</html>
myModule.js:
console.log("Loading myModule2...");
nw.require('./myModule2');
myModule2.js:
console.log("Greetings from myModule2!");
myTestError();
There are two ways to get the buggy behavior with this test case. Here is the first:
../nwjs-sdk-v0.13.0-rc4-linux-x64/nw .
Greetings from myModule2.js! /home/max/code/test2/myModule2.js:1
Result: New browser window opens with URL chrome-devtools://devtools/home/max/code/test2/myModule2.js
. Browser window says: "This site can’t be reached. The web page at chrome-devtools://devtools/home/max/code/sports/test2/myModule2.js might be temporarily down or it may have moved permanently to a new web address."
Second method:
../nwjs-sdk-v0.13.0-rc4-linux-x64/nw .
Uncaught ReferenceError: myTestError is not defined /home/max/code/test2/myModule2.js:3
Result: Same as before ("The site can't be reached.").
In this scenario, clicking the first line of output (Loading myModule2... myModule.js:1
) works, but clicking the second doesn't.
Ubuntu 15.10 64-bit.
@ghostoy please take this issue. FYI the link href handling is WebInspector.linkifyURLAsNode of third_party/WebKit/Source/devtools/front_end/components/Linkifier.js. After giving the "file://" prefix it can be opened correctly with browser window. But ideally we need it to be loaded in the Resource pane as the other JS file.
There are three internal causes:
opener.func()
which throws exceptions. So I won't fix it.Sorry, more of a question than a bug report, but I just noticed this is now milestoned for 0.14, and am a bit alarmed at the idea of not being able to use 0.13 at all.
Is there a workaround for this bug? I don't understand how I can work with 0.13 since I can't debug. The only thing I can think of is to merge the entire app into a single file so that it doesn't 'require' anything.
@ghostoy had a fix. It's still under review and it's marked as 0.14 because the underlying change is important. We want to make sure it doesn't have any side effects. @ghostoy can we have some way to enable it only in SDK build?
btw, 0.14 would be released soon with Chromium 50 stable in 1-2 weeks.
PS, the patch still has a chance to be in 0.13.x although it's marked as 0.14.
@loadbalance-sudachi-kun funded this issue with $256. Visit this issue on Issuehunt
@maxbarry I am claiming this issue.
In beta4 on Ubuntu 15.10 64-bit, clicking a link to source from the console opens a new ERR_FAILED browser window with "This webpage is not available," rather than displaying the source within devtools:
package.json:
index.html:
myModule.js:
To reproduce:
nwjs-sdk-v0.13.0-beta4-linux-x64/nw .
Hello. /home/max/code/sports/test/myModule.js:1
Result: New window opens. URL is "chrome-devtools://devtools/home/max/code/test/myModule.js". Title is "chrome-devtools://devtools/home/max/code/test/myModule.js is not available - NW.js". Content is: "This webpage is not available | ERR_FAILED | The webpage at chrome-devtools://devtools/home/max/code/test/myModule.js might be temporarily down or it may have moved permanently to a new web address."
Notably, this only happens when myModule.js is included in the above fashion. If instead index.html includes it like this:
... then it works, except that it doesn't seem to correctly link to the right line number, and the output must be viewed via "Inspect" rather than "Inspect background page".