1505282 - WebIDE keeps duplicating the devtools frame

Status: RESOLVED DUPLICATE of bug 1545407

(DevTools :: about:debugging, enhancement, P3)

Description

[Lars T Hansen [:lth]]

Attachment: WebIDE tools frames.png

I'm developing remotely on an Android device.  WebIDE connects to the device just fine, and I select my tab and debug it for a while, everything seems OK.  Then for some reason the device is disconnected, so I reconnect and re-select the tab, and when I do that, I get a second frame at the bottom of the WebIDE window for the tools; the space previously occupied by the tools is left blank below the new tools frame.

After I've done this a few times the window looks like the attached screenshot: a tiny area at the top for the WebIDE itself, then the tools frame, then three blank areas where the tools used to be.

Comment 1

[Lars T Hansen [:lth]]

For the record:

- Android device is a Samsung Galaxy Tab S2 with Android 7, Firefox Nightly updated today
- Desktop system is some x64 thing with Fedora 28, Firefox Nightly updated today

There are other problems with WebIDE in this context:

- that it keeps disconnecting from the device, since I lose debugging context every time that happens, notably my place in a 1MB+ wasm file that I'm debugging

- that the tab I'm debugging (the one that is in focus) is at the bottom of the list of tabs in WebIDE (I have 40+ tabs at the moment)

Comment 2

[Soledad Penades [:sole] [:spenades]]

Hello Lars,

thanks for filing the bug. I think you've stumbled upon the worst parts of WebIDE; I'm really sorry about that.

We're working on an easier workflow for debugging mobile devices, which does not involve using WebIDE.

At the moment we're only able to connect to USB devices, but if that's what you're using and want to give a try to this new system, using Nightly, I'd highly recommend it! It should be more stable than WebIDE, although since it's under development there might be new bugs. Apologies in advance!

The new system replaces the previous about:debugging page, but it is currently behind a pref, so you need to activate it first. 

1. Go to about:config
2. search for devtools.aboutdebugging.new-enabled and set it to true.
3. Then go to about:debugging
4. With your USB connected phone, you should be able to connect to it and debug tabs

Please let us know if that works.

Thank you for your patience :-)

Comment 3

[Lars T Hansen [:lth]]

(In reply to Soledad Penades [:sole] [:spenades] from comment #2)
> Hello Lars,
> 
> thanks for filing the bug. I think you've stumbled upon the worst parts of
> WebIDE; I'm really sorry about that.

As they say, nothing is idiot-proof because the idiots are so clever :)  I did find my bug eventually, so no real harm done.

> We're working on an easier workflow for debugging mobile devices, which does
> not involve using WebIDE.
> 
> At the moment we're only able to connect to USB devices, but if that's what
> you're using and want to give a try to this new system, using Nightly, I'd
> highly recommend it! It should be more stable than WebIDE, although since
> it's under development there might be new bugs. Apologies in advance!

OK, that's very promising.  The Android debug session was a one-off thing, I don't normally need to work on Android at all, but should the issue come up again I'll keep this very much in mind.  Thanks for letting me know.

Comment 4

[Lars T Hansen [:lth]]

