Debugger click-to-resume overlay broken on 0.19 about browser HOT 15 CLOSED

Created. #40

from browser.

Sorry, I get a very different behavior because I have a page with two Elm apps in it, and it barfs in special ways when I open both debuggers.

from browser.

But in 0.19, the overlay is not shown.

It is shown outside of the window. I could make it shown by adding position: fixed to the overlay (from devtool), but the "Resume" event was still not handled.

I think this is the event handler but seems like not working.

from browser.

Can we get some action on this issue? I want to demonstrate the awesomeness of Elm and use 0.19, but this regression would make me look silly if I try to show off the debugger.

Sounds like you know what to do, @jinjor

from browser.

@Pilatch
I tried debugging hard, but it was really hard (against my expectation) and finally gave up. I think something is wrong in handling virtual DOM in the kernel logic. If you want to debug, you can do something like this.

from browser.

That's pretty cool. I'm seeing a runtime error getting tossed.

Uncaught TypeError: domNode.replaceData is not a function

{
	switch (patch.$)
	{
		case 0:
			return _VirtualDom_applyPatchRedraw(domNode, patch.s, patch.u);

		case 4:
			_VirtualDom_applyFacts(domNode, patch.u, patch.s);
			return domNode;

		case 3:
			domNode.replaceData(0, domNode.length, patch.s);
			return domNode;

from browser.

But... it looks like this should have been resolved a while back. Maybe it's a regression. elm/virtual-dom#20

from browser.

@evancz How do I debug codez in here so I can contribute? I tried jinjor's suggestion of using elm-kernel-debug, but that didn't honor the changes I made in the Browser module and compile them into index.html.

How do you do it when working on stuff?

from browser.

@Pilatch Did you understand what the shell script does? It is just a dirty hack, not a library.

from browser.

Yea, I understand what it's doing. I wanted to test the browser library, so I made changes in there, put it in the base of the project alongside virtual-dom, changed the package variable in the shell script and re-built. The script puts my changes into the 0.19.0 folder, but the generated index.html file doesn't have those changes in it.

from browser.

OK, I think I see what's up. Thanks to a helpful person in slack, I discovered that you can negate the cache by deleting .dat files, and by putting stuff in your ~/.elm folder, which would mean the build script would change line 23 to

target_dir=~/.elm/0.19.0/package/$author/$package/$version

EDIT: For some reason I had to delete the export ELM_HOME line because that was putting stuff in the current directory, and it refused to actually use that when building. Go figure. Maybe with some refinement I can find out why.

EDIT EDIT: Got it. Just need to whack the .dat files at the right point. See diff.

@@ -15,6 +15,7 @@ here=`pwd`
 export ELM_HOME=$here

 cd $package
+find . -iname '*.dat' | xargs rm
 version=`cat elm.json | jq -e .version | tr -d '"'`
 rm -rf ./elm-stuff
 elm make --docs=documentation.json
@@ -27,5 +28,5 @@ cp -r $package/* $target_dir```

from browser.

Nope. Finally found it. There was a version conflict with virtual-dom. The one I was modifying was 1.0.2, but elm was building 1.0.0. Will update your readme and send pull request... among other things. :)

from browser.

Update. Now that I have that running smoothly I can debug enough to confidently say:

1. The overlay can display properly by adding styles in Overlay.elm as @jinjor suggested.

                    , style "position" "fixed"
                    , style "top" "0"
                    , style "left" "0"

2. Clicking to resume is bugged not because of Elm code, but because of Debugger.js. I was reminded by the adage, "When you find a bug, it's probably in JS." We also know the Elm code is not at fault because the Resume button on the little popout thingy works as expected, and that just sends a simple Resume message.

We can prove this by allowing click events through. in the _Debugger_blocker function in Debugger.js we can add this check against click events, which will make the overlay's click event work as intended.

	if (event.type !== 'click')
	{
		event.stopPropagation();
		event.preventDefault();
	}

Of course that lets all click events through, which will have undesirable consequences and will probably corrupt the program's state in some cases. So my task is now to only allow click events on the overlay. How to do that is not immediately obvious because hoo-boy this code is funky!

from browser.

Derp. Looks like I just needed to add id "elm-debugger-overlay" to the overlay in Elm. Incoming merge request.

from browser.

The fix in #40 ended up in some debugger improvements that @Skinney worked on recently. The plan is to release that in a PATCH change by Monday, so it should be possible to get the fixed version by just changing from 1.0.1 to 1.0.2 once it is out!

from browser.