Skip to content

0.13 beta4 - devtools / source not found when clicking links from console #4269

Description

@maxbarry

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:

{
  "name": "sample",
  "main": "index.html"
}

index.html:

<!DOCTYPE html>
<html>
  <head>
    <title>Hello World!</title>
  </head>
  <body>
    <h1>Hello World!</h1>
    <script>
    nw.require('./myModule.js');
    </script>
  </body>
</html>

myModule.js:

console.log("Hello.");

To reproduce:

  1. Run nwjs-sdk-v0.13.0-beta4-linux-x64/nw .
  2. Right-click -> "Inspect background page"
  3. See output: Hello. /home/max/code/sports/test/myModule.js:1
  4. Click link to source

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:

<script src="myModule.js"></script>

... 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".

Activity

  1. maxbarry commented on Jan 18, 2016

    @maxbarry
    Author

    I also just posted in #4121, which is closed, but still exhibiting a similar crashing bug for me.

  2. ghostoy commented on Jan 19, 2016

    @ghostoy
    Member

    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:

  3. added a commit that references this issue on Jan 19, 2016
  4. added a commit that references this issue on Jan 20, 2016
  5. rogerwang commented on Jan 20, 2016

    @rogerwang
    Member

    Fixed in git and will be available in the next nightly build.

  6. added a commit that references this issue on Jan 23, 2016
  7. added a commit that references this issue on Feb 19, 2016
    89324ba
  8. 12 remaining items

  9. removed this from the milestone on Apr 2, 2016
  10. maxbarry commented on Apr 6, 2016

    @maxbarry
    Author

    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.

  11. rogerwang commented on Apr 6, 2016

    @rogerwang
    Member

    @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.

  12. rogerwang commented on Apr 6, 2016

    @rogerwang
    Member

    PS, the patch still has a chance to be in 0.13.x although it's marked as 0.14.

  13. added 2 commits that reference this issue on Apr 7, 2016
    0ffdf14
    24acd1f
  14. modified the milestones: 0.14.0, 0.14.x on Apr 14, 2016
  15. IssueHuntBot commented on Sep 17, 2018

    @IssueHuntBot
  16. championpaddler commented on Dec 21, 2018

    @championpaddler

    @maxbarry I am claiming this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions