I have been happily using the Chrome development tools for some five years to debug my Angular/node.js code. I open the Chrome development tools, click on the "sources" tab, navigate my way to the "Webpack" link on the left, and find my way to the directory of all my Javascript source and away we go. Among other matters, the good folk of Chrome have continually improved the debugger over the years: it is a beautiful thing. I have been very happy.
Until this week, when suddenly the Webpack disappeared from the source options. I can see lots else (essentially, all the javascript referenced direct from the index.html file) but the webpack is not there. Nor is it accessible in Safari. But it is still there in Opera and Firefox.
What is going on? I can not be the only person who routinely uses Chrome to debug a webpack application. Help, please.
Here is a screenshot of what I see in my browser. First, as it now appears WITHOUT any Webpack access, in Chrome:
Second, as it still appears in Firefox (and Opera) with Webpack and all my stuff:
Update! I've found the code in Safari. But it no longer appears under the label "Webpack". Instead, it appears under the site URL-->dist-->app.bundle.js (which appears as a folder containing all the code files, thus:
However, app.bundle.js in Chrome is NOT a folder; clicking on it brings up this message:
Yes, I can see that I might here be able to use the "Filesystem" tab to import the files from my development system, and to edit and debug them directly in the debugger while running the app on a local host. Very neat. But actually, there are many times I need to be able to dig inside the app on the production system. I can still do this on Safari, Firefox, Opera. But not now on Chrome. Why not?
UPDATE! I have been digging yet further. Not only is it only Chrome that has this problem. It appears that it is only Chrome on an M1 chip Mac running Big Sur. And digging still deeper: when I look at the app.bundle.js file I discover -- lo and behold! -- all 13000 lines of my code, originally distributed across some 60 component.js files, appears in this one indigestible mega file. Yes, I could find the bit I am working on in there and debug it. So Chrome developers: how come the Safari folks are able to deconstruct app.bundle.js back to the original file structure and you guys cannot?
Related
I used to edit the JavaScript code in our app through chrome dev tools and those changes worked fine. For the past few months, I'm not able to do the same. Chrome is still allowing me to edit the code, but those changes are not reflected. And also, I'm not even able to hit the breakpoint once I make changes in the file where I had the breakpoint.
I did find a solution/workaround, which is by enabling the "overrides" option in the chrome dev tools and attached the workspace (target build) folder. This process is currently working fine.
But I'm still curious why live edits suddenly stopped working. Anyone had encountered similar problem and know any root cause?
This question was answered with configuration for webpack. I am trying to get source maps working myself and wondering why chrome (and firefox) are not respecting the comment
//# sourceMappingURL=main.js.map
I thought I should see a network request to the server in devtools for the map file, right? Why is that not happening and how do we modify the main.js file created by webpack OR the *.js file created by our other tools such that it works without configuring chrome developer tools like was done before. I figure since both firefox and chrome are not working, there must be some new standard I am missing? (but not sure since webpack does not seem to do it properly?)
Firefox says it should be just do the above here -> https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map
I've a really annoying problem on recent Chrome version 75.0.3770.90, also on Canary and Dev versions (Win 10 Build 18362). I'm developing an Angular app and when I'm setting up a breakpoint in dev tools, it keeps opening the minified app.js, which causing the whole chrome to freeze. It's annoying and it seriously undermines my work productivity. Also I noticed this with tests, there it opens karma-test-shim.js file with the same effect. I know by reading all possible forum posts, freezes caused by opening large minified files are common, but my problem is why it even opens if I don't have breakpoint there? On the other hand, if I blackbox the minified scripts, then I can't open the .ts files (the dev tool doesn't find them), which is, again useless for me.
Img: Although the breakpoint is set in .ts file, the app.js keeps opening up (it was previously closed).
I don't know if this is issue in my set-up or if is a Chrome issue, but I'll be thankful if someone could help me with this frustrating issue.
I released a new version of a firefox webextension, Copy
All Tabs last night. The code is open source and available on github.
The new version fixes many bugs and is overall more stable. It works as expected on Windows and Mac (Firefox 61).
However, when I was testing on Linux (both Firefox 60 and 61), the "Copy Tabs" function fails.
https://www.google.com/search?q=Component+returned+failure+code&ie=utf-8&oe=utf-8&client=firefox-b-1-ab
Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE)
The function that fails on Linux is located in this file:
https://github.com/charlesbrandt/copy_all_tabs/blob/master/ff-web_extension/background.js
The major shift was moving the copy and paste functions from a content script that was injected into the active tab's page to the background.js file. The content script approach was failing for Firefox specific pages (e.g. about:debugging) for security reasons.
Given the discrepancy, I'm inclined to think it has something to do with Firefox, but if it's a problem in the webextension I'd be happy to fix it.
If this is a bug in firefox, what is the best way to report it?
Alternatively, does anyone have a suggestion for how modify the extension so that it works effectively on all platforms?
Update:
I followed #Dexter's advice and filed a bug in Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1473780
Since that time, the plugin eventually started working in newer versions of the browser.
I do NOT know if this might be your issue, but here goes.
Recently switched from Windows to Pop! OS (derived from Ubuntu/GNOME). Had problems with certain Firefox Browser Extensions, specifically those enabling the copying of links from webpages and subsequent pasting them into, say, GVim.
UNTIL I followed the instructions here:
How to Customize the GNOME Shell in Ubuntu Using Extensions
https://www.makeuseof.com/tag/customize-gnome-shell-extensions/
WRT installing GNOME Tweak, GNOME Shell Extensions, and Shell Extensions for Firefox.
I would suggest you try this and see if it helps. I hope it does.
I came across a problem today where the only way for the web program I am developing showed the most recent copy of a modified script was to reboot the machine. It is a file bundled in the master layout page, in a script bundle. I tried CTRL-F5 and deleted all files (I think) in Internet Options of IE11 to ensure it wasn't using the cached copy, but that was not sufficient.
I then suspected the cause is related to the fact I am using the VS Development server in VS2010. I tried killing WebDev.WebServer40.exe, hypothesizing it was caching it there, but that was not it either. I made the test as basic as modifying the entire contents of the script file to be a single alert() message, which never appeared, until I rebooted the machine.
I've seen suggestions to add args to the file when referencing it, or rename it each build, but clearly that's not productive when running many iterations in new development. I am wondering if there's perhaps a Visual Studio or Internet Explorer option here that guarantees to load the un-cached file each build? Is IE also possibly caching this info in some other memory space I need to be aware of too? thanks
EDIT:
Ok, it turns out the root cause of the problem was a post-build step modifying the script files I was working on. Rebooting was therefore a coincidental fix. As always, blame the writer. :). However, I have seen this problem occur many times in the past, genuinely, and am still curious if there's browser settings available (with specifics) that ensure scripts (and CSS files) are never cached, in development.
Disable the browser cache. Accessed through the debugger or developer tools (usually F12).
Here are some examples:
Chrome
Firefox
IE11