1286850 - Addon Debugger/Toolbox does not update script file (48.0b6)

Status: RESOLVED WORKSFORME

(DevTools :: Debugger, defect, P2)

Description

[bugzilla12345678]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140911151253

Steps to reproduce:

When I add addon to Addon Debugger and connect, then I click on popup to open new page which I want to debug. I insert breakpoint in Debugger. I debug it and do some change in the function I am debugging. I do it in external editor. Then I reload the addon. The Debugger did not refreshed the window with script which was changed. Sometimes it helped me to reload the addon, but sometimes not and I need to restart the Firefox, add the addon, connect, click on popup, find function and add breakpoint...


Actual results:

The Debugger did not refreshed the script file when addon is restarted.


Expected results:

The Debugger should reload script when I restart addon or when I restart addon and click on popup (in that moment Debugger registers the page script). I would be better if you would add icon to click on it, and to do this stem automatically (refresh icon).

Comment 1

[bugzilla12345678]

I choosed severity blocker because If I want to add breakpoint I need to reconnect to Addon or restart Firefox, which is the worst case.

Comment 2

[bugzilla12345678]

In most cases, restart of Firefox is needed because Addon Debugger does not update script file.
Highly frustrating, disgusting experience... You should fix it as fast as possible

Comment 3

[bugzilla12345678]

Also - the Debugger does not print any errors in script file, when there is error in script file, it just will not run it. This is why I restart 60 times per hour. It is hard to find if error is in the script or it is corrected already because Debugger does not reflect the changes in code. It often does not see that the error was corrected, so when I use console.log it will not print any log.

Exceptions are usable only if the code is running, not when it is not running.

Comment 4

[bugzilla12345678]

The Addon Debugger also shows incorrect values for variables when the loaded script file was not updated

Comment 5

[bugzilla12345678]

I added url image. The current code in the namespace.js content script is:
// console.log(make_it_easy);
var make_it_easy = {
  inspector: {},
  extractor: {},
  easy: {},
  advanced: {},
  images: {}
};

And I can go through it. When I paste bookmark on line #1, so it is ignored like there is no code. If I add bookmark on line #4, so it is paused. I can go line by line even that the code looks like commented.

Comment 6

[bugzilla12345678]

correction: breakpoint, not bookmark

Comment 7

[bugzilla12345678]

I can confirm that Toolbox/Debugger is showing incorrect results, errors and exceptions

due to the fact that Toolbox does not update the code after the file/script change was made.

I can give you an example from my current code. Using JQuery I try to access iframe->body elements on this page:
https://www.poradte.cz/poradna/5/

var iframes = $("iframe[class~='wysiwyg']");
  if (iframes)
    $.each(iframes.prevObject, function( k, iframe ) {
      add_styles(task, iframe);  
    });

Now the function add_styles which was before Content Script file change:
var easy_add_styles =
function(task, iframe = null){
    if ( iframe.body )
      {
      var contents = $(iframe.body).contents()
      for ( var k in task.search )
        {
        console.log(contents.find(task.search[k]));
        contents.find(task.search[k]).css(task.css[k]);
        }
      }
}

Now the function add_styles which was after Content Script file change:
easy_add_styles =
var function(task, iframe = null){
    if ( iframe.body )
      {
      var contents = $(iframe.body).contents()
      for ( var k in task.search )
        {
        console.log(contents.find(task.search[k]));
        contents.find(task.search[k]).css(task.css[k]);
        $.each(contents.find(task.search[k]), function( k, element ) {
          $(element).css(task.css[k]);  
        });


        }
      }
}

To test it you need to create object task with search array containing selectors (div, input, etc) and array of css styles.

What I did is that when the Content Script file was opened in Toolbox/Debugger I did change in the file. Then I restarted the addon, reloaded the webpage. Code was injected. I called the command which executes the function add_styles. Now I got error/exception that the element is wrong reference, does not exists or that it does not contain function css or something like this.

I needed to close ToolBox and restart Firefox, open my addon, open the webpage, open the Toolbox, find the function add_styles, add breakpoint, run the hotkey/command again. Now I can debug the function without problem. The debugger now sees the element variable to be defined and prints no errors.

And this is the reason why Firefox is loosing users (at least the extensions programmers). They prefer to work with Chrome development tools which are reliable and without performance problems. I wonder how long I can stay with you.

Comment 8

[bugzilla12345678]

Additional facts:

+ when I restart Firefox and open the Toolbox, then open document to debug, this work 100%. But bugs in this state
- when the update bug happens, the updated code in file is not visible. I close the Toolbox, then I update the web-page, then I start the Toolbox again. Sometimes, I repeat, SOMETIMES, the code in Toolbox is refreshed.
- I can debug on an average of 10-15 minutes till the bug happens (code is not updated after change).
- When the bug happens, it is either when MORE THAN 1 LINE WAS CHANGED
- or it is after longer period of time. E.g. when I put my PC to sleep for 30-60 minutes. Then I go back, turn it on. And I try to debug, but the changes in code do not reflect to the code loaded in debugger. Here I must to restart the Firefox completely.

Comment 9

[Patrick Brosset <:pbro>]

Pinging the component owner to confirm and triage this bug.

Comment 10

[James Long (:jlongster)]

This sounds like a complicated workflow involving addons and how they are loaded. Nobody is maintaining the addon debugger right now, honestly. This may also be problematic because the old debugger does not support scripts with the same URL. What might be happening is a script file is loaded in the debugger, let's say it's URL is resource://my-addon/foo.js, and it loads the text. Then some special reloading logic updates that URL. The debugger has no way of knowing that the script has been updated, and continues to show the old text.

However, restarting the addon debugger should fix that issue. It sounds like there's something a lot more complicated going on.

I feel like this needs to be split up into a few bugs, with specific isolated test cases. That would help a lot in being able to reproduce specific bugs. I think there are multiple things going on here, so separating each problem would help (even if they may be related, we can dupe bugs later).

We are working on a new debugger that is enabled in nightly. It also doesn't support scripts that are updated with the same URL, as the UX of that is very hard to get right. (the old script can still exist in memory, and have breakpoints, so what happens when it breaks on the old script?) Currently we are focusing on the new debugger and addon debugging is not a focus right now. I'm sorry you are hitting this in your workflow, but there are other workflows that we need to focus more on (typical webdev workflows which a *lot* more people are using), so I'm setting this as P2.

Comment 11

[Jason Laster [:jlast]]

Honza, what do you think about this?

Comment 12

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

I tested addon debugging a bit:

1. Load and addon using about:debugging
2. Create BP in content script
3. Hit BP and step, see callstack, inline preview
4. Change the source in external editor
5. Reload addon and the page
6. Hit BP again, source is updated

All work for me just fine.

Since this is 3 years old report and a lot changed since that I am going to close as WORKSFORME.

@[e-mail]: Please reopen if you are still able to reproduce this issue (a zdravím z ČB :)

Honza