(In reply to Soledad Penades [:sole] [:spenades] from comment #2)

Hello Lars,

The new system replaces the previous about:debugging page, but it is
currently behind a pref, so you need to activate it first.

1. Go to about:config
2. search for devtools.aboutdebugging.new-enabled and set it to true.
3. Then go to about:debugging
4. With your USB connected phone, you should be able to connect to it and
   debug tabs

This more or less works (it doesn't feel stable, but it does work :) but has a number of real weaknesses that I hope can be addressed, here are some I've run into:

• I can look at the contents of workers but I can't debug webassembly in a worker, because compiling wasm for debugging requires reloading the page and reloading it changes the UUID of the worker, leaving the current worker window inert; when I then open a new window for the worker with the new UUID I have the same problem
• The network pane appears to show a subset of the loaded content, and this subset is not stable (for example, on a twitch.tv channel there's a ton of JS and some webassembly but the network pane I'm looking at right now shows me neither)
• The settings for stopping on exceptions appear to be global; this may be an ok compromise now but won't be in the long run (also it's not obvious this works for workers whose windows have not been opened yet, meaning it's impossible to diagnose startup problems).

It's probably critical, in a debugging setting, to auto-popup windows for workers when they are created, without running code in them, so that the programmer can set debugging options.

It's certainly critical that if a page is being debugged then all wasm on the page and in the page's workers is being compiled for debugging.

Comment 5

[Lars T Hansen [:lth]]

Ah, I see what I took to be the UUID is something twitch serves up, not something we control. So the point about how debuggable workers are is more open, I need further data.

Comment 6

[Soledad Penades [:sole] [:spenades]]

Thank you Lars - this feedback is really useful! Are those problems just things you see when debugging remote devices, or do you experience them on a 'normal' desktop debugging session?

Also, if you have steps to reproduce any of these less-than-optimal situations, that would help us fix and validate them :)

Comment 7

[Lars T Hansen [:lth]]

I encountered a lot of problems while trying to debug a problem on twitch.tv. If you connect to firefox on a phone and (on the phone) go to https://m.twitch.tv, select a channel, and then select a stream, you should see information for the page with the stream on it. (The stream might not play, which is bug 1521939.) There should be a lot of JS content and normally one wasm file showing in the network pane, and they did show up in WebIDE in DevEd, but not in about:debugging. Also, in the debugger pane, you should see two workers. If you open one of them there should be just one node to expand, and a couple levels down you'll see a wasm file. When you select that you'll get a message in the source code frame that you need to reload to debug wasm. But when I reload ... I get the same problem all over again. So I can't debug wasm in a worker, at least not the way twitch has set things up.

As far as stopping on exceptions is concerned, that does work in the main thread but I'm fairly sure it does not work in workers; when I choose to stop even on exceptions that will be caught, I do stop at a lot of exceptions in the main thread, but at none in the workers, though I'm reasonably sure there are some.

Workers are going to be a big deal very soon, so a better debugging experience for workers would be most welcome...

Thanks for asking!

Comment 8

[Soledad Penades [:sole] [:spenades]]

Thanks a lot, Lars!

After reading this carefully...

I think many of the issues about pausing on exceptions or popping debugger windows open for the worker are all potential Debugger bugs (so pinging Jason as they're doing work with workers in the debugger and this might be really interesting to hear) (Jason - comment #4 and comment #7)

I'm also pinging Jan as he's the owner of network monitor and perhaps wants to look into the network panel issue with missing content (comment #4)

Lars, sorry to repeat myself but if you could provide reduced test cases that we can use to validate (and perhaps to use in our test suite) it will make it so much easier to ensure this works reliably. There are so many reports of sites not working under specific conditions, but when we get the chance to look at it the site has changed and it's not reproducible anymore, so we know there's a problem but we cannot fix it :-(

Comment 9

[Lars T Hansen [:lth]]

I'll file what I can but it'll be a best-effort activity, as available time is very limited :(

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Can I somehow reproduce the scenario on my machine and test the Network panel with no remote device?

Honza

Comment 11

[Lars T Hansen [:lth]]

Re network panel, I don't know. I was not able to repro the network panel problem on a later attempt, even with a remote device. about:debugging also seems to be unstable on startup (doesn't work real well the first couple attempts) but becomes more reliable after that, so it's possible it was an artifact of startup woes.

Comment 12

[Julian Descottes [:jdescottes]]

Thanks for the feedback. This bug has interesting suggestions but will be hard to move forward as it is. I will move the worker related feedback to another bug.

I am not going to mention the comment about "pause on exception" being global. It is the case, once you enable it on one debugger, it will be enabled for all your debugger instances. If there are alternative suggestions, it would be better to file a bug in the Debugger component. I personally would not really know what to suggest so I can't file that bug on your behalf.

Comment 13

[Lars T Hansen [:lth]]

(In reply to Julian Descottes [:jdescottes] from comment #12)

Thanks for the feedback. This bug has interesting suggestions but will be hard to move forward as it is. I will move the worker related feedback to another bug.

OK.

I am not going to mention the comment about "pause on exception" being global. It is the case, once you enable it on one debugger, it will be enabled for all your debugger instances. If there are alternative suggestions, it would be better to file a bug in the Debugger component.

I will do that; it's the kind of thing that needs to be fixed if the debugger's going to be useful for real programs.