Client side chrome debugging degraded?

Hello,

Noob here…

I have been staying up with the 1.3 betas and release candidates. I noticed that the client side debugging started getting degraded. I cannot set breakpoints on many of the code lines, the breakpoint will jump to the beginning of the function or the end of the function when I try to place a breakpoint somewhere in the function. In many circumstances I need to stick some dummy code in there (e.g. intermediate variables) so that I can have a breakpoint. Or resort to console.log…

The server side debugging is working fine and I can set breakpoints wherever there are code lines without issue.

My question:

  • is this normal?
  • is this a bug in the Meteor build? I had not seen this in v1.2

My environment:
Windows 10 x64
Meteor 1.3-rc.12 (will soon upgrade to 1.3 released)

Thanks!

2 Likes

Yeah I get this all time too, it’s really frustrating. I’m pretty sure I got it with 1.2 too, although I didn’t use that for long before switching to 1.3.

There are a couple of causes I believe: One relates to source maps which I don’t completely understand but relates to the difference between the JS as it is actually processed by the site and the JS in your source code files and how Chrome maps those two things to each other in order to then display your source code to you in the way you are expecting.

The other is that Chrome won’t let you put a break point on a line that it thinks is broken (i.e. doesn’t ‘compile’). Completely unhelpfully it doesn’t tell you when that’s the case.

@joshowens taught me the ways of the debugger keyword which (I’m sure you probably already know) is a programmatic hard breakpoint that will stop your code dead in its tracks. I’ve switched to using that instead of trying to add breakpoints from Chrome.

Thanks for the reply @tomRedox . Given your response I went ahead and filed bug #6623

Gaah! All the MDG devs I’ve seen on videos use Macs, and this seems Windows only according to #6623 :fearful:

Yeah, my feeling from the 1.3 beta period was that nobody at MDG uses Windows as their primary OS, so less obvious issues around speed aren’t as visible to the dev team. It’s got me questioning using Windows for Meteor dev to be honest, but as most of my work at the moment is in .NET it’s not easy to switch to using a Mac, especially as I’ve not had a massive amount of success with running Windows in Parallels/VMWare with multiple monitors for example, although that was a while ago.

However, there are other issues with Windows; it really doesn’t like node’s long file names and the lack of symlinks makes things difficult sometimes too, so I might reinvestigate the Mac approach.

I closed #6623 out. It seems with Meteor 1.4 the issue has gone away. Hurray!