Open Bug 1723440 Opened 3 years ago Updated 2 months ago

debugger breakpoint is not working after setting it on SOURCE

Categories

(DevTools :: Debugger, defect, P3)

Product:
DevTools
Component:
Debugger
Version:
Firefox 92
Type:
defect

Tracking

(Not tracked)

People

(Reporter: karlcow, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

Attachments

(1 file, 3 obsolete files)

network panel
1.68 MB, image/png
Details

Trying to diagnose Bug 1723343

  1. with Firefox Nightly 92.0a1 (2021-07-30) (64-bit) on macos
  2. Go to https://reasonator.toolforge.org/geneawiki2/?q=Q42
  3. Open the debugger tool in devtools
  4. Search all files for "function GeneaWiki "
  5. One match appears exactly
  6. Go to that file and sets a breakpoint, for example, on this.column_spacing = 40 ;
  7. Reload the page

Expected:
the debugger breaks for that line

Actual:
Nothing is stopped as if the breakpoint was not set.

No specific file in the tree seems associated to these instructions.

Duplicate of Bug 1720443 ?

fwiw it seems edge canary doesn't even find the source code at all. no match for the geneawiki function. I can only find it at the previous level.

Attached image network panel —

This is the JS file which is not being shown in the debugger
https://reasonator.toolforge.org/geneawiki2/gw.js

we can see it in network.

The file seems to be dynamically loaded through a form.html which is also created dynamically.

my comments:

// is the document ready?
$(document).ready(function () {
  // then load stuff
  loadMenuBarAndContent({
    toolname: "GeneaWiki2",
    meta: "GeneaWiki2",

    // an html file
    content: "form.html",

    // and run it
    run: function () {
      document.title = "GeneaWiki";
      gw = new GeneaWiki("results");
      gw.status_id = "status";
      $("#results svg").css({ width: "100%" });
      initializeFromParameters();
    },
  });
});

The form.html is

<script src="jquery-svgpan.js"></script>
<script src="gw.js"></script>

<div class="row" id='result_container'>
	<div class="span12" id='results' style='overflow:auto;border:1px solid #DDDDDD;height:600px'>
	</div>
	
	<div class="span12">
	<small>
	Use mouse wheel to zoom, drag to pan. Connection colors have no additional meaning.
	</small>
	</div>

	<div class="span12" id='status'>
	</div>
	
</div>

grmph…

Thanks!

Even though we show the breakpoint, it seems we can't actually apply it because we are missing a proper source information:

console.error: 
"Ignore invalid breakpoint from debugger store" 
({
  options: {}, 
  disabled: false, 
  location: {
    sourceUrl: null, 
    line:4, 
    column:1
  },
  astLocation: {
    name: "GeneaWiki", 
    offset: {
      line: 3, 
      column: (void 0)
    },
    index: 0
  }, 
  generatedLocation: {
    sourceUrl: null,
    line: 4, 
    column: 1
  }
}) 
"Breakpoints expect to have either a sourceUrl or a sourceId."

:karlcow, in case this helps, as a workaround, you can set a breakpoint in main.js "gw = new GeneaWiki ( 'results' ) ;" and step in from there.

Just to confirm, this is really an issue about breakpoint persistence.

I did the following:

  • set a breakpoint in main.js at the line gw = new GeneaWiki ( 'results' ) ;
  • reload
  • wait for debugger to pause

Then I added a breakpoint as in the initial STRs:

  • search for "function GeneaWiki "
  • set breakpoint on this.column_spacing = 40 ;

And then I resumed. The debugger managed to break on the other breakpoint. So at least the breakpoints work. It's just that we can't actually track which source they have been added to, so after a reload we lose track of them.

It's very confusing that the breakpoints still show up in the UI however. We fixed a bug around persisting invalid breakpoints in Bug 1720512, but it's a shame that we keep displaying those breakpoints as if they had been persisted. At the very least we should hide them on navigation. I will file another bug for that. (filed bug 1723475)

See Also: → 1723475

Julian,
Yup it's what I ended up doing.
Thanks!

Severity: -- → S3
Priority: -- → P3
Attachment #9347553 - Attachment is obsolete: true
Attachment #9345196 - Attachment is obsolete: true
Attachment #9333012 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